[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#746578: libpam-systemd to flip dependencies - proposal

Am 04.11.2014 17:07, schrieb Josh Triplett:
> This isn't a complete showstopper, since most of the time people seem to
> debootstrap a standard system and then install additional packages.
> However, it would affect a debootstrap with --include=task-desktop or
> --include=gnome or similar.

Just as a side note: I never use debootstrap to actually include
anything that wouldn't be considered 'base system', just because I've
had the experience that quite a few packages don't work together with
debootstrap (try doing --include=syslog-ng (and --exclude=rsyslog) while
debootstrapping wheezy - the dependency resolution works properly, but
the package won't install, because the preinst or postinst scripts don't
like debootstrap's environment (the rsyslog exclude alone works btw., so
that's what I'm doing if I want something with syslog-ng)). I have some
real doubts that debootstrap is going to be able to set up something
like GNOME or task-desktop or whatever, just because they probably are
going to pull in lots of packages of which at least a couple are going
to have similar problems to the aforementioned one I had with syslog-ng.

Therefore, I always tend to use debootstrap to just install a very, very
basic system and then use apt-get in a chroot to install the rest of the
software, if I decide to install a Debian image like that.

This in mind, looking at apt-cache rdepends libpam-systemd[1], I don't
see anything in there I'd want to include in debootstrap. But maybe
that's just me.

> Does anyone see an obvious way to structure the dependencies to avoid
> this result and only install systemd-sysv?

I don't think that's possible if you want to keep the effect the
switching the dependencies has (i.e. selecting systemd-shim as first
alternative so that systems without systemd as pid1 don't try to install
systemd-sysv when packages depending on logind are installed).

>> I haven't tested the upgrade scenario.
> I appreciate the test you already ran.  I'd love to see an upgrade test
> as well (from a system with sysvinit installed), but this test already
> revealed an issue.

 - Fresh install of Debian Wheezy (from netinst CD)
 - tasksel: Standard utilities + SSH server
 - aptitude full-upgrade
 - aptitude install --without-recommends gdm3
    (package that pulls in libpam-systemd in Jessie, without
     installing too much, although gdm3 itself already pulls in
     quite a lot on wheezy, in hindsight probably should have gone
     with network-manager...)
 - Then edit sources.list, remove everything wheezy-related, add my
   modified mirror, apt-get update

Then this gives the following consequences:

  - apt-get upgrade:
          * doesn't try to upgrade enough packages that you could call
            the system jessie, doesn't pull in anything systemd related
            other than trying to upgrade libsystemd-login0 (already
            installed on wheezy because of a Depends of dbus)
  - apt-get dist-upgrade
          * pulls in systemd-shim
  - aptitude full-upgrade
          * pulls in systemd-shim
  - aptitude upgrade (i.e. safe-upgrade)
          * takes a couple of minutes to resolve deps
            (granted, running in a VM, but I have a fast CPU, so
            this is really unusual, never seen aptitude working so
            long before, but OTOH I've never done a dist-upgrade
            with aptitude before, so maybe that's normal?)
          * DOES NOT pull in systemd-shim
  - didn't test any other frontends

(I'm not showing any detailed package lists here because there's just
too much unrelated stuff.)


[1] Depended on by:
        udisks2, policykit-1, network-manager, lightdm*,
        gnome-settings-daemon, gnome-bluetooth, gdm3
Recommended by (not relevant for deboostrap IIRC):
        xfce4-session, xfce4-power-manager, systemd,
        gnome-session-bin, argyll
(* Depends: libpam-systemd | consolekit)

PS: I tested this because I think it's better to have all the relevant
information before deciding an issue, please don't interpret my email as
being critical of the proposed resolution.

Reply to: