Hi,
I tried to address the issues from the first review for V0.0.0 at
http://mentors.debian.net/package/logdata-anomaly-miner, the changes are now
in the V0.0.2~pre0 package uploaded.
But still there are some points not completely clear to me:
Issues from https://www.debian.org/doc/debian-policy/
* I tried to follow this one, but seem to have overlooked some points. Could
someone please give me a pointer?
Issues from https://www.debian.org/doc/packaging-manuals/python-policy/
* Python3: As this software especially targets production use, currently
Python 2.6 is attempted to allow use over a broad range of OS. If community
is sufficiently large to support a parallel Python2/3 development, Python 3
support is definitely a goal.
* Python2 reference from package: Changed from
#!/usr/bin/python -BEsSt
to
#!/usr/bin/python2 -BEsSt
Is this sufficient to address the issues from the review?
* Python package dependency: Not sure how to handle that in suitable way:
there is no abstract "python2" package, so add a control file for to source
tree for each distro to build for having the correct "python2.X" dependency
in it? Or would that be better:
"Depends: python2.6 | python2.7, python-tz, ${misc:Depends}"
As second solution seems simpler, I prefer that.
* Arch-dependency: Currently the code calls directly into libc as Python is
missing quite all syscalls for secure filesystem interaction.
Apart from that, no use of arch-dependent .pyc files is made: the tool is
long-running, so the overhead acceptable and all the .pyc-related attack
surface can be skipped for the uid=0 part of the program.
Considering that, is there a change of package structure needed and if
yes, which?
Issues from https://packaging.python.org/en/latest/distributing/:
* Does this really apply? Currently the components are packaged as
application, use as a module was not attempted/tested yet. Perhaps split the
application from the module later on? Current layout should be compliant
with
https://www.debian.org/doc/packaging-manuals/python-policy/ch-programs.html,
depending how the libc link for different CPU-archs is treated as mentioned
above.
@Native package:
* Currently this mode chosen, as there is only a single source code
repository for open-source upstream development also holding the Debian
packaging stuff. What would be right way to split that? Remove Debian-part
from upstream and instead add it to debian collab platform? Or keep both
mixed but split build process into "BuildTgz" and "BuildDebPackage"?
I have added a watch file because lintian complained about that, now it is
complaining about the existence of the watch file. (The pubkey issue I'll
fix as soon as it is clear, if a watch file is really needed).
@Versioning:
* I was just waiting for pointers for good versioning policy during and
after porting from java. As the package was already needed to be available
on Ubuntu, I started with simple versioning scheme with major.minor.sub.
Source code repository is here:
http://bazaar.launchpad.net/~roman-fiedler/logdata-anomaly-miner/roman-fiedl
er/files
More about the package releases, versioning is here:
https://launchpad.net/logdata-anomaly-miner
Thanks for any comments,
Roman
Attachment:
smime.p7s
Description: S/MIME cryptographic signature