Web lists-archives.com

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

On 09/08/2018 08:18 PM, Sylvestre Ledru wrote:
> Hello,
> Le 08/09/2018 à 18:39, Sean Whitton a écrit :
>> Hello,
>> On Fri 07 Sep 2018 at 10:10PM +0200, Ruben Undheim wrote:
>>> However, I think the policy gives us a lot of freedom to choose (it is not very
>>> strict in this case).
>> I don't understand.  This seems pretty strict:
>>     Two different packages must not install programs with different
>>     functionality but with the same filenames.
> I think the policy should be changed.
> It was possible to accommodate that when the archive was a few thousand packages.
> Now that it is much bigger, that floss are everywhere, packages are being forked,
> we might want to update the policy to give more flexibility.

If by more flexibility, you mean allowing packages to conflict, I'm all
against it. I would loose trust in Debian.

By the way, forks aren't a problem, it means both packages provides the
same functionality.

> For example, in the Rust team, we have been discussing about packaging fd (a find alternative developed using rust [1]).
> We are planning to install it in /usr/bin/fd .. but this conflicts with something completely different, fdclone a clone
> of fd, a MS-DOS file browser...

fdclone isn't a shell utility, you just start it once, then you use its
ncurse-like interface. Renaming it /usr/bin/fdclone wouldn't be a
problem at all, and would be useful if you need to use /usr/bin/fd,
which may be useful in shell scripts (which means you need a specific
name so that examples one may find online can work in Debian).

> 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.

I really prefer this over allowing file collisions.


Thomas Goirand (zigo)