On Tue, 25.05.10 13:15, Simo Sorce (ssorce@xxxxxxxxxx) wrote: > > My one concern about the current discussion is that the decision to > > move to systemd in the timeframe of F14 is being rushed ahead of the > > aforementioned technical judgement. I can understand your personal > > enthusiasm for the move as you are intimately familiar with systemd. > > But I'm not sure its adequate to rush ahead until we all have a better > > feel on how this works in practise... and how much work its going to > > take to convert all our existing packages to systemd styled startup. > > The back and forth on your blog between yourself and Tim Waugh about > > cups service activation, for example, is something I think we all need > > to understand. I think there is a lot buried in that discussion about > > how complex some of our existing services are going to look under > > systemd styled configuration. > > I second that. > > I'd like to remember that there are *many* upstreams are going to > resistant to this change. A lot of upstream projects need to be > compatible to a lot of Linux and Unix systems, even old ones, so before > they move they want guarantee that this is really going to be the next > thing. That means that until most distributions start using systemd > they are not going to do the work. They don't *need* to move. It's not an exclusive disjunction, that you'd have to support either systemd or not systemd. You can easily support both systemd activation and classic sysv from the same binary. The 10 daemons we have patched so far only needed about 10 lines of changes each to become socket-activatable. And those changes are nops unless $LISTEN_FDS is set. Or in other words: moving to systemd is a gradual process, where for every service we can decide indivdually how we want to do it: 1) continue use a classic sysv init script 2) provide a native unit file 3) provide a native unit file and do socket/bus based activation And all that for the same binary. As mentioned I have now patched the 10 daemons or so we ship by default (and a few more) to become socket activatable. If we can merge those upstream and into our packages we already are a big step ahead and everything else can come later. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
