> Von: Gianfranco Costamagna [mailto:locutusofborg@debian.org] > Hi, > > (answering where I can!) >> Moving the code to "/usr/lib/python2.7/dist-packages/aminer" in fact allows >> dh_python2 to extract the version information: >> >> Depends: python:any (<< 2.8), python:any (>= 2.7.5-5~), python-tz, >> init-system-helpers (>= 1.18~) >> >> (Remark: Is there any reason to restrict the versions to >=2.7.5? The tools >> should have compatibility with >=2.6 and I would expect the "Depends" >> section >> to somehow reflect that reality. Is DEBPYTHON_SUPPORTED and >> DEBPYTHON_DEFAULT intended to be used to fix that?) > > that stuff is built for unstable/testing, so the variables are filled > with the current python situation > (2.6 is only on old-stable, and Stretch has 2.7.11 already). > > Probably if you try to build it with a jessie chroot, you get different values, and this is correct. > (you can't in general install deb built against stretch into wheezy/jessie, without > breaking stuff, this is why some dependencies are not too relaxed, to avoid people > doing that, but instead upgrading the minimal set of packages to make sure > things will work after the apt-pinning). > > I don't foresee any issue here, because even in case of a backport, the > package will need to be rebuilt on top of that. OK, so I will not attempt to fiddle with that and stick to the stricter versions. > >But doing the move, lintian will not like the produced package any more: > > > >E: logdata-anomaly-miner: python-script-but-no-python-dep usr/lib/aminer/AMiner > > I can't say, I don't see the package installing stuff in usr/lib/python* on > mentors Maybe the hints from Piotr Ożarowski's followup mail will fix that, using his hints. > >The rationale behind not putting aminer into dist-packages (and removing > >dist-packages from python-path) was: >> [Snip] > > >b) prepare against possible future risks due to accidental loading (call to > >__init__) of other packages residing in dist-packages, that may give rise to > >privilege escalation (like the GNU-TLS CVE from this/last week) > > mmm you want to avoid people importing your library? > > ok Not directly avoid, but make them think more about it before adding. I also remember having issues with some svg-python library, that starts to misbehave as soon as other packages are installed because of "try: import xxx; ..." blocks. Just want to reduce the risks. > >Of course, it should be possible to move the code to > >/usr/lib/python2.7/dist-packages/aminer and perform the "link" operation, > but > >this could make it more "sexy" for an admin to include whole dist-packages > in > >python path again. > >In that light, should the code be moved? > > leaving to other folks the answer > >Apart from that, this will also make it harder to use the same codebase for > >both python2.6/python2.7, but that should be fixable by providing more > >patches. > > you can't use python2.6 on Stretch, so no issue here. Understood, dropping the 2.6/2.7 compatibility stuff > >> >-#!/usr/bin/python2 -BEsSt > >> >+#!/usr/bin/python2.7 -BEsSt > >> > >> this should be also handled by dh_python2 AFAIK > > > >Even with move dh_python2 does not touch the files. The only difference is, > >that lintian does not like the files any more. > > can you please double check with the documentation? > https://wiki.debian.org/Python/LibraryStyleGuide The "python2" selection in the binaries was effect of reading it, but perhaps I got something wrong: Intro: "It (the LibraryStyleGuide) is not intended to supplant the Debian Python Policy and in fact, if you have not read that document, stop now and go read it" And from " Debian Python Policy" https://www.debian.org/doc/packaging-manuals/python-policy/ch-python.html#s-interpreter_name "Python scripts that require the default Python 2 version should specify python2 as the interpreter name." So should be OK in my opinion. > [Snip]
Attachment:
smime.p7s
Description: S/MIME cryptographic signature