systemd acceptance, packaging guidelines (was Re: systemd and changes)

[Bill Nottingham]

Matthias Clasen (mclasen at redhat.com) said: 
> > BOOTUP
> > - System boots successfully to GUI, when configured.
> > - System boots successfully to text mode, when configured.
> > - System properly handles being passed [1-5], 'single', 'S', 's', '-s',
> >   booting to the appropriate 'runlevel' (0 and 6 can still work,
> >   but they're sort of pointless anyway) When booted in this manner,
> >   '5' will bring up a GUI, and '3' will not.
> 
> You mean 'being passed on the kernel cmdline', I assume ?

Yes.

> Do we consider interactive boot essential (I think not) ?

This seems rather complicated, given the parallel nature of how systemd
starts things.

> Should mention something about forced fsck, maybe.
> What about selinux relabeling ?

Booting with 'forcefsck', 'fastboot', and 'autorelabel' should continue to
function.

> > PACKAGING
> > - Guidelines for packaging systemd units shall be formalized.
> > - The behavior when both systemd units and SysV services are present on
> >   the system shall be defined. This includes defined behavior when a
> >   service appears to be 'enabled' for SysV links while 'disabled' for
> >   systemd (and vice-versa).
> > - The syntax of systemd units shall be frozen for the release (all future
> >   releases? Some set number of releases?)
> 
> Can you clarify this a bit ? I assume what we want is that future
> systemd releases remain backwards compatible with systemd units of
> today.

Yes. The idea is that if someone writes a systemd unit file today, they're
not going to need to change its syntax, or where they put it, or how they
enable it in future releases, unless they're changing it to use *new*
features of systemd.

> > GENERAL SANITY
> > - Booting a system shall achieve a similar result as booting in upstart:
> > -- The same set of services will be started.
> 
> I don't think this is a requirement on systemd, really. If we make
> changes to the default system configuration to not include a service in
> F14 that was included in F13, that is not a systemd problem. So, I think
> what you really mean here is: systemd will start all services that are
> configured to be included in the default install (and dependencies), but
> no others.

I meant 'as booting in upstart on the same release'. It's still an option
in the F-14 branched tree.

> > -- The services shall function the same.
> 
> This is again not really much of a systemd requirement.

It's a place where systemd can cause regressions due to the change in
how services are started. See the current (now fixed?) NetworkManager problems.

> > ORDERING
> > - rc.local will run as the final service on bootup.
> > - gettys will not start until after rc.local.
> 
> These two seem contradictory, at first sight...

I wasn't treating gettys as a service, but we can reword this.

Bill