Re: New essential package sysvinit-utils split out from sysvinit
> sysvinit is also an Essential package. What steps are you taking to ensure
> that you've retained the proper semantics for Essential? Such changes
> should be backed with more than just an apt upgrade test, because an apt
> upgrade where everything /works/ may not be the case we'll have to worry
> about in the future. As a start, I think that sysvinit would need to
> Pre-Depend on sysvinit-utils, to ensure that the packages are unpacked in
> the correct order to not break sysvinit on disk.
Yes, sysvinit need to pre-depend on sysvinit-utils, and this is
already done. The debootstrap test also verified that this work. And
to list the steps I have taken:
- looked at how Ubuntu have done a similar split
- tested using debootstrap to verify that this do not affect the installer
- tested using aptitude upgrade to verify that it do not affect upgrades
- tested using 'dpkg -i' (need to be done in two steps because of the
pre-depend) to verify that the packages behave as they should.
I am open for suggestions on what more to test. The packages are now
available in experimental, for those interesting in testing it.
> Also, sysvinit is an Essential package. So how is upstart going to
> conflict with it? (At least, it seems that upstart can't be
> usefully introduced into Debian until etch+1, and that only if
> sysvinit itself is *not* going to be Essential for etch.)
You are correct, and this is intentional. The point is to make it
easier, not trivial, to test upstart and other sysvinit replacements.
Those testing upstart will have to cope with the removal of the
essential package themselves for Etch. After Etch we might consider
making it even easier.
> Which programs are going to be in the sysvinit package, and which
> ones are going to be in the sysvinit-utils package, and why?
I realise I forgot to point to the discussion where the introduction
of this package have been discussed. The thread start in
The programs killall5, last, lastb, mesg, pidof and sulogin are moved.
they are used independently from init, and I believe it make sense to
make them available in a separate package.