On Mon, 23.08.10 20:04, Toshio Kuratomi (a.badger@xxxxxxxxx) wrote: > On Mon, Aug 23, 2010 at 11:08:24PM +0200, Lennart Poettering wrote: > > On Mon, 23.08.10 13:59, Jesse Keating (jkeating@xxxxxxxxxxxxxxx) wrote: > > > > > On 8/23/10 1:17 PM, Matthew Miller wrote: > > > > I understand your desire to get your code out there in the real world. But > > > > Fedora really can't afford to have a marketing-disaster release right now. > > > > Because this is a far-reaching change to a core service, any problems people > > > > encounter will be amplified -- and amplified *way more* than my little > > > > complaints. I want to avoid that. > > > > > > Also note that Fedora 15 development is happening now, rawhide is > > > composing each night, and systemd could be tested there just as easily > > > as tested with Fedora 14 branched. Unlike the old days if you missed > > > one release you had to wait months before trying again, we now are able > > > to give you a development tree for the next release immediately. > > > > Well, but why? things in F14 are jolly? > > > > Either stop this discussion or tell me exactly which bug you think is > > the one that makes you think that "systemd for f14" doesn't work out? > > > Maybe I should start a new thread since this isn't really a bug, but it is > a blocker -- we need to get some packaging guidelines out for systemd. > I think that the last message on the subject was this one: > > http://lists.fedoraproject.org/pipermail/devel/2010-July/139483.html > > Could I get a reply as to whether that looks right? There's something missing about how to handle upgrades from only-sysv to both-sysv-and-systemd packages. i.e. you need to check whether sysv is enabled and enable the systemd services accordingly. This is described in daemon(7) in more detail. > As noted in the post, I'm not sure if the outlined procedure correctly > implements level 1. > > We should probably also have the scriptlets for implementing level 3 for the > things basic to the system that require that. Tbh I'd not amend the policy for now, if that's acceptable. The policy currently says that packages should have SysV scripts and that's a good thing. Some selected pkgs now contain systemd unit files in addition to sysv init scripts, but the only policy I'd recommend for them is to say that they should enable/disable/start/stop these exactly in the same cases as the sysv scripts previously were. And I'd say that such a policy is clear anyway. In the F15 cycle we should then revisit this, and come up with a sane policy and even make sysv scripts optional. However, note that this all will probably turn out more complex than it might look: for example, so far no policy for D-Bus services existed, and all D-Bus services that are bus activatable are enabled unconditionally and cannot be disabled without removing the package. Something similar applied to stuff that got started via Upstart or udev: so far it was not possible to disable these services in a sane way. The policy in F15 should cover all these cases, as we shift the focus away from start-everything-on-bootup to a scheme where things are more dynamic. Or in other words: I don't think we should rush out a policy here, let's continue to work for what we have in F14, and then in F15 come up with a comprehensive policy on this, which would even incorporate the experiences we gained with the selected packages which already shipped both sysv and systemd unit files in F14. BTW, was there a written down policy on how to package Upstart jobs/services? Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
