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.
Cheers,
Thomas Goirand (zigo)
Reply to: