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

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



On Wed, 05 Nov 2014 08:42:07 -0500 Sam Hartman <hartmans@debian.org> wrote:
> I don't think this matters for the vote, and apologies because there's
> probably a better place to send this advice.  I was thinking last night
> about the apt and debootstrap resolver issues and  was wondering whether
> the following solution might help.
> 
> I realize the issue is minor and is more about minimizing packages
> installed than safety of the proposal.
> 
> What if libpam-systemd depended on
> systemd-shim-nosysv|systemd-sysv|systemd-shim?
> 
> Introduce a new package systemd-shim-nosysv in the systemd-shim package
> that depends on systemd-shim and conflicts with systemd-sysv.
> 
> I have not tried this.  It might reduce the probability that
> systemd-shim gets uselessly installed.  however, I don't know whether it
> creates systems where systemd-sysv gets removed.

Seems like a great idea to me; we talked a bit about Conflicts in the
context of cgmanager, but this approach (with an artificial intermediate
package) makes much more sense.  I agree that it needs careful testing,
though; after Christian Seiler's testing of debootstrap and apt, I
really don't know how either would decide to resolve this.  Either or
both might well decide to choose the alternate dependency of the
essential "init" package rather than the alternate dependency of
libpam-systemd.

> Even if this does end up being a good idea, I don't think the TC
> resolution needs to change.  As I read it, the essential character of
> the resolution is that systemd-shim is preferred to systemd-sysv in
> libpam-systemd.  If we find better technical ways of doing that, more
> power to us all.  If there is a real disagreement about whether we're
> within the spirit of the TC resolution should it pass, we can ask the TC
> again either informally or formally.  I don't want to see us getting
> ultra-picky about the wording of resolutions to constrain or permit
> future innovation.

I agree; when I suggested clarifying in the TC decision that the Depends
shouldn't be hard-coded (what became clause 6 of the current proposal),
I didn't just have versioned dependency changes in mind, but also
package structural changes (on either systemd's or systemd-shim's part).
I think the suggestion you made above fits entirely within the spirit of
the TC resolution.

- Josh Triplett


Reply to: