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

[Steffen Möller <steffen_moeller@gmx.de>]

Hello,

On 09.09.18 02:11, Russ Allbery wrote:
> Paride Legovini <pl@ninthfloor.org> writes:
>
>> 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.
> If the packages conflict, though, this is extremely unfriendly to the
> users who do want to use both packages.  They cannot use both packages on
> the same OS installation, and have to resort to chroots or VMs or
> containers, which is a lot of extra complexity.  I'm therefore in favor of
> keeping Policy's prohibition on using Conflicts for this case; maybe a
> combination of two packages will get lucky and there will be literally no
> users who want to use both at the same time, but it's very hard to tell
> when that's the case and the failure mode is ugly.
>
> I kind of like the solution of putting the binaries in a different
> directory.  This is also a little irritating, since users have to add an
> additional directory to their PATH, but they only have to do that once and
> it works consistently going forward, and they can still use the other
> program.
>
> It's not totally unheard of to have to modify PATH to use a package,
> particularly one that wants to use a bunch of very generic command names.
> That was always the official way to use MH, for example.

You may be referring to some alike http://modules.sourceforge.net/  ; And
yes, I personally would not mind if Debian packages would have an option
to install into such a module. Actually, this would even help a lot for
the parallel installation of multiple versions of the same
library/binary, which is not uncommon in scientific workflows (sadly).

It seems like I am a bit in a minority position here. And it hurts me to
contradict all those folks who one respects for all the good work they
do. Anyway, in my very humble and personal opinion, the policy of not
having conflicts makes perfect sense for anything that is essential to
have. But for anything optional, well, that conflict is optional, too.
We should allow ourselves to rely more on upstream's communities to take
care not to conflict with names. That is because they talk with each
other and most likely they have an idea what they talk about. If someone
happens to be in two such communities then Debian makes it easy enough
for everyone to just install a package quickly when this is needed and
to then deinstall it when that tool's execution's purpose is done. I
mean, this is why we are doing this all after all. We should take some
pride in what we achieved and tell people to use our package managers
when conflicts arise as a dear exception. Conflicts are natural. We
should find a way to deal with them and not come up with a dysfunctional
world of compromises that annoys by default and not just as a
theoretical construct. Also, I think we can rest assured, if communities
have not talked and named binaries the same, then the conflicts between
the respective packages is what will help to persuade those communities
to adjust their naming.

Cheers,

Steffen