Sean Whitton <spwhitton@spwhitton.name> writes: > It is difficult to think further about this without input from the > maintainer as to how much this was a part of his motivation, and what > experiences he has had led him to think in that way. Hi All, Could I just check if there's a point of common acceptability which both sides of this discussion could live with? Please don't assume that I'm offering this as a preferred outcome. I would hope that we can come up with something better than this, but I think that agreeing that this is an acceptable and achievable baseline would provide a foundation on which to build something better. My suggestion for a mutually bearable solution would be that the network-manager package could have its dependency on libpam-systemd changed to instead be something like: libpam-systemd | network-manager-nonsystemd and that the init diversity folks could then take responsibility for satisfying that optional dependency as they see fit in order to keep network-manager available on non-systemd systems, which should insulate the network-manager maintainer from almost all of the effort involved. I say 'almost all' because I would imagine that non-systemd-related bugs might be reported against network-manager occasionally, and need to be reassigned, and one could also imagine that upstream might change things in a way that was clearly going to break things on non-systemd systems, in which case it would be polite if the network-manager maintainer would open a bug mentioning that change against the network-manager-nonsystemd package, etc. If you think this approach is impractical for some reason, please say so, because what I have in mind as a better option does rather rely on this being available as a plausible fall-back position. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/ http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg, GERMANY
Attachment:
signature.asc
Description: PGP signature