> From: Gianfranco Costamagna [mailto:locutusofb...@debian.org] > > > E: logdata-anomaly-miner: python-script-but-no-python-dep > >Tried to follow the guidelines, seems that everything works but lintian is > >still > complaining. Changes recommended from various forums: > > >Any ideas would be appreciated. Otherwise I'll just add a workaround to get > rid of the lintian error. > > I still don't see "python" in build-dependencies. > > BTW your rules hack is wrong, please just call dh --with=systemd,python2 > > BTW "python2.6 | python2.7" <-- please remove dh_python2 should handle > them too
I tried that already, but somehow it did not work out (that's why the manual
"python2.6 | python2.7" is kept).
dh_gencontrol
dpkg-gencontrol: warning: Depends field of package logdata-anomaly-miner:
unknown substitution variable ${python:Depends}
dpkg-gencontrol: warning: File::FcntlLock not available; using flock which is
not NFS-safe
dpkg-gencontrol: warning: package logdata-anomaly-miner: unknown substitution
variable ${python:Versions}
dh_md5sums
dh_builddeb
I'll stay on that one (see todos), at the moment I am trying to figure out
with strace what the rule
/usr/share/dh-python/dh_python2 -p logdata-anomaly-miner
usr/lib/aminer/AMiner usr/lib/aminer/AMinerRemoteControl
is doing and why it does not detect the correct version to pass it on to
dpkg-gencontrol.
> > W: logdata-anomaly-miner: maintainer-script-calls-systemctl prerm:30
> > W: logdata-anomaly-miner: maintainer-script-calls-systemctl prerm:31
>
> Gone by following changes .... (BUT read below):
>
> >CAVEAT: Although lintian is happy, there are two issues with that change,
> that may/are problematic:
> >
> >a) I moved the DEBHELPER in prerm BEFORE my code to delete the users. Is
> the DEBHELPER code really intended to be run before or may this cause other
> issues?
>
> what about a "postrm" script?
You are good! Funny, how dumb one can be ... Just used the stubs from previous
packages without thinking ...
> >b) In postinst DEBHELPER will automatically activate the systemd unit. But
> >this
> was not done INTENTIONALLY! Therefore documentation included a section,
> what to >check/do before activating the service to avoid any risks. Are
> there
> means to get to that state also with the dh-systemd components?
>
> preinst?
Would that split of old postinst solve all problems without provoking new
ones?
a) new preinst: the user/creation (with #DEBHELPER#)
b) postinst: chmod/chown, .. changes to files (WITHOUT the #DEBHELPER#)
> >Thanks for the hint. If I understand correctly, pybuild will only care
> >about
> maintaining the dependencies to the python packages and which interpreter
> to use but it >will NOT require the software to load from site-packages or
> to
> create/use pyc files, which is currently avoided due to security reasons?
>
> I'm not sure :( sorry
No problem, kept as todo.
> >According to Debian manual, this should be used to automatically include
> files from uppermost directory of the unpacked source. Currently there are
> no useful files >at this location, all documentation is included directly
> from
> source/root/usr/share/doc/aminer/. Would following files be sufficient?
>
> an empty file can be deleted, if you have no documentation, but having an
> empty file should be avoided
> (I don't like them, they overcomplicate packaging and are just useless)
OK, I have deleted for now. What about the suggestion with the CHANGELOG?
Currently debian/changelog is the "packaging changelog". But the software has
also a "feature/version changelog". Where should that be kept best? Options:
* only upstream tar-ball but dropped during packaging
* in tar and package at same location
* in tar and package at different location
> [Snip]
>
> >Current content is "root/* ." There is no compiling involved, so this
> >copies
> just the plain files into the package. Is there something else to be used
> for this
> >purpose?
>
> not sure, does dh_systemd correctly handle the service file?
Yes, it seems so: from generated #DEBHEL:
# Automatically added by dh_systemd_enable
# This will only remove masks created by d-s-h on package removal.
deb-systemd-helper unmask aminer.service >/dev/null || true
# was-enabled defaults to true, so new installations run enable.
if deb-systemd-helper --quiet was-enabled aminer.service; then
> >How should that work? In generated DEBHELPER code I do not see any
> commands that would create the users? If you mean the length of " >abort-
> >upgrade|abort->remove|abort-deconfigure": this is from dh-make, should
> that be changed?
>
> yes, just override what you need, don't put default stuff there
> (and open a built-deb file, you will see the #DEBHELPER# macro substituted
I just kept it as it seemed to me to be a second line of defence against
typos: everything not handled will end up in the "exit 1", so the first
attempt to install the package during testing/continuous integration will
fail:
abort-upgrade|abort-remove|abort-deconfigure)
;;
*)
echo "postinst called with unknown argument \`$1'" >&2
exit 1
;;
I have removed that part, both unused options and the error handling.
> >This was not really planned. The idea behind the package structure was to
> have only one repository to maintain to build the packages for both
> Debian/Ubuntu. Will >the Debian/Ubuntu requirements be that different in
> the end, that maintaining a single code base for building is not possible
> anyway? In such scenario are those >changes the best?
>
> create an upstream tarball, and switch to quilt mode, the code doesn't
> change
> for Debian, or Ubuntu, and makes easier for other linux
> distros to use it.
Thanks for the pointer to quilt. Seems to make sense, is on the todo list.
> >* Move the debian/ stuff in the upstream repository to debian-templates/
> (not packaged)
>
> not requested.
Understood, quilt will do here also.
> >* Create a downstream repository, e.g. at the "Debian collab platform",
> where the upstream source.tgz is loaded automatically and only the debian/
> stuff is stored
>
> >Does that make sense?
>
> you can also just remove the debian from the orig tarball, and add it on top
> of
> your changes after unpacking the orig tarball.
OK, I will change. There is only one question open at the moment: what is the
Debian policy for versioning of those Debian-specific build files? Could they
be hosted just anywhere, e.g. adding them to the same upstream repository,
used to build the source.tar.gz or should the go to a separate repository,
perhaps even under control of Debian folks like the "Debian collab platform"?
Would https://wiki.debian.org/Alioth/PackagingProject make sense?
Thank you very much for your answers and patience, I will do a clean package
build after doing some more reading/testing.
Best regards,
Roman
Todos:
* Fix: " dh --with=systemd,python2" somehow fails to substitute
dependencies/version in control
* Check transition to "pybuild" and possible side effects (see mails
~2016-06-02) after solving the dependency problem
* Enable quilt mode to patch upstream Launchpad source.tar.gz after deciding
about versioning of Debian-specific patches.
smime.p7s
Description: S/MIME cryptographic signature
