Re: Using update-alternatives for /usr/bin provided binaries
On Tue, Oct 15, 2013 at 1:47 PM, Thomas Goirand <zigo@debian.org> wrote:
> 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
Does this really invoke /usr/bin/coverage, as opposed to just
importing the coverage module (I'm not familiar with testrepository)?
I would have expected most Python tools to just import the module,
rather than spawning the wrapper as an external process, hence my
original question. (In fact, how would that invocation even work
correctly, if it's running with whatever interpreter the `coverage`
wrapper uses, rather than the interpreter you invoked setup.py with?)
> 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.
I agree with this; if a naming conflict develops in the future, I
don't think renaming things then will be any harder than renaming them
now is, and if a conflict never develops, there isn't an issue to
begin with.
--
mithrandi, i Ainil en-Balandor, a faer Ambar
Reply to: