Re: Using update-alternatives for /usr/bin provided binaries
On 10/15/2013 02:39 PM, Ben Finney wrote:
> My disagreement is several-fold:
>
> * The binary package ‘python-coverage’ is for Python 2, and
> ‘python3-coverage’ is for Python 3. These are, as I understand it,
> deliberately treated as distinct runtime systems in Debian's Python
> world.
>
> So is it correct for both of them to attempt to provide the same
> command, when in most Python packages we're deliberately naming
> development tools to have Python 3 explicitly a separate runtime
> system?
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.
If we have update-alternatives, then it's very easy for a maintainer to
choose which one of the 2 implementation it wants:
Build-Depends: python-coverage
Build-Conflicts: python3-coverage
if you need /usr/bin/coverage to be python-coverage, or:
Build-Depends: python3-coverage
Build-Conflicts: python-coverage
if you want /usr/bin/coverage to be the python3-coverage implementation.
That's easy enough. Also, with priorities like I wished to set,
python-coverage (eg: Python 2) was the preferred implementation.
> * If we're not going to have Python 2 and Python 3 packages attempt to
> provide the same command name, there doesn't seem much point using the
> Debian alternatives system. A symlink, as is already used in existing
> releases of the package, should be sufficient.
There's no symlink in /usr/bin/coverage in the current package.
> * 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.
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).
> This was the reason for
> renaming the binary ‘/usr/bin/python-coverage’ in every Debian release
> of the package so far.
If you went into renaming the *source* package of python-coverage, then
IMO you wasted your time. There's never a problem with source package
name conflicts in Debian (I mean other than having things look nice,
there's no technical problem), only with the resulting binaries and the
files that they include.
>> We both didn't want to hold the update of python-coverage which was
>> really overdue: the last upload was from 2012-05, and version 3.6
>> (required for many packages) was released early last January. So I
>> went ahead and sponsored the upload of python-coverage 3.7.
>
> I'm really glad to see this, and thanks to Thomas for agreeing to get
> Coverage 3.7 into Debian separately from this mostly-unrelated issue.
:)
Let's hope it passes the NEW queue fast.
>> Though, #726255 still needs a resolution, and I would like to have the
>> view of other Python module maintainers. Is using update-alternatives
>> the way to go? Was my commit correct? Is there any other (better) way to
>> do things here?
>>
>> Please let both Ben and I know your view.
>
> Likewise. (I'm subscribed to this forum, and AFAIK Thomas is also, so
> no need to Cc us on the discussion.)
Agreed, also because that's the Debian list code of conduct to not do so
unless requested.
Thomas
Reply to: