(intentionally breaking thread)
Toshio Kuratomi (a.badger(a)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.)
- As long as we're still shipping upstart, the sysv scripts would still
need included, and would still need to be set up with chkconfig the
same way.
> As noted in the post, I'm not sure if the outlined procedure correctly
> implements level 1.
I believe it does.
> We should probably also have the scriptlets for implementing level 3 for the
> things basic to the system that require that.
My reading of your mail is different - the case we want to handle is case
#2 (installation of something that starts by default - dbus, NM, etc.)
As I understand it, they would be the same, with the addition of:
%post
if [ 0$1 -eq ]; then
/bin/systemctl enable<foo.service>
fi
with foo.service having the appropriate [Install] stanza that says where it
should start up. As with SysV scripts, we generally do not start services
by default, so this is rare.
Case #3 that you mentioned is something I don't think we have in Fedora -
we never start services on package installation.
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.
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.
SINGLE USER MODE
- Exiting single user mode properly returns to the default state.
- single-user mode output is correctly displayed on the console.
File /etc/inittab should keep working at the same level it is now.
Jeff