Re: Using update-alternatives for /usr/bin provided binaries
On Tue, Oct 15, 2013 at 11:19 AM, Thomas Goirand <zigo@debian.org> wrote:
> You will *not* find any upstream source code that will be using
> /usr/bin/python2-coverage or /usr/bin/python3-coverage. Absolutely all
> of them will be using /usr/bin/coverage (if they need the command line
> tool). Thinking that you will be able to patch all of them is both an
> illusion and a waste of time IMO.
What sort of upstream "source code" would be using the /usr/bin
wrapper at all? (I ask this question without prejudice; I can
obviously imagine some ways this might happen, but I'm more interested
in the actual existing use cases that you implied, not ones that only
exist in my imagination)
>> * The name ‘/usr/bin/coverage’ is, IMO, far too generic to claim in
>> Debian for a Python-only development tool.
>
> While I agree in principles, there is, so far, no other package that
> claims this file. You can use "apt-file search /usr/bin/coverage" to
> check for this. The problem is that *upstream code* is using
> /usr/bin/coverage. So unless you explain this to upstream and have the
> issue fixed over there, and have it fixed in the pypi package, you
> cannot expect downstream code (users of python-coverage) to use anything
> else.
I think this is ultimately the problem of whichever package comes
second, not python-coverage. (cf. other examples of name collisions,
like ack/ack-grep)
> Also, if there was another package that were using /usr/bin/coverage, it
> could also use the update-alternatives thing (if it's implementing the
> same thing, of course... otherwise we have a problem).
Presumably it would /not/ be implementing the same thing.
Reply to: