Bug#746578: libpam-systemd to flip dependencies - proposal
On Tue, Nov 04, 2014 at 08:17:52PM +0100, Christian Seiler wrote:
> 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.
No, I agree with you; it doesn't seem excessively problematic by itself,
and it may or may not actually be a good argument against the proposed
resolution.
> > 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).
Well, one obvious approach: make either systemd-shim or cgmanager
"Conflicts: systemd-sysv". However, that seems overly harsh, and breaks
the case of booting an alternate init system via the init= command-line
argument.
> >> 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
Well, ugh. Bad apt, no biscuit.
This seems much more problematic to me. I *expected* apt to say "well I
need to install the Essential init package, which pulls in systemd-sysv,
which satisfies libpam-systemd". But apparently apt resolved all the
dependencies simultaneously and ignored alternative dependencies.
(Presumably if you had systemd-sysv installed in wheezy this wouldn't
happen, but that's not an interesting case, nor does it need this kind
of test to confirm that.)
I wouldn't necessarily suggest using this as an argument against the
proposed resolution. Instead, I'd recommend making sure that cgmanager
is just as harmless under systemd as systemd-shim 8-4 currently is, by
making it not run under systemd. That would make this change much
safer.
> 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.
Thank you *very* much for your work.
- Josh Triplett
Reply to: