On 10/13/2013 08:24 AM, Ben Finney wrote:
> On 12-Oct-2013, Thomas Goirand wrote:
>> On 10/11/2013 01:42 PM, Dmitry Shachnev wrote:
>>> Also, you have a typo in postinst files ('coverate' != 'coverage').
>>
>> This seems to be changed (by ben), though there's now other problems in
>> the bzr version.
>>
>> […]
>> Setting up python-coverage (3.7+dfsg.1-1) ...
>> update-alternatives: error: alternative link /usr/bin/coverage is
>> already managed by python-coverate
>> dpkg: error processing python-coverage (--install):
>> subprocess installed post-installation script returned error exit status 2
>
> That error is reporting an existing “python-coverate” name managing the
> command. This is only going to be a problem on systems that have that; the
> released package won't have that. You can fix it on yours by deleting that
> association.
Yes, this was an typo/error I did. If any of us has this on his system,
then a manual update-alternatives --remove should be performed. I had to
do this myself. I'm sorry for my mistake, though that's (now) completely
unrelated to the package we have in BZR (eg: it's fixed...).
>> First, Ben changed from /usr/bin/coverage to /usr/bin/coverage3 in the
>> python3-coverage.postinst. This loose the point! The point was to be
>> able to have python-coverage and python3-coverage both provide
>> /usr/bin/coverage...
>
> Python 2 and Python 3 are being sdtrictly treated as separate run-time
> systems in Debian.
This is the case, the only thing is that, both should provide
/usr/bin/coverage.
> So my position is that ‘/usr/bin/coverage’ should not be
> provided for Python 3.
It must be, because that's what upstream code is expecting.
>> If you want python3-coverage to provide a /usr/bin/coverage3, you do not
>> need to use update-alternative. Simply add a symlink and we are good to
>> go.
>
> Okay. So I shall remove the use of ‘upsate-alternatives’ altogether.
Please don't. 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.
Now, I've seen that you've just *deleted* the
python{3,}-coverage.{postinst,prerm}. That's not cool... :( I would
appreciate if you could first try to understand what I'm trying to do
before just flushing my enhancement? Going back and forth is a loss of
time. :/
Since you seem really motivated to remove that, I will state it once more:
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.
>> Also, Ben replaced what I wrote by:
>>
>> master_link_path=/usr/bin/coverage
>> package_name=python-coverage
>> alternative_path=/usr/bin/python2-coverage
>> priority=200
>>
>> update-alternatives --install ${master_link_path} ${package_name} \
>> ${alternative_path} ${priority}
>>
>> which is wrong.
>
> Does it behave incorrectly? How?
It does behave incorectly! 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.
>> link is the generic name for the master link
>> name is the name of its symlink in the alternatives directory
>> path is the alternative being introduced for the master link.
>>
>> Never, the man page talks about a package name, but about the name of
>> the link in /etc/alternatives.
>
> Right. I'm making clear, with the above, that the package name is being
> used as the name of the link in the alternatives directory.
Well... *no* !!! :)
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.
>> Also, Ben, please do not add new variables if they are used only once.
>
> I do not agree with that. Variables are useful for making explicit the
> *meaning* of a value where it is used. So I'll continue to set variables
> where they give a meaningful name to a value to make the packaging
> configuration sufficiently explicit.
I was almost certain you would reply exactly that. And I do not agree
with this view. For having meanings of the parameters of a shell
command, you can use *comments*, which is what I wrote above the
update-alternatives. Please don't use variables instead of comments.
>> It is also very annoying that you insist in removing the last line of
>> the changelog in the BZR. Doing this, the package can't build, as
>> dpkg-parsechangelog fails. Please don't do that, that's irritating. ! :)
>
> Thanks for the feedback, but I also disagree on this one as detailed
> earlier in bug#635476.
This bug report is huge. I read it already once (a few days ago), and it
took me a long time. Could you be more specific about which part of this
bug report you are referring to?
Cheers,
Thomas Goirand (zigo)
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
