Bug#762194: Alternative proposal for init switch on upgrades.
]] Cameron Norman
> On Sat, Nov 22, 2014 at 6:10 PM, Adam Borowski <kilobyte@angband.pl> wrote:
> > On Sat, Nov 22, 2014 at 05:29:42PM -0800, Cameron Norman wrote:
> >> I would like to propose a different one.
> > [...]
> >>
> >> So, the change would be that: the sysvinit package would cease being a
> >> transition / shim package, however it would not signal that a user
> >> explicitly installed sysvinit; sysvinit-core would be a simple package
> >> that just depended on sysvinit, and the presence of this package
> >> *would* signal that the user explicitly installed sysvinit; init would
> >> (pre-)depend on "systemd-sysv | sysvinit | sysvinit-core | upstart".
> >
> > I'm afraid this doesn't allow partial upgrades from wheezy to use
> > systemd-sysv, as sysvinit is an essential package there, and apt considers
> > packages to be essential if they're present in any source.
>
> I take it you mean that the user will have to remove an essential
> package to install systemd-sysv, not that the package will not be
> installable, correct?
>
> That seems reasonable to me. If the user has packages from Wheezy
> installed, those packages could reasonably depend on sysvinit as PID 1
> without expressing that dependency.
No. They could reasonably depend on sysvinit being installed. We ship
alternative inits in wheezy, some of which does not require sysvinit to
be uninstalled (systemd and runit comes to mind, I would not be
surprised if there are more).
However, in the tradition of Essential packages, nowhere is it
well-defined which of sysvinits interfaces were part of the
essentialness and which are not. I kinda wish we'd fix that at some
point, to make it easier to swap out (or get rid of) Essential packages.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
Reply to: