> Von: Gianfranco Costamagna [mailto:locutusofb...@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 

> >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 

> >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"

"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

Reply via email to