Your message dated Tue, 29 Oct 2013 11:20:33 +1100
with message-id <[email protected]>
and subject line Re: Bug#726255: Claiming ‘/usr/bin/coverage’ for a
Python-specific programmer tool
has caused the Debian Bug report #726255,
regarding Provide ‘/usr/bin/coverage’ command for ‘python-coverage’ program
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
726255: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=726255
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: python-coverage
Version: 3.4-3
Submitter: Thomas Goirand <[email protected]>
Severity: wishlist
Thomas Goirand requests the ‘python-coverage’ and (upcoming)
‘python3-coverage’ package provide alternatives for the
‘/usr/bin/coverage’ command.
Here is a detailed explanation from Thomas:
=====
This is, as much as I can tell, a standard practice in Debian to do
this. You can for example see it in python-babel, or in
python-waitress.
Let's say I have a package that build-depends on python-coverage |
python3-coverage, and then, on the system I am building on, there's
only python3-coverage installed. Build-dependencies would be
satisfied, though upstream code may want to invoke
/usr/bin/coverage. IMO, you should see this just like with sh with
multiple implementation. By calling /usr/bin/coverage, you are
saying that you don't care which version. If you explicitly call
/usr/bin/coverage3 it is because you want explicitly this one.
[…]
upstream projects do expect /usr/bin/coverage to be there, and
otherwise FTBFS. They don't really care if it is a python2 or
python3 implementation, they just need *one* of the 2
implementation, and /usr/bin/coverage to be present.
Example when building "heat" (one of the OpenStack packages I maintain):
zigo@host ~/sources/openstack/havana/heat/heat$ python setup.py \
testr --coverage
running testr
running=${PYTHON:-python} -m subunit.run discover -t ./ .
No handlers could be found for logger "heat.engine.environment"
/home/zigo/sources/openstack/havana/heat/heat/heat/common/wsgi.py:759:
DeprecationWarning: BaseException.message has been deprecated as of
Python 2.6
exc.message = gettextutils.get_localized_message(exc.message, locale)
/home/zigo/sources/openstack/havana/heat/heat/heat/tests/test_wsgi.py:226:
DeprecationWarning: BaseException.message has been deprecated as of
Python 2.6
self.assertEqual(message_es, e.exc.message)
Ran 3094 (+3024) tests in 54.360s (+54.168s)
PASSED (id=4)
As you see, it works. Now, let's remove /usr/bin/coverage:
zigo@host ~/sources/openstack/havana/heat/heat$ sudo \
update-alternatives --remove coverage /usr/bin/python2-coverage
zigo@host ~/sources/openstack/havana/heat/heat$ python setup.py \
testr --coverage
running testr
running=${PYTHON:-python} -m subunit.run discover -t ./ .
/bin/sh: 1: coverage: not found
======================================================================
FAIL: process-returncode
tags: worker-0
----------------------------------------------------------------------
Binary content:
traceback (test/plain; charset="utf8")
Ran 1 (-1546) tests
FAILED (id=5, failures=1 (+1))
error: testr failed (1)
now it fails because /usr/bin/coverage isn't present.
[…] python-coverage is *not* the name that should be in use for the
symlink in /etc/alternatives. Eg, we don't want
/etc/alternatives/python-coverage, but really
/etc/alternatives/coverage.
[…]
What you want is /etc/alternatives to contain the name of the script
file which we setup as a link in /usr/bin, so that that it can be shared
among multiple programs. Just like we have:
/usr/bin/awk -> /etc/alternatives/awk
/etc/alternatives/awk -> /usr/bin/gawk or /usr/bin/mawk
gawk and mawk are both implementation of the awk program, and are both
using update-alternatives so that they both can provide /usr/bin/awk.
This is what we want to do here, so that, no mater if python-coverage or
python3-coverage is installed, we always have a /usr/bin/coverage
implementation. In this case, there's no /etc/alternatives/gawk or a
/etc/alternatives/mawk, but a single /etc/alternative/awk. We need this
type of implementation exactly.
=====
--
\ “Pinky, are you pondering what I'm pondering?” “I think so, |
`\ Brain, but isn't a cucumber that small called a gherkin?” |
_o__) —_Pinky and The Brain_ |
Ben Finney <[email protected]>
signature.asc
Description: Digital signature
--- End Message ---
--- Begin Message ---
package python-coverage
outlook 726255 The name ‘/usr/bin/coverage’ is too broad for so specific a tool.
tags 726255 + wontfix
thanks
On 16-Oct-2013, Ben Finney wrote:
> I'm glad we discussed this. I haven't seen a convincing argument that
> overrides the consensus here that a Python-specific programming tool
> should not claim the broad name ‘/usr/bin/coverage’ in Debian.
Accordingly, with a solid consensus that ‘/usr/bin/coverage’ is not
appropriate for this tool in Debian, I'm closing this bug report as
“wontfix”.
--
\ “I got a postcard from my best friend, it was a satellite |
`\ picture of the entire Earth. On the back he wrote, ‘Wish you |
_o__) were here’.” —Steven Wright |
Ben Finney <[email protected]>
signature.asc
Description: Digital signature
--- End Message ---
