[py3porters-devel] Bug#782762: python-qrcode: Please add python3 package

[Stuart Prescott]

Hi all,

Thanks for the comments.

> > * move to pypi.debian.net instead of chasing pypi upstream pages
[...]
> > -opts=pgpsigurlmangle=s/$/.asc/
> > https://pypi.python.org/packages/source/q/qrcode/qrcode-(.*).tar.gz
> > +opts=pgpsigurlmangle=s/$/.asc/
> > http://pypi.debian.net/qrcode/qrcode-(.*).tar.gz
> This moves from an https URL to a cleartext http URL.  This seems like
> an overall loss to me, even at the cost of "chasing" pypi a bit.  I'd
> generally prefer to stick with the secure URL.  If pypi isn't being
> stable, maybe we should ask them if they can try to stabilize?

The download is still gpg signed and I'd trust the gpg signature in preference 
to an https URL.

The "fixed" version of pypi that is claimed to provide stable URLs is hideous 
to work with:

	https://pypi.python.org/packages/source/q/qrcode/

(the embedded md5sum in the URLs makes for a tedious regexes that no human 
should be required to write or understand).

As an aside, we see places like sourceforge, pypi, bitbucket etc breaking 
uscan on a regular basis which then requires us to update 4-digit numbers of 
packages. I'd rather have the single point of failure under our control (so we 
fix pypi.d.n once to deal with a new setup) rather than having to update 1000 
packages again.

> I note you didn't update the debhelper version requirements (or
> debian/compat) to 9, as recommended in
> 
>  https://wiki.debian.org/Python/LibraryStyleGuide

There are no practical benefits to doing so for this package, but yes, it may 
as well be updated. Yes, we should include a versioned dependency on debhelper 
just in case someone wants to backport to squeeze.
 
> I also note that the updated d/rules doesn't include PYBUILD_NAME, which
> i understood was a necessary value to export.

There is no requirement to do that. The style guide linked to above implies 
you do but in practice you do not. From the pybuild man page:

      · if  more  than  one  binary  package is build: add
         debian/python-foo.install files, or export
         PYBUILD_NAME=modulename  (modulename  will  be  used  to
         guess  binary package prefixes), or export PYBUILD_DEST‐
         DIR env. variables in debian/rules

I have done the first of these; the *.install files were going to be necessary 
anyway for the multiple binary packages and for qr(1).

> > + This package contains the Python 2 module; the command line tools are in
> > + the python3-qrcode package.
> 
> This is the biggest possible change to the package, and i'm not sure
> what to do about it.

Likewise and it's a FAQ in this porting process for which there is no really 
good answer; the only nice situation is where there is a separate package with 
binaries in addition to the modules.

> This means that someone who has installed python-qrcode for the purposes
> of using /usr/bin/qr might be surprised to find that interface disappear
> from their system.  I don't think there are any debian packages that
> have this dependency (the only rdepends are python-freeipa and keysync,
> which i think use the python modules and not /usr/bin/qr) but it's
> conceivable that some user had installed it this way and is now bummed.
> 
> Python3 porters: what is the right way forward for packages like this?
> 
> If we decide on a case-by-case basis, what is a reasonable rule of thumb
> to follow?
> 
> I'm tempted to say that for this package, with its few reverse
> dependencies, and no explicit use of /usr/bin/qr that i can see, we can
> just move the script from python-qrcode to python3-qrcode.

Agreed. That was my feeling in making the move in this case; I also looked at 
popcon of python-qrcode and decided that the number of people with pitchforks 
wouldn't be enormous (while recognising that there would indeed be some people 
who would have pitchforks...).
 
> Alternately, we could have some sort of alternatives system so they
> could both provide the script, but this seems like it would be overkill.

I'd say use of the alternatives system would only make sense if the local 
admin actually cared about which particular implementation was used.

There are two additional alternative options:

* make a "qr" package that depends on python3-qr and ships only the 
/usr/bin/qr [1]. This separate package doesn't actually solve the upgrade 
problem though... to provide an upgrade path, we'd be making a Replaces on the 
python-qr package and there would also need to be a link to cause apt to 
install the new package. That link would mean that installing a Python 2 
package caused Python 3 to be installed which is clearly wrong.

* both python-qr and python3-qr ship /usr/bin/qr but with some sort of dpkg-
divert dance in their maintainer scripts. (Give ownership of qr(1) to the 
python3 package and divert the other one to qr-python2 or similar.) This would 
work but also feels a bit fragile.

> I'm inclined to push changes like this (including Stuart's edits, and
> the move of /usr/bin/qr to python3-qrcode) to collab-maint and prepare
> an NMU once i've had the chance to test them.

I'm obviously comfortable with that :) I've got combinations of python-qrcode 
and python3-qrcode installed on a couple of different machines for my own use 
-- I wanted python3-qrcode because I was starting new projects in Python 3 and 
hitting at roadblocks when I found them. This was an itch being scratched.

cheers
Stuart

[1] Our ftp-masters have previously indicated that they'd like packages to 
ship more data than metadata which is fair enough, but at the same time the 
separate package would have been the "right" thing to be do for many of our 
python module packages that also happen to ship an executable. That we have 
not been using separate binary packages for the executable and the module 
means that users have had to care about implementation details (which version 
of python is qr(1) using?) and is precisely why we have this problem now. 

-- 
Stuart Prescott    http://www.nanonanonano.net/   stuart at nanonanonano.net
Debian Developer   http://www.debian.org/         stuart at debian.org
GPG fingerprint    90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/py3porters-devel/attachments/20150521/fbb9531c/attachment.sig>