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