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

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]



Hello Sean,

Sean Whitton wrote on 08/09/2018:
> Hello Sylvestre,
> 
> On Sat 08 Sep 2018 at 08:18PM +0200, Sylvestre Ledru wrote:
> 
>> Renaming binaries is a big pain, it is confusing for the user, making the life of the maintainer
>> harder, the documentations won't reflect the Debian-reality.
>>
>> The wording should be changed from "must" to "should":
>> ---
>> Two different packages should not install programs with different
>> functionality but with the same filenames.
>> ---
>> and give more flexibility to maintainers.
>>
>> Or am I missing a key reason for this?
> 
> My understanding is that there are quite deep social reasons for the
> current policy (please note, though, that I was not involved in Debian
> when this piece of policy was created; neither was I involved during the
> nodejs TC decision).
> 
> The current policy protects maintainers and users of less popular
> packages from feeling that their package is less important in Debian,
> just because something else that is more popular comes along and happens
> to use the same name.
> 
> The current policy means that the discussion about which package should
> use the name begins on neutral ground, without prejudice against the
> less popular package.  By requiring that they both change their names if
> agreement cannot be reached, the maintainers put on equal footing.
> 
> To my mind, this is part of our attempt to be "the universal operating
> system".

These are all sensible reasons, and I think the policy has been written
in the way it is after carefully pondering all the options.

However, there are clearly cases where renaming binaries makes several
people unhappy (most likely: the package maintainers, upstream, people
writing scripts, users of different distributions), while not making a
single user happier. This is especially true with low popcon packages
with a small use case intersection.

I find policy too strict on this point, and I would favor it to be
somehow relaxed or allow other options.

Paride

Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: