Bug#935304: libpam-systemd: Please relax Depends: systemd-sysv

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug#935304: libpam-systemd: Please relax Depends: systemd-sysv

Mark Hindley
Package: libpam-systemd
Version: 241-7
Severity: normal

Dear systemd maintainers,

Please would you reconsider libpam-systemd's dependency on systemd-sysv?
This dependency makes switching from libpam-systemd to libpam-elogind on desktop
systems difficult with out removing and the reinstalling many components one
libpam-elogind is installed.

systemd cannot be removed whilst it is PID 1 so sysvinit-core needs to be
installed first and the system rebooted. sysvinit-core conflicts with
systemd-sysv and libpam-systemd depends systemd-sysv. So installing
sysvinit-core forces the removal of anything depending on libpam-systemd
including the majority of many desktops.

I can imagine the original intention of the dependency was to ensure systemd was
the active init. However, even with systemd-sysv installed, it is still possible
to boot with init=/bin/sh on the kernel commandline or change the init in grub
menu. So the dependency fails to ensure systemd is PID 1.

I suggest that Recommends would be a more suitable relationship.

Thanks

Mark

Reply | Threaded
Open this post in threaded view
|

Bug#935304: [libpam-systemd] This bug also prevents KDE Plasma5 Desktop from being used in Buster for SysV init users

Stephen Lyons-2
Package: libpam-systemd
Version: 241-5
Control: severity -1 important

--- Please enter the report below this line. ---

I was using the KDE Plasma 5 Desktop in Stretch but during the upgrade
process to Buster this dependency broke things for me as a SysV init
user as the following dependency chain exists:

plasma-desktop ->
plasma-workspace ->
udisks2 ->
libpam-systemd ->
systemd AND systemd-sysv

The dependency on systemd-sysv did NOT appear in the previous "Stretch"
and I was happy to tolerate systemd on my system as long as it was NOT
PID1 i.e. with a SysV init. This bug thus seems to be a regression in
that I can no longer have this.

As this forces a change of Desktop and all the packages associated with
it I feel this warrants remarking this as an "important" bug and I have
attempted to do so...

Stephen

--- System information. ---
Architecture: Kernel:       Linux 4.19.0-5-amd64

Debian Release: 10.0
  500 stable          security.debian.org
  500 stable          ftp.uk.debian.org
  500 stable          apt.spideroak.com
--- Package information. ---
Package's Depends field is empty.

Package's Recommends field is empty.

Package's Suggests field is empty.
--
To mitigate against EFAIL attacks email messages will be handled only as
plain text, please do not send emails in an HTML form to this recipient!


signature.asc (598 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#935304: #935304: Set severity to important

Svante Signell-2
In reply to this post by Mark Hindley
severity 935304 important
thanks

Michael: Next time you lower the importance of this bug, please give a
motivation. It is not especially instructive doing such a thing without
explaining why.

Reply | Threaded
Open this post in threaded view
|

Bug#935304: #935304: Set severity to important

Michael Biebl-3
Am 10.09.19 um 11:03 schrieb Svante Signell:
> severity 935304 important
> thanks
>
> Michael: Next time you lower the importance of this bug, please give a
> motivation. It is not especially instructive doing such a thing without
> explaining why.

Svante, next you respect the decision of the maintainer, please.

Anyway, I marked this wishlist, wontfix as the dependency is there for a
reason. libpam-systemd is non-functional without systemd as PID 1, so
this dependency will stay and is not optional (recommends)


--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#935304: #935304: Set severity to important

Svante Signell-2
reopen 935304
found 935304 243-1
severity 935304 important
thanks

On Tue, 2019-09-10 at 11:10 +0200, Michael Biebl wrote:

> Am 10.09.19 um 11:03 schrieb Svante Signell:
> > severity 935304 important
> > thanks
> >
> > Michael: Next time you lower the importance of this bug, please give a
> > motivation. It is not especially instructive doing such a thing without
> > explaining why.
>
> Svante, next you respect the decision of the maintainer, please.
>
> Anyway, I marked this wishlist, wontfix as the dependency is there for a
> reason. libpam-systemd is non-functional without systemd as PID 1, so
> this dependency will stay and is not optional (recommends)

Please read the motivation in the bug report for making it a recommends. You
cannot guarantee that systemd runs as PID 1, even with this hard dependency!

Downloading the sources for systemd (241-7~deb10u1, 242-7 and 243-1) and looking
into debian/control one finds:
Package: libpam-systemd
Architecture: linux-any
Depends: ${shlibs:Depends},
         ${misc:Depends},
         systemd (= ${binary:Version}),
         libpam-runtime (>= 1.0.1-6),
         dbus,
         systemd-sysv

Reply | Threaded
Open this post in threaded view
|

Bug#935304: #935304: Remove wontfix tag

Svante Signell-2
In reply to this post by Mark Hindley
tags 935304 -wontfix
thanks

Reply | Threaded
Open this post in threaded view
|

Bug#935304: Please reconsider. Thanks

Mark Hindley
In reply to this post by Michael Biebl-3
On Tue, Sep 10, 2019 at 11:10:52AM +0200, Michael Biebl wrote:
> Anyway, I marked this wishlist, wontfix as the dependency is there for a
> reason. libpam-systemd is non-functional without systemd as PID 1, so
> this dependency will stay and is not optional (recommends)

Michael,

I would like to ask you to reconsider this.

Obviously you are correct that libpam-systemd is not functional without systemd
as PID 1. However, the same argument is true of systemd itself, which does not
depend on systemd-sysv.

It is also possible to bypass systemd-sysv altogether and boot a system with a
different init on the kernel command line.

If you were to agree to reduce this dependency to recommends, libpam-systemd
would still pull in systemd-sysv in all normal circumstances of invoking APT.

The removal of systemd-sysv can only be specifically requested by installing
another init. Even after this has happened, systemd is still running and
libpam-systemd is still functional. Only after a reboot is libpam-systemd non
functional (as is systemd itself) , but by that stage the sysadmin is clearly
set on using a non-systemd init and can complete the migration to whatever
configuration s/he desires.

So, my conclusions are

 - the libpam-systemd dependency on systemd-sysv doesn't actually ensure that
   systemd is actually PID 1.

 - if the libpam-systemd dependency on systemd-sysv were reduced to Recommends,
   systemd-sysv would still be installed by APT in all normal scenarios.

 - the libpam-system dependency on systemd-sysv makes migration from systemd to
   another init/logind combination significantly more difficult than it need be
   by forcing the removal of many GUI components.

 - the removal of systemd-sysv system running libpam-systemd as part of changing
   inits does not impact libpam-systemd functionality until after a reboot.

Thank you for reconsidering.

Mark

Reply | Threaded
Open this post in threaded view
|

Bug#935304: Please allow Cooler Heads to Prevail

Sam Hartman-5
In reply to this post by Mark Hindley
control: severity -1 wishlist
control: tags -1 wontfix

Dear Svante:

By repeatedly manipulating the severity of the bug, by removing the
wontfix tag,  you are adding flames to a fire that does not need them.

We have procedures for disagreeing with a maintainer's approach to a
bug, and revert wars are not the right answer.
Revert wars of this type will always increase friction, and this
situation does not need additional friction.
I believe revert wars are almost inherently incompatible with respectful
use of the BTS.

In this particular instance, I think your message would  have been much
more constructive if you had not manipulated the bug metadata and simply
asked Michael to explain why he reduced the severity.


In a number of bugs I've seen Mark being entirely reasonable and
professional.  Before Michael can respond, others jump in and increase
the flame level significantly.  If I were Michael, I might well not want
to engage if I was going to face all that even if I were happy to try
and discuss the issue with Mark.

I'd like to try and recommend a way forward.  Have a private discussion
among the more level-headed people on both sides of this issue and see
if we can figure out what the options and possibilities are.

Explore the implications of options including:

1) relaxing this dependency

2) Finding other ways to do the upgrade

3) Accepting that the upgrade cannot be done with a desktop installed

4) Discovering that we've reached a point where we're in conflict about
Debian's interest in supporting sysvinit and that the project needs to
be asked questions

I think it would be quite valuable for people on both sides to have a
shared understanding on the implications of changes we could make even
if they don't agree on how they would balance these trade offs.


I will follow up with Michael and Mark individually and see if they
would be willing to be part of such a discussion

--Sam

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#935304: libpam-systemd: Please relax Depends: systemd-sysv (was: Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful) (fwd)

Cristian Ionescu-Idbohrn
In reply to this post by Mark Hindley
Bummer...  Sorry, was #935304 it was aimed for.

---------- Forwarded message ----------
Date: Sun, 29 Sep 2019 11:00:10 +0200 (CEST)
From: Cristian Ionescu-Idbohrn <[hidden email]>
To: [hidden email]

On Sun, 29 Sep 2019, Mark Hindley wrote:

> On Sat, Sep 28, 2019 at 11:41:56AM +0200, Thorsten Glaser wrote:
> > On Sat, 28 Sep 2019, Cristian Ionescu-Idbohrn wrote:
> >
> > > 1. install sysvinit-core; that removes systemd-sysv but nothing else
> > >    systemd related
> >
> > > Souldn't that work?
> >
> > It would, if but for libpam-systemd having a (somewhat questionable
> > but understandable) dependency on systemd-sysv. This is basically
> > what spawned this thread.
> >
> > So we'll not be going there.
>
> Thorsten is quite right.
>
> There is already a separate bug concerning the libpam-systemd
> systemd-sysv dependency. See https://bugs.debian.org/935304. That
> would be a more appropriate place for you to add any comments you
> may have regarding this aspect of the behaviour you have observed.

Following Mark's advice, here are my findings:

On Sun, 29 Sep 2019, Cristian Ionescu-Idbohrn wrote:

>
> Right.  I see now what happens on my systems.  I have an older
> version of systemd packages installed:
>
> ,----
> | Version: 238-5
> `----
>
> which depends on:
>
> ,----
> | systemd-shim (>= 10-3~) | systemd-sysv
> `----
>
> as I stopped systemd related package updates:
>
> ,---- [ /etc/apt/preferences.d/no-systemd ]
> | Package: systemd systemd-sysv systemd-sysv:i386 libsystemd0 libpam-systemd
> | Pin: release o=Debian
> | Pin-Priority: -1
> `----
>
> at the point when systemd-shim was removed.

Does it mean that, in my case, the transition to elogind would be
easier?


Cheers,

--
Cristian