Re: systemd and changes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux