Bug#935304: Please reconsider. Thanks

Mark Hindley mark at hindley.org.uk
Wed Sep 11 11:53:51 BST 2019

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)


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.


More information about the Debian-init-diversity mailing list