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

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?



Matthew Vernon <matthew@debian.org> writes:

> On 14/12/2020 21:56, Philip Hands wrote:
>
>> Could I just check if there's a point of common acceptability which both
>> sides of this discussion could live with?
>
> [...]
>
>> 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
>
> Is this instead of the logind virtual package? I'm not quite sure what 
> problem you're trying to solve here, but I'm don't think it generalises 
> well (you'd end up with potentially lots of package that just Depend on 
> logind and maybe contain an init script); and without any input from the 
> network-manager maintainer about why they were unwilling to take the 
> patch to use the existing virtual package, I'm not sure why this should 
> be more acceptable.

If that were the way things were going, then I'd expect one to end up
with a package that bundled all the init scripts, and provided whatever
virtual packages etc. required to glue all the bits together somehow.

The details of how to do that seemed like things that should be between
the people maintaining the two sets of packages, and I wasn't worrying
about the details too much, because I was rather hoping that it wouldn't
actually be needed.

>> 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.
>
> I'm confused as to why you don't just tell us what your better option is.

My better option was that having defined the areas of responsibility by
thinking about who'd do what in a split package setup, we might manage
to agree that the same people could take the same responsibility for
maintaining those bits in the places where they would need to be in the
packages as they stand.

For that to work, I think the maintainer would have to have the right to
declare that they didn't think the experiment was working out
(presumably because of drowning in bugs that were not being handled in a
sensible time, say) at which point the already agreed split package
setup would provide an acceptable plan B.

That would hopefully allow the maintainer to relax enough about having
some new people co-maintaining some fragments of the package to give
space for everyone to demonstrate that it was possible for them to work
together.

There's nothing specific to NM in any of that BTW, so if other packages
are in this position where constructive cooperation really ought to
work, but there's just a little too much distrust at present, then maybe
you can give this a try there.

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


Reply to: