On Tue, Oct 15, 2013 at 11:19 AM, Thomas Goirand <z...@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. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAMcKhMShx87_d8dR=ouos+cfct_qhetx7hz+d6egli9dmbe...@mail.gmail.com
