Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]
Russ Allbery wrote on 09/09/2018:
> 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 agree, and in fact I don't suggest Conflicts right away (though I
think it can be the best solution in some cases).
> 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 would certainly work, but as you say it is still irritating. I like
the idea of putting the binaries in a different directory *and*
providing a "name compatibility package", as it has been already
suggested. This package would provide the symlinks in /usr/bin and set
the needed Conflicts. In this way we allow both packages to be installed
at the same time while leaving the users enough freedom to chose what to
have in their PATH.
As we want the packages to be discoverable, I would name them something
like this:
<package>-debcompat (for "compatible with the other Debian packages"):
installs binaries in /usr/share/<package>/bin, does not set Conflicts,
warns the user in the Description, Suggests <package>.
<package>: installs the /usr/bin symlinks, sets the required Conflicts,
depends on <package>-compat.
I would avoid the "-legacy" suffix, as it suggests that something is
outdated.
A "first come best served, modulo a different debian-devel consensus,
modulo CTTE" policy could be good enough to decide which package
deserves to install the "real" binary in /usr/bin.
We have to recognize that there is no perfect solution here. If we
enforce the rename it will often be a big hassle for several people for
a little gain while still leaving room for ambiguity (e.g. user set-up
aliases and symlinks). On the other side if we allow Conflicts to be
always used we will end up having useful but incompatible packages. I
think the best compromise is somewhere in between.
Paride
Reply to: