> Von: Piotr Ożarowski [mailto:piotr@debian.org] > > [Fiedler Roman, 2016-06-09] > > > * install into /usr/lib/logdata-anomaly-miner/ and dh_python2 will pick > > > it up without any overrides, additional options, etc. > > > > So I guess, before that (where dh_python2 refused to operate at all), > > using /usr/lib/aminer as a shorthand - as the package name is quite > > long - was a bad idea. > > NAME in /usr/lib/NAME is not used in Python¹. It's not module name, you > cannot import it so Python module naming rules do not apply here. > > [¹] at least in /usr/lib/NAME/foo scripts OK, I understand. So for simplicity it seems to be best when NAME==[full-package-name], already changed in newest mentors upload. > > As import names cannot contain a dash, is use of > > "usr/lib/logdata-anomaly-miner/aminer" as module storage directory and > > "aminer" as shorthand module name in imports OK? > > if /usr/lib/logdata-anomaly-miner is the storage and > /usr/lib/logdata-anomaly-miner/aminer is the module dir (with > __init__.py file), then yes Confirmed, that's exactly how it works now. > > Still when building, lintian is unhappy with the output package: > > > > E: logdata-anomaly-miner: python-script-but-no-python-dep usr/lib/logdata- > anomaly-miner/AMiner > > E: logdata-anomaly-miner: python-script-but-no-python-dep usr/lib/logdata- > anomaly-miner/AMinerRemoteControl > > is AMiner and AMinerRemoteControl symlinked in /usr/bin/? > (you can use debian/logdata-anomaly-miner.links to do that) Currently they are not symlinked. I took the same approach as with e.g. /usr/lib/apt/methods/http or /usr/lib/eject/dmcrypt-get-device where those binaries are usually not intended to be called by user directly. Meanwhile this has changed, e.g. AMinerRemoteControl is more or less now OK for cmd-line use. So I would add the symlinks. Or would moving of the files be more Debianic? > PS please don't CC me, I read debian-python@lists.debian.org Sorry about that.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature