> 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
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]
smime.p7s
Description: S/MIME cryptographic signature
