Re: Using update-alternatives for /usr/bin provided binaries
On 10/15/2013 07:04 PM, Jakub Wilk wrote:> Apparently two (mostly
orthogonal) problems have been squeezed into a
> single bug report:
>
> 1) Is the name /usr/bin/coverage appropriate?
> 2) Can the alternatives mechanism be used to switch between the two
> implementations of the coverage command line tool?
Please let's focus on providing /usr/bin/coverage. I don't really care
by what mechanism, as long as the unit tests are working, and Debian
behaves like upstream coverage package from pypi. We can leave the
implementation details for later. Even if only python-coverage (as
opposed to the python3- version) was providing it, I'd be satisfied.
On 10/15/2013 06:21 PM, Tristan Seligmann wrote:
> 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)
I'm not sure if you're talking about the *full path* bit or what.
Upstream code (or at least, unit tests...) is calling "coverage" from
the standard accessible $PATH.
For example:
zigo@ ~/os/heat/heat heat (debian/havana)# cat tox.ini | grep coverage
python setup.py testr --coverage
Nearly all OpenStack projects are using testrepository. All of them are
using python-coverage. Many python modules are as well, and I had to
patch some of them to avoid the problem (sorry, I can't remember which
one right now...). I would like that it doesn't happen again, and also
that our users (eg: developers trying to find out unit test coverage)
can run the coverage tests without troubles.
>>> * 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.
The thing is, we can bikeshed about what *may* happen *in the future*.
Though right now, there's a problem which I would like to fix. And that
is very easily fixed by providing /usr/bin/coverage, while "ugly
hacking" (because that's what it is about) in all other upstream
projects is a much, much harder task.
Thomas
Reply to: