Hi Osamu-- thanks very much for your packaging work for getmail!
On Thu 2017-12-21 00:48:44 +0900, Osamu Aoki wrote: > On Tue, Dec 19, 2017 at 06:36:15PM -0500, Daniel Kahn Gillmor wrote: >> On Tue 2017-12-19 16:47:01 -0500, Daniel Kahn Gillmor wrote: >> > somehow /usr/bin/getmail got dropped from the getmail 5.5-1 packaging :/ >> >> I've pushed some changes to the master branch of >> https://anonscm.debian.org/git/collab-maint/getmail.git that resolve >> this matter for me. >> >> they also do a little bit of packaging cleanup. I hope they're useful! > > Thanks. I realized your change just before upload. Good. > Yes this cleans my rough edges. > > I had some changes locally with a bit different style too ;-) I have > debian/rules with: > > # Always use debian/getmail as destination (not debian/tmp) > # even when dummy getmail4 package exists > override_dh_auto_install: > dh_auto_install --destdir debian/getmail ok, it looks like i tend to prefer the more declarative style, and you prefer the imperative style. You're the maintainer, so your decision goes :) Just so you know why i prefer the declarative style, though: i think with your imperative changes to the debian/rules makefile, a new upstreamversion that injects something funky into the filesystem will just have it happen (possibly without the maintainer noticing). With the declarative approach i'd outlined (that is, listing everything explicitly in debian/getmail.{docs,install,manpages}, and including dh_missing --fail-missing), the packager has to actively acknowledge changes to the installed filesystem, which i like as a double-check during packaging itself. > So when we drop getmail4 transition package, migration needs only > dropping it in the debian/control field. I think that would happen either way :) anyway, just thought i'd explain my reasoning. I'm happy to follow your lead on the package. All the best, --dkg
