Bug#746578: Reasons to keep systemd-sysv as the first alternative

[Josh Triplett]

On Thu, 18 Sep 2014 17:14:01 -0700 Cameron Norman  
wrote:
> On Thu, Sep 18, 2014 at 2:10 PM, Josh Triplett  wrote:
> > I'm pulling a quote from the bottom of Steve's mail to the top, to call
> > attention to a new and critical point that I didn't see raised anywhere
> > in the debian-devel discussion:
> >
> > On Thu, 18 Sep 2014 12:23:18 -0700 Steve Langasek  wrote:
> >> If we decide that init *should* be automatically changed on upgrade, then
> >
> > (Which I'm assuming from your footnote [1] that you *are* in favor of?)
> >
> >> the ordering of the dependencies on libpam-systemd is immaterial except in
> >> the specific case that someone has upgraded to (or newly installed) jessie,
> >> selected an init system other than the default, and subsequently installed 
> >> a
> >> desktop environment on a system that didn't initially have one.  In this
> >> case, installing the DE *definitely* should not override the user's
> >> explicit selection of init system.
> >
> > *This* is a point that I haven't seen raised in the entire previous
> > discussion on debian-devel, and I think it's a completely valid point.
> >
> > Personally, in this case, I'd argue that the desirable dependency (which
> > we can't easily express) would be "sysvinit-core ? systemd-shim :
> > systemd-sysv".
> 
> To be more precise, it would be "!systemd-sysv ? systemd-shim :
> systemd-sysv" so that other alternate inits are treated equally.

No, that's not equivalent.  Having sysvinit-core installed, since it
only exists in jessie, indicates a system with sysvinit intentionally
and explicitly installed.

That said, as mentioned in my response to Steve's mail, approximating
the dependency with "systemd-shim | systemd-sysv" may suffice *if* it
doesn't break the new-install, upgrade, d-i, or debootstrap cases.

> One question: if `init` and `libpam-systemd` (with the inversed
> dependency) are installed simultaneously on a system with only
> sysvinit installed (i.e. Wheezy), apt would know that systemd-sysv is
> going to be installed (to satisfy init package's dependency) and would
> not install systemd-shim, correct?

That was one of the scenarios I mentioned in my response to Steve's
mail.  Someone should actually test that.

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140919154600.GA21445@thin

Bug#746578: Reasons to keep systemd-sysv as the first alternative

[Uoti Urpala]

On Thu, 2014-09-18 at 17:14 -0700, Cameron Norman wrote:
> On Thu, Sep 18, 2014 at 2:10 PM, Josh Triplett  wrote:
> > Personally, in this case, I'd argue that the desirable dependency (which
> > we can't easily express) would be "sysvinit-core ? systemd-shim :
> > systemd-sysv".
> 
> To be more precise, it would be "!systemd-sysv ? systemd-shim :
> systemd-sysv" so that other alternate inits are treated equally.
> 
> As you hopefully can see, this can be condensed to "systemd-sysv ?
> systemd-sysv : systemd-shim" AKA "systemd-shim | systemd-sysv" :)

You completely missed the point, which was to distinguish between
systems that have explicitly installed the new use-sysvinit-as-init
package and systems that only use sysvinit because they have not yet
upgraded to the new default. Neither of those have systemd-sysv
installed, thus your version does not work.


>From another mail:
> If the transition is already happening, why have the dependency be
> like it is anyway? User's systems will be switched regardless, so
> there is no use in having a second pass at changing the init.

For partial upgrades.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1411128134.1645.5.ca...@pp1.inet.fi

Bug#746578: Reasons to keep systemd-sysv as the first alternative

[Cameron Norman]

On Thu, Sep 18, 2014 at 2:10 PM, Josh Triplett  wrote:
> I'm pulling a quote from the bottom of Steve's mail to the top, to call
> attention to a new and critical point that I didn't see raised anywhere
> in the debian-devel discussion:
>
> On Thu, 18 Sep 2014 12:23:18 -0700 Steve Langasek  wrote:
>> If we decide that init *should* be automatically changed on upgrade, then
>
> (Which I'm assuming from your footnote [1] that you *are* in favor of?)
>
>> the ordering of the dependencies on libpam-systemd is immaterial except in
>> the specific case that someone has upgraded to (or newly installed) jessie,
>> selected an init system other than the default, and subsequently installed a
>> desktop environment on a system that didn't initially have one.  In this
>> case, installing the DE *definitely* should not override the user's
>> explicit selection of init system.
>
> *This* is a point that I haven't seen raised in the entire previous
> discussion on debian-devel, and I think it's a completely valid point.
>
> Personally, in this case, I'd argue that the desirable dependency (which
> we can't easily express) would be "sysvinit-core ? systemd-shim :
> systemd-sysv".

To be more precise, it would be "!systemd-sysv ? systemd-shim :
systemd-sysv" so that other alternate inits are treated equally.

As you hopefully can see, this can be condensed to "systemd-sysv ?
systemd-sysv : systemd-shim" AKA "systemd-shim | systemd-sysv" :)

One question: if `init` and `libpam-systemd` (with the inversed
dependency) are installed simultaneously on a system with only
sysvinit installed (i.e. Wheezy), apt would know that systemd-sysv is
going to be installed (to satisfy init package's dependency) and would
not install systemd-shim, correct? Although, according to Steve that
would be simply an aesthetic issue, as systemd-shim does not impede
operation of systemd as init.

Best regards,
--
Cameron Norman


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CALZWFR+DKFwoR=dcarpea5czesyiaupywuwuoa+nmpdjf8l...@mail.gmail.com

Bug#746578: Reasons to keep systemd-sysv as the first alternative

[Uoti Urpala]

On Thu, 2014-09-18 at 12:23 -0700, Steve Langasek wrote:
> On Thu, Sep 18, 2014 at 11:36:54AM -0700, Josh Triplett wrote:
> > I agree completely that it doesn't make sense for the transition from
> > sysvinit to systemd to take place via libpam-systemd rather than via
> > some core package like "init",
> 
> And yet you are arguing that the libpam-systemd dependency should not be
> inverted, for political (not technical) reasons.

He did give *technical* reasons to not invert the dependency. I also
agree that it's suboptimal if the init system changes as a "side effect"
of upgrading/installing some other, seemingly unrelated, package.
However, that does not make it a good idea to install shim as a side
effect instead. At least the case where you do partial upgrades of
packages that now add a libpam-systemd dependency is one where
systemd-sysv first seems technically correct (more below).

When doing partial upgrades, I think the ideal user experience would be
to inform the user that he should do the migration to systemd at this
point before proceeding to update certain individual packages to newer
versions.


> If we decide that init *should* be automatically changed on upgrade, then
> the ordering of the dependencies on libpam-systemd is immaterial except in
> the specific case that someone has upgraded to (or newly installed) jessie,
> selected an init system other than the default, and subsequently installed a
> desktop environment on a system that didn't initially have one.  In this
> case, installing the DE *definitely* should not override the user's
> explicit selection of init system.

It is also relevant if someone does a partial upgrade to current
unstable from an older system that still uses sysvinit for legacy
reasons only (and is expected to switch to systemd at *some* point in
any case). Installing shim would make the user waste effort dealing with
shim's problems, while still requiring them to deal with any
incompatibilities from the systemd transition at a later point.
Deferring some issues in this way while increasing the amount of overall
work and problems could be a valid choice in particular cases, but I do
not thing it should be the default behavior.


> If the bugs in systemd-shim are too severe to allow it to be used with
> logind (a claim that I do not agree with - and I think you and Michael are
> moving the goalposts by using the existence of bugs in
> cgmanager+systemd-shim /in general/ as a justification for delaying the
> change in dependency order), then those bugs should be marked as
> release-critical, and the determination should be made by the usual means
> whether systemd-shim should be included in the release.  But it is not for

There is a difference between a package that's functional enough to be
useful for people who know what they're doing, and a package that's
suitable to be automatically installed just because people do partial
upgrades in a particular order. And it seems that systemd-shim falls in
the first camp (though I have not followed it closely myself). It may
not be RC-buggy, but "not RC-buggy" is not a sufficient quality
criterion to install it automatically if a user just wants newer GNOME
packages for example.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1411076173.1645.3.ca...@pp1.inet.fi

Bug#746578: Reasons to keep systemd-sysv as the first alternative

[Josh Triplett]

I'm pulling a quote from the bottom of Steve's mail to the top, to call
attention to a new and critical point that I didn't see raised anywhere
in the debian-devel discussion:

On Thu, 18 Sep 2014 12:23:18 -0700 Steve Langasek  wrote:
> If we decide that init *should* be automatically changed on upgrade, then

(Which I'm assuming from your footnote [1] that you *are* in favor of?)

> the ordering of the dependencies on libpam-systemd is immaterial except in
> the specific case that someone has upgraded to (or newly installed) jessie,
> selected an init system other than the default, and subsequently installed a
> desktop environment on a system that didn't initially have one.  In this
> case, installing the DE *definitely* should not override the user's
> explicit selection of init system.

*This* is a point that I haven't seen raised in the entire previous
discussion on debian-devel, and I think it's a completely valid point.

Personally, in this case, I'd argue that the desirable dependency (which
we can't easily express) would be "sysvinit-core ? systemd-shim :
systemd-sysv".  In other words, "if the user has explicitly selected
sysvinit, as indicated by installing the sysvinit-core package that only
exists in jessie but not wheezy, then install systemd-shim to make that
work, otherwise use systemd-sysv".  That's not equivalent to either
libpam-systemd's current dependencies *or* your proposal to invert them.

If there's a way to express *that* dependency through the dependency
mechanism we currently have, I'd be entirely in favor of it; if a user
has explicitly selected sysvinit-core, as opposed to implicitly by
having sysvinit installed, then by all means they should end up with
sysvinit-core plus systemd-shim rather than systemd-sysv.

However, that said, if flipping the dependencies around (together with
the current sysvinit and init packages) would best approximate that,
without breaking any of the upgrade or new-install cases, then I'd be
happy to drop my objection to changing libpam-systemd's dependencies.

Specifically, are the following all true even with libpam-systemd's
dependencies inverted?  (Ideally it would help to test this via
debootstrap and apt.)

- Upgrades from wheezy to jessie, with or without a desktop environment
  installed, will transition from sysvinit to systemd-sysv, via the
  init/sysvinit packages (the latter providing /lib/sysvinit/init).

- New installs of jessie via d-i or debootstrap, with or without
  task-desktop or gnome, will install systemd-sysv.  (d-i is the
  important case, but I'm concerned about the deboostrap case because I
  don't know if apt would be smart enough to look at the *simultaneous*
  installation of init and libpam-systemd and favor init's preference of
  systemd-sysv over libpam-systemd's preference of systemd-shim.  I
  don't think d-i installs those simultaneously.)

- As you suggested below, installs of jessie that have explicitly
  switched to sysvinit (or upstart for that matter) and subsequently
  installed a package depending on libpam-systemd should install
  systemd-shim rather than systemd-sysv.

If all three of the above are true with init and sysvinit staying as
they are and libpam-systemd's dependencies switching around, then I
don't see any harm in switching the dependencies around, and I'll stop
advocating against that.  If any of the above would be broken with
libpam-systemd's dependencies inverted, then I'd advocate against
changing those dependencies for exactly that reason.

Ideally, I'd like to keep this part of the discussion (regarding Steve's
very reasonable point below that users who *explicitly* install
sysvinit-core in jessie should not be switched to systemd-sysv by
installing a desktop environment) separate from the question of whether
upgrades from wheezy to jessie should switch from sysvinit to
systemd-sysv (which as far as I can tell Steve is not objecting to, but
Ian is).

On Thu, 18 Sep 2014 12:23:18 -0700 Steve Langasek  wrote:
> On Thu, Sep 18, 2014 at 11:36:54AM -0700, Josh Triplett wrote:
> > On Thu, 18 Sep 2014 11:09:18 -0700 Russ Allbery  wrote:
> > > I conceptually dislike the user experience of switching init systems
> > > because the user upgraded some random package that, from their
> > > perspective, doesn't appear related to the init system.  I feel like
> > > switching init systems should be a more intentional action than that.
> > > There is a variety of local customization that is init-system-specific,
> > > and I'm dubious that we're going to be able to catch and warn about all of
> > > it.
> 
> > > I've not made up my mind about the merits of switching init systems from
> > > sysvinit to systemd during a dist-upgrade, but if we do that, I think we
> > > should do it via some more deliberate and obvious method than pulling
> > > systemd-sysv in via the dependency tree of some random package.  The
> > > partial upgrade UX for that is really bad, IMO.
> 
> > I agree completely that it doesn't make 

Bug#746578: Reasons to keep systemd-sysv as the first alternative

[Russ Allbery]

Steve Langasek  writes:

> If the systemd-shim package is currently broken and should not be
> allowed to satisfy the libpam-systemd dependency, then that should be
> expressed as a release-critical bug keeping it out of the release, *not*
> by the systemd maintainers placing conditions on the ordering of the
> alternative dependencies.  The correct way to avoid libpam-systemd
> triggering a switch of init system is for libpam-systemd to list the
> conservative alternative first in the dependency list.

> If we decide that init should not be automatically changed on
> upgrade[1], then it should not be automatically changed on upgrade for
> /any/ users, including those who have desktop software installed.  The
> way to accomplish this is to list systemd-shim as the first alternative
> dep.

> If we decide that init *should* be automatically changed on upgrade,
> then the ordering of the dependencies on libpam-systemd is immaterial
> except in the specific case that someone has upgraded to (or newly
> installed) jessie, selected an init system other than the default, and
> subsequently installed a desktop environment on a system that didn't
> initially have one.  In this case, installing the DE *definitely* should
> not override the user's explicit selection of init system.

> In both cases, the way to achieve the desired result is for
> libpam-systemd to depend on systemd-shim | systemd-sysv, *not* on
> systemd-sysv | systemd-shim.

Yeah, this exactly.  So far as I can tell, Steve's analysis is correct,
and means that we should list systemd-shim first.

I understand the sensitivity to bugs here, but basically some users are
going to be confused either way.  I believe listing systemd-shim first is
conceptually correct due to the implications for the various scenarios
Steve lays out, and we'll need to deal with bugs by assigning them to the
appropriate package and setting the severity of those bugs as is
appropriate.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/871tr8y7ji@hope.eyrie.org

Bug#746578: Reasons to keep systemd-sysv as the first alternative

[Steve Langasek]

On Thu, Sep 18, 2014 at 11:36:54AM -0700, Josh Triplett wrote:
> On Thu, 18 Sep 2014 11:09:18 -0700 Russ Allbery  wrote:
> > I conceptually dislike the user experience of switching init systems
> > because the user upgraded some random package that, from their
> > perspective, doesn't appear related to the init system.  I feel like
> > switching init systems should be a more intentional action than that.
> > There is a variety of local customization that is init-system-specific,
> > and I'm dubious that we're going to be able to catch and warn about all of
> > it.

> > I've not made up my mind about the merits of switching init systems from
> > sysvinit to systemd during a dist-upgrade, but if we do that, I think we
> > should do it via some more deliberate and obvious method than pulling
> > systemd-sysv in via the dependency tree of some random package.  The
> > partial upgrade UX for that is really bad, IMO.

> I agree completely that it doesn't make sense for the transition from
> sysvinit to systemd to take place via libpam-systemd rather than via
> some core package like "init",

And yet you are arguing that the libpam-systemd dependency should not be
inverted, for political (not technical) reasons.

If the systemd-shim package is currently broken and should not be allowed to
satisfy the libpam-systemd dependency, then that should be expressed as a
release-critical bug keeping it out of the release, *not* by the systemd
maintainers placing conditions on the ordering of the alternative
dependencies.  The correct way to avoid libpam-systemd triggering a switch
of init system is for libpam-systemd to list the conservative alternative
first in the dependency list.

If we decide that init should not be automatically changed on upgrade[1],
then it should not be automatically changed on upgrade for /any/ users,
including those who have desktop software installed.  The way to accomplish
this is to list systemd-shim as the first alternative dep.

If we decide that init *should* be automatically changed on upgrade, then
the ordering of the dependencies on libpam-systemd is immaterial except in
the specific case that someone has upgraded to (or newly installed) jessie,
selected an init system other than the default, and subsequently installed a
desktop environment on a system that didn't initially have one.  In this
case, installing the DE *definitely* should not override the user's
explicit selection of init system.

In both cases, the way to achieve the desired result is for libpam-systemd
to depend on systemd-shim | systemd-sysv, *not* on systemd-sysv |
systemd-shim.

If the bugs in systemd-shim are too severe to allow it to be used with
logind (a claim that I do not agree with - and I think you and Michael are
moving the goalposts by using the existence of bugs in
cgmanager+systemd-shim /in general/ as a justification for delaying the
change in dependency order), then those bugs should be marked as
release-critical, and the determination should be made by the usual means
whether systemd-shim should be included in the release.  But it is not for
the systemd maintainers to exercise a veto on systemd-shim outside of our
normal process for deciding that packages are RC-buggy.

> Nonetheless, as far as I can tell, libpam-systemd is *not* the package
> driving the systemd transition anymore.  Does that address your concern,
> Russ?

It absolutely does not address the problem, because if it weren't driving
the systemd transition in at least some cases (and it is), *there would be
no reason not to list systemd-shim as the first alternative*.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org

[1] For the record, this is not my position.  I understand Russ's concerns,
but I also think the grub transition is as much an example of the *problems*
with such an approach as it is of the successes, because at the end of the
day users are still left to manually switch away from grub1 - many of whom
never have, and have wound up with more bugs over the long term as a result
of using EOLed software.  We should take care that our users' upgrade
experience is a good one, but there are downsides to a policy of never
making a change on upgrade that we haven't 100% proven won't result in boot
regressions.


signature.asc
Description: Digital signature

Bug#746578: Reasons to keep systemd-sysv as the first alternative

[Josh Triplett]

On Thu, Sep 18, 2014 at 11:36:53AM -0700, Josh Triplett wrote:
> On Thu, 18 Sep 2014 11:09:18 -0700 Russ Allbery  wrote:
> > I conceptually dislike the user experience of switching init systems
> > because the user upgraded some random package that, from their
> > perspective, doesn't appear related to the init system.  I feel like
> > switching init systems should be a more intentional action than that.
> > There is a variety of local customization that is init-system-specific,
> > and I'm dubious that we're going to be able to catch and warn about all of
> > it.
> > 
> > I've not made up my mind about the merits of switching init systems from
> > sysvinit to systemd during a dist-upgrade, but if we do that, I think we
> > should do it via some more deliberate and obvious method than pulling
> > systemd-sysv in via the dependency tree of some random package.  The
> > partial upgrade UX for that is really bad, IMO.
> 
> I agree completely that it doesn't make sense for the transition from
> sysvinit to systemd to take place via libpam-systemd rather than via
> some core package like "init", not least of which because that would
> mean systems with desktops or certain daemon packages installed would
> get transitioned to systemd but other systems would not.
> 
> However, as far as I can tell, I think we've actually solved that
> problem: wheezy systems with sysvinit installed will upgrade to the
> transitional "sysvinit" package, which depends on "init", which depends
> on "systemd-sysv | sysvinit-core | upstart".  Between that and "init"
> being "Essential: yes" (which causes apt to try to install it on
> all upgrades to jessie), that *should* cause a transition to
> systemd-sysv.
> 
> Now, that's not quite optimal yet.  Michael Biebl is currently working
> on a plan to have fallback boot options available in GRUB that will boot
> to sysvinit when both are installed, and that would require having both
> systemd-sysv and some sysvinit package (not clear which one) installed.
> (This could support other bootloaders as well, and systems not
> explicitly covered could still explicitly boot with
> init=/lib/sysvinit/init on the kernel command line.)

Correction to this part of my mail: /lib/sysvinit/init is provided by
the sysvinit package, which will remain installed in an upgrade from
wheezy to jessie.  So, this already works, apart from the automatic
entries in the grub bootloader.  My apologies for suggesting that there
was more to do there in terms of package dependencies.

I just tested this by installing a wheezy "minbase" chroot with
debootstrap and upgrading it to jessie.  This installed systemd-sysv via
"init", left sysvinit installed, and /lib/sysvinit/init existed for use
as a fallback init.  At no time was libpam-systemd installed.

> Nonetheless, as far as I can tell, libpam-systemd is *not* the package
> driving the systemd transition anymore.  Does that address your concern,
> Russ?
> 
> - Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140918185054.GA9424@jtriplet-mobl1

Bug#746578: Reasons to keep systemd-sysv as the first alternative

[Josh Triplett]

On Thu, 18 Sep 2014 11:09:18 -0700 Russ Allbery  wrote:
> I conceptually dislike the user experience of switching init systems
> because the user upgraded some random package that, from their
> perspective, doesn't appear related to the init system.  I feel like
> switching init systems should be a more intentional action than that.
> There is a variety of local customization that is init-system-specific,
> and I'm dubious that we're going to be able to catch and warn about all of
> it.
> 
> I've not made up my mind about the merits of switching init systems from
> sysvinit to systemd during a dist-upgrade, but if we do that, I think we
> should do it via some more deliberate and obvious method than pulling
> systemd-sysv in via the dependency tree of some random package.  The
> partial upgrade UX for that is really bad, IMO.

I agree completely that it doesn't make sense for the transition from
sysvinit to systemd to take place via libpam-systemd rather than via
some core package like "init", not least of which because that would
mean systems with desktops or certain daemon packages installed would
get transitioned to systemd but other systems would not.

However, as far as I can tell, I think we've actually solved that
problem: wheezy systems with sysvinit installed will upgrade to the
transitional "sysvinit" package, which depends on "init", which depends
on "systemd-sysv | sysvinit-core | upstart".  Between that and "init"
being "Essential: yes" (which causes apt to try to install it on
all upgrades to jessie), that *should* cause a transition to
systemd-sysv.

Now, that's not quite optimal yet.  Michael Biebl is currently working
on a plan to have fallback boot options available in GRUB that will boot
to sysvinit when both are installed, and that would require having both
systemd-sysv and some sysvinit package (not clear which one) installed.
(This could support other bootloaders as well, and systems not
explicitly covered could still explicitly boot with
init=/lib/sysvinit/init on the kernel command line.)

Nonetheless, as far as I can tell, libpam-systemd is *not* the package
driving the systemd transition anymore.  Does that address your concern,
Russ?

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140918183435.GA2380@jtriplet-mobl1

Bug#746578: Reasons to keep systemd-sysv as the first alternative

[Russ Allbery]

I conceptually dislike the user experience of switching init systems
because the user upgraded some random package that, from their
perspective, doesn't appear related to the init system.  I feel like
switching init systems should be a more intentional action than that.
There is a variety of local customization that is init-system-specific,
and I'm dubious that we're going to be able to catch and warn about all of
it.

I've not made up my mind about the merits of switching init systems from
sysvinit to systemd during a dist-upgrade, but if we do that, I think we
should do it via some more deliberate and obvious method than pulling
systemd-sysv in via the dependency tree of some random package.  The
partial upgrade UX for that is really bad, IMO.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87iokkyf5d@hope.eyrie.org

Bug#746578: Reasons to keep systemd-sysv as the first alternative

[Josh Triplett]

I'd like to call attention to a few reasons why libpam-systemd should
continue to depend on "systemd-sysv | systemd-shim".

First, see bugs like 761389 (and others on cgmanager and systemd-shim),
which are still popping up regularly.  While I acknowledge that people
are actively working on the shim stack, far fewer people work on or test
that stack (or have a reason to care about that stack) than on the
systemd stack, and that stack is continuously playing catch-up based on
new systemd development.  As a result, it will inevitably encounter more
issues than the systemd stack.  That's not an argument to drop that
stack, but it *is* an argument to not make it the default.  I don't
think it's reasonable to consider the shim stack a more "natural" change
from sysvinit; people argue for sysvinit based on legacy/maturity/etc,
but the shim stack introduces a significant amount of new machinery
with far *less* maturity, legacy, or testing than sysvinit *or* systemd.

Second, the technical committee *already* decided to make systemd the
default init system.  This seems like yet another attempt to seize an
opportunity to erode or undermine that decision.  (I anticipate many
more such attempts in the future.)  The technical committee decision did
not say "default only for new installs, with upgrades using sysvinit",
for instance.

Third, there's already a proposal on -devel to detect potentially
problematic situations on upgrade (such as hand-edited /etc/init.d
scripts that would be superseded by un-edited .service files), and
prompt in that situation.  Such a prompt would be similar to the
existing prompts obtained when attempting to remove the package for the
running kernel; they're not the most elegant approach around, but they'd
address many of the concerns regarding more intricate sysvinit setups
that would need manual intervention for a smooth upgrade.  That would
then avoid introducing a prompt for *all* systems, even those that can
smoothly upgrade with no issues.

I would advocate for implementing the prompting proposal, and keeping
systemd-sysv as the first (preferred) alternative in libpam-systemd's
dependencies.

(Though, if a one-time unconditional prompt about upgrading to systemd
would serve as suitable warning, I'd advocate for that; however, somehow
I doubt that step would actually satisfy people calling for systemd's
head.)

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140918153431.GA14232@thin