Hi > I still don't see "python" in build-dependencies.
>I tried that already, but somehow it did not work out (that's why the manual >"python2.6 | python2.7" is kept). the reason should be the missing python dependency and the missing dh_python2 call >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. don't know, dh --python2 should do the job. not sure why you override that >You are good! Funny, how dumb one can be ... Just used the stubs from previous >packages without thinking ... :) IIRC I did the same mistake some years ago :D >Would that split of old postinst solve all problems without provoking new >ones? I guess so >a) new preinst: the user/creation (with #DEBHELPER#) >b) postinst: chmod/chown, .. changes to files (WITHOUT the #DEBHELPER#) with DEBHELPER too. preinst <-- user creation postinst <-- systemd start (automatically) prerm <-- systemd stop (automatically) postrm <-- user del and whatever I'm not completely sure, just try, test and look at the policy https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html >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: dh_installchangelogs is your friend :) (but files that has similar names are added automatically I guess, just check if it is added or not >I have removed that part, both unused options and the error handling. it should already be handled in the DEBHELPER macro, right? >Thanks for the pointer to quilt. Seems to make sense, is on the todo list. ok >Understood, quilt will do here also. yes >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? whenever you want, a "debian" branch in upstream packaging, a directory on your pc whenever is convenient for you (also alioth, collab-maint, github) having a different branch on git will make the packaging of new releases easy as git checkout debian git merge vVERSION-tag dch and so on (YMMW) >Thank you very much for your answers and patience, I will do a clean package >build after doing some more reading/testing. keep your time :) >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. irc/OFTC and #debian-python/#debian-mentors channels might be your friends, as well as manpages :) (or the debian-mentors mail list) G.
