Bug#746578: More systemd fallout :-/
On Thu, Sep 18, 2014 at 11:59 AM, Josh Triplett <josh@joshtriplett.org> wrote:
> On Wed, 17 Sep 2014 15:34:48 +0100 Ian Jackson <ijackson@chiark.greenend.org.uk> wrote:
>> In #746578, a user requests that the dependency from libpam-systemd to
>> systemd be changed from
>> systemd-sysv | systemd-shim
>> to
>> systemd-shim | systemd-sysv
>>
>> The maintainers of libpam-systemd have rejected this change. I would
>> like the TC to set out the applicable principle(s), and overrule the
>> maintainer in this case.
>>
>>
>> As I understand it from reading the threads in the bug and on
>> debian-devel, the effect of this would be:
>>
>> * New jessie installations would still get systemd.
>>
>> * squeeze->jessie upgrades which are not already using systemd would
>> not be switched silently to systemd but would use systemd-shim
>> instead.
>>
>> * Attempts to upgrade non-systemd systems in some other circumstances
>> would no longer switch silently to systemd.
>
> The latter two points are not actually accurate. I just tested this by
> installing a wheezy "minbase" chroot using debootstrap and upgrading it
> to jessie.
>
> The list of packages installed as part of the wheezy minbase chroot:
>
> apt base-files base-passwd bash bsdutils coreutils dash debconf
> debconf-i18n debian-archive-keyring debianutils diffutils dpkg e2fslibs
> e2fsprogs findutils gcc-4.7-base gnupg gpgv grep gzip hostname
> initscripts insserv libacl1 libapt-pkg4.12 libattr1 libblkid1 libbz2-1.0
> libc-bin libc6 libcomerr2 libdb5.1 libgcc1 liblocale-gettext-perl
> liblzma5 libmount1 libncurses5 libpam-modules libpam-modules-bin
> libpam-runtime libpam0g libreadline6 libselinux1 libsemanage-common
> libsemanage1 libsepol1 libslang2 libss2 libstdc++6
> libtext-charwidth-perl libtext-iconv-perl libtext-wrapi18n-perl
> libtinfo5 libusb-0.1-4 libustr-1.0-1 libuuid1 login lsb-base mawk mount
> multiarch-support ncurses-base ncurses-bin passwd perl-base
> readline-common sed sensible-utils sysv-rc sysvinit sysvinit-utils tar
> tzdata util-linux xz-utils zlib1g
>
> The upgrade:
>
> /# apt-get --no-install-recommends dist-upgrade
> Reading package lists... Done
> Building dependency tree... Done
> Calculating upgrade... Done
> The following NEW packages will be installed:
> acl adduser dmsetup gcc-4.9-base init libaudit-common libaudit1 libcap2 libcap2-bin libcryptsetup4 libdb5.3 libdbus-1-3 libdebconfclient0 libdevmapper1.02.1 libgcrypt11 libgcrypt20 libgpg-error0 libkmod2 libncursesw5 libpcre3 libprocps3 libsystemd-daemon0 libsystemd-journal0
> libsystemd-login0 libudev1 libwrap0 procps startpar systemd systemd-sysv udev
> The following packages will be upgraded:
> apt base-files base-passwd bash bsdutils coreutils dash debconf debconf-i18n debian-archive-keyring debianutils diffutils dpkg e2fslibs e2fsprogs findutils gcc-4.7-base gnupg gpgv grep gzip hostname initscripts libacl1 libapt-pkg4.12 libattr1 libblkid1 libbz2-1.0 libc-bin libc6
> libcomerr2 libgcc1 liblocale-gettext-perl libmount1 libncurses5 libpam-modules libpam-modules-bin libpam-runtime libpam0g libreadline6 libselinux1 libsemanage-common libsemanage1 libsepol1 libslang2 libss2 libstdc++6 libtext-charwidth-perl libtext-iconv-perl libtinfo5
> libusb-0.1-4 libuuid1 login lsb-base mount multiarch-support ncurses-base ncurses-bin passwd perl-base readline-common sed sensible-utils sysv-rc sysvinit sysvinit-utils tar tzdata util-linux zlib1g
> 70 upgraded, 31 newly installed, 0 to remove and 0 not upgraded.
> Need to get 33.7 MB of archives.
> After this operation, 27.5 MB of additional disk space will be used.
>
> (Including recommends would install a few additional packages, including
> libpam-systemd because systemd Recommends it, but I used
> --no-install-recommends to prove that libpam-systemd was *not* the
> driver of the transition, nor was it involved in the upgrade.)
>
> This transition is driven not by libpam-systemd as suggested in this bug
> report, but by the "sysvinit" transitional package (which depends on
> init) and by moving the "Essential: yes" bit from sysvinit to init.
> Note that that transition was coordinated between the sysvinit, systemd,
> and upstart maintainers, and that the "init" package also supports
> sysvinit and upstart.
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.
Also, although the squeeze/wheezy -> jessie bit Ian wrote seems to be
incorrect, his last point still stands: on a jessie minbase (with init
shifted to !systemd-sysv), if you install libpam-systemd, your init is
changed back to systemd.
So the "systemd-sysv | systemd-shim" bit is either pointless and
redundant (upgrading to Jessie) or actively disruptive (installation
of libpam-systemd on jessie+ systems).
Cheers,
--
Cameron Norman
Reply to: