Bug#813096: ITP: logdata-anomaly-miner -- lightweight tool for log checking, log analysis
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.
>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
>The rationale behind not putting aminer into dist-packages (and removing
>dist-packages from python-path) was:
>
>a) require the aminer-admin to "link" in each dist-packages module separately,
>thus reminding it, that it is no good idea to include large amounts of third
>party libraries in security-critical code. Code volume is also bugs and
>attack-surface.
I didn't get completely this, but I leave other people to answer
>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
>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.
>> >-#!/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
>So it would be OK to place the files in usr/lib/python2.7/dist-packages and
>add a symlink to usr/lib/python2.6/dist-packages?
no, python2.6 is dead, no need to add it here.
>I would not like to push for that. Let's take the time and learn. Also this
>package might be the template for other security-tool packages, so better have
>it clean before cloning.
thanks for understanding!
>Understood. It might be, that this is all not a big issue for the python-dev >pros, might be sorted out quickly.
I hope so, I understand the package is doing some non-standard things, so trying
to make it python-library style might be even a bad idea in general, this is why
I would prefer to have some double/triple checks here ;)
thanks for the nice email!
G.
Reply to: