Le mercredi 20 mai 2015, 15:20:52 Daniel Kahn Gillmor a écrit : > The change is: > > * python-qrcode used to include /usr/bin/qr (and its associated > manpage) > > * in the new configuration, python3-qrcode ships this binary. > > 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. Hi,
You could let python-qrcode "recommends" python3-qrcode, so that most users that haven't disabled 'install-recommends' get it automatically and get the /usr/bin/qr they are used to; other could still overide this (deselect it in aptitude TUI for example). This problem is not python specific at all; here is an other example: the doom engine chocolate-doom will be split in 4 package; so that chocolate-doom proper can move to main while c-strife|heretic|hexen remain in contrib. To ease upgrades, the new chocolate-doom will recommends the other 3 spun-off packages. http://anonscm.debian.org/cgit/pkg-games/chocolate-doom.git/tree/debian/changelog Alexandre Detiste -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
