Hi Gianfranco, hello Python devs,
Introduction for debian-python members: Gianfranco is giving me great
assistance in the mentoring process to get the logdata-anomaly-miner package
included to Debian. There were some issues, we are not completely sure, how to
sort them out, any help on that would be appreciated!
Sorry for drawing your attention to that in the middle of the running
discussion. You can find the whole discussion in the ITP bug report
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813096 . Perhaps reading the
whole issue would not justify the time spent, so from my opinion most
important 2 topics and related questions are:
* Rationale not using "usr/lib/python*/": See this mail, first inline reply
section. Q: Are the arguments relevant? Move code or not?
* dh_python2 woes: Beginning of it, see Bugreport " Fri, 3 Jun 2016 18:54:16
+0000". Idea was to share as much code as possible between python2.6/python2.7
systems, but somehow this does not work out with packaging/lintian. Q: is
building a 2.6/2.7 package even a good idea or should it be avoided? Instead
upstream code and Debian packaging rules/patches could be optimized for
generating different packages for those versions.
The package in question can be found at
https://mentors.debian.net/package/logdata-anomaly-miner
> Von: Gianfranco Costamagna [mailto:locutusofborg@debian.org]
> Hi
>
> >I had already added it already to
> >* control
> >Depends: ${python:Depends}, python-tz, ${misc:Depends}
>
> >which was mangled (with warning) to:
>
> maybe you are installing the files in usr/lib/foo, instead of
> usr/lib/python*/
> and then dh_python2 is not acting correctly?
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?)
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 don't think installing python stuff outside that directory is a good
> idea...
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.
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)
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?
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.
> >@@ -1,4 +1,4 @@
> >-#!/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.
> >Everything seems to work without it also and the same package could have
> been
> >used for python2.6 and python2.7 systems but lintian does not understand
> that.
>
> well, installing into usr/lib/python* should fix that issue
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?
> I would prefer you to ask on debian-python about this issue, because I'm
> wondering about something bad that is just hidden and will be spot when the
> package
> enters the
> archive.
>
> having an ack for a more python-savvy person would be great
> (I could even sponsor the package as-is, but I'm not too confident with
> that)
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.
> >I hope this fixed all the review comments for regarding the packaging. I
> would
> >like to keep the deeper restructuring of upstream code + Debian packaging
> >scripts for upstream/Debian release V0.0.3. Is that OK from Debian side?
>
> it is ok to have new uploads, don't worry about that, I just would like to
> have a
> feedback from another DD before uploading/finish the review.
>
> is it possible for you?
> otherwise let me know and I'll finish the review and do the final
> checks+upload.
Understood. It might be, that this is all not a big issue for the python-dev
pros, might be sorted out quickly.
Best regards,
Roman
Attachment:
smime.p7s
Description: S/MIME cryptographic signature