Re: Bug#762194: Alternative proposal for init switch on upgrades.
]] Cameron Norman
> On Sat, Nov 29, 2014 at 11:15 PM, Tollef Fog Heen <tfheen@err.no> wrote:
> > ]] 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.
>
> Would systemd-sysv having a `Provides: sysvinit` fix this issue?
I'm not sure which of my two points you're addressing, but I don't think
it would fix either. Packages in wheezy can assume the interfaces
provided by sysvinit are present without any kind of
dependency. (Arguably, they can only assume those in squeeze are
present, if one wants to support partial upgrades, but that's not
particularly important here.) Whether systemd-sysv in jessie Provides
sysvinit or not has no influence on this; there's no dependency being
tracked.
Whether it Provides: sysvinit or not does not change the level (or lack
thereof) of documentation on which of sysvinit's interfaces are
Essential. For instance, I would be surprised if /usr/include/initreq.h
is considered part of the Essential interfaces, and by that I mean more
the «you don't need to depend on this», rather than the «must work when
not configured». The latter is trivial for a .h file, except it
includes bits from libc6-dev, which I think we all agree should not be
considered transitively Essential, because that would be crazy.
/sbin/runlevel and /sbin/telinit I would consider part of the Essential
interface of sysvinit, but my point is: nowhere is this documented, so
different people will make different assumptions here.
> I think if the pre-installation /etc/inittab checking that has been
> discussed is implemented then systemd could reasonably be considered
> to provide sysvinit's interfaces (especially with the /dev/initctl
> compatibility).
Some of them, sure. All? No. And I'm still not sure which problem
you'd be trying to solve with that.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
Reply to: