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

[Lennart Poettering]

On Mon, 23.08.10 23:06, Bill Nottingham (notting at redhat.com) wrote:

> (intentionally breaking thread)
> 
> Toshio Kuratomi (a.badger at gmail.com) said: 
> > 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?
> 
> - At the moment, /bin/systemctl is in systemd-units. (I think this
>   is a bug. Filed.)

No, this is actually intended that way: systemd-units contains
everything necessary by packages that want to ship systemd unit files:
the dirs to place them in, some of the deps and the tool to
enable/disable them. Everything for actually booting systemd otoh is in
the systemd package.

> This, however, is just packaging guidelines. From readng the thread, there
> are many things that I think people would like covered with systemd before
> they would feel comfortable with it. So, I'm going to attempt to quantify
> what would need to be tested and verified. This document focuses on
> backwards compatibility. THIS IS GOING TO BE VERY VERBOSE. Comments, changes,
> etc. welcome.

While I think this is a good idea I am concernced a bit that this makes
me responsible for stuff I am not willing to take responsibility
of. i.e. if something from this list is broken, but it isn't systemd's
fault then this should not be a reason to drop systemd from F14. Also,
some of this I am not really able or willing to test (iscsi...), so I
don't want to be responsible to fix this.

I think the list is generally good, but the process for handling it
should be that bugs are filed about items from the list which don't work
correctly and be marked as blockers. But if they are subsequently
reassigned to other packages, then this should not reflect back to
systemd.

Some comments on the individual items.

> PLYMOUTH
> - plymouth is shown on startup.
> - plymouth is quit correctly.
> - plymouth is shown on shutdown.
> - 'esc' to show details still functions in plymouth.
> - an equivalent to /var/log/boot.log still exists, and is populated
>   (can be normal syslog)
> - plymouth transition from grub -> boot -> X is seamless for KMS cards,
>   similar to Fedora 13.

Except maybe the first three items this is completely independent of
systemd. I am not willing to take responsibility for bugs that are in
Plymouth, in X, or in the kernel.

> - init shall support a mechanism to re-exec itself to not cause dirty
>   inodes on shutdown; initscripts will use this method on shutdown.

This is bad. While we support this just fine I think it is a really bad
idea to reexec init at shutdown. What's the point of this, can you elaborate on
this? This smells to me as a workaround for brokeness in older init
systems, and I don't see a reason why reexecing itself would be
necessary for systemd.

Also, let's not forget that this requirement didn't exist for
Upstart. Upstart always has been and still is unable to reexec itself.

> PREFDM
> - prefdm starts a configured display manager correctly.
> - prefdm starts a installed display manager correctly without additional
>   configuration.

Hmpf, especially the second item is notthing systemd has an influence on.

> CONSOLEKIT
> - ConsoleKit properly logs system start, stop, and restart.
> - The ConsoleKit shutdown/reboot/halt methods work as expected.

Well, I think we had som probs with PK here, but I don't want to be
responsible for fixing PK either.

> SERIAL CONSOLES
> - Booting with a primary serial console (via console=) automatically
>   sets up a getty on the console, and sets up securetty to allow for root
>   login.

I cannot say I am particularly happy with how securetty has been handled
so far: entries are only added, not removed from securetty, and the root
directory must be writable. I'd see this fixed differently, i.e. in
pam_securetty so that it verifies the kernel console= switch internally.

> - (optional) Booting with secondary serial consoles does the same.

Hmm, could you elaborate on this? We have discussed this a couple of
times upstream, and came to the conclusion that the only safe thing to
do is to run a getty only on the main kernel console, i.e. where input
is accepted from.

> PACKAGING
> - Guidelines for packaging systemd units shall be formalized.

As pointed out elsewhere, I'd avoid this for F14.

> SERVICE HANDLING
> - Running 'chkconfig <foo> <(null)|on|off>' on a service managed by systemd
>   will return the correct code/perform an appropriate action.

Hmpff. I don't think this is a good idea. chkconfig should manage SysV
scripts, and "systemctl enable" should manage systemd units. But
interpolating this would create the impression the semantics were
identical, although they really aren't.

What would make sense to add to chkconfig is something that checks
whether a systemd unit is installed and then prints "Hey, you have a
systemd unit installed, chkconfig won't do what you think it will do for
this unit" or so.

It's one thing redirecting /sbin/service to systemctl, but it's a
completely different thing redirecting chkconfig to it as well.

> ORDERING
> - rc.local will run as the final service on bootup.
> - gettys will not start until after rc.local.
> - prefdm will start coincident to gettys (earlier?)

Well, first of all, the first two items here obviously contradict. But
putting that aside: I don't think speaking of ordering here these days
really makes sense. Neither was it traditionally run as last thing of
bootup (i.e. it was only synchronized against sysv scripts, not against
upstart, inittab, dbus, cron, inetd services), nor do I think it even
makes sense to speak of a "final service". There's no such thing. You
can only order things in relation to stuff you know, not to the unknown.

So, saying it should run before the gettys, or before prefdm might make
sense, but saying it should run after "everything else" doesn't
really. But I am not even too convinced about the prefdm/getty ordering,
as this creates an unnecessary synchronization point for everybody, even
though rc.local is empty (which it probably is for 99.9% of all
people). We want prefdm to start as early as possible.

> -- iSCSI /
> -- LDAP user information
> -- IPA/AD user information
> -- NIS user information

Can't test any of this really. Wouldn't even know how to test this. I also
don't want to be responsible for the fact taht nss-ldap is borked.

> - All packaged upstart jobs are modified to have some SysV or systemd-native
>   equivalent.

uh, which ones are these? I'd like to ask that it is decided in the
indivudal case if they matter or don't.

Somebody once posted a list of these packages. Anybody has that handy?

Lennart

-- 
Lennart Poettering - Red Hat, Inc.