On Mon, 23.08.10 23:06, Bill Nottingham (notting@xxxxxxxxxx) wrote: > (intentionally breaking thread) > > Toshio Kuratomi (a.badger@xxxxxxxxx) 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. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
