Bug#884807: getmail: does not ship /usr/bin/getmail
Hi,
On Wed, Dec 20, 2017 at 11:23:54AM -0500, Daniel Kahn Gillmor wrote:
> On Thu 2017-12-21 00:48:44 +0900, Osamu Aoki wrote:
> >
> > # 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 for the record, let me clarify my position. I thought about this
concern.
> Just so you know why i prefer the declarative style, though:
I also prefer the declarative style for *splitting* generated files into
*multiple* binary packages from the debian/tmp directory. But that is
for *splitting* into binary packages ;-)
> 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).
I see your point. You are considering *.install as a one level of
security check. Then you should raise concern to the current
dh_auto_install behavior (maybe since debhelper compat>=4) which doesn't
use the debian/tmp directory as the DESTDIR. All
"single_binary_package"-type packages use the debian/
directory as the DESTDIR and ship all generated files without filtering.
I remember this DESTDIR choice was flip-flopped before debhelper compat
4. But the current choice of DESTDIR is quite stable since then.
> 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.
Please note there were imperative changes to the debian/rules even in
your proposed version which got carried over from my previous script. I
mean "rm -rf debian/.../usr/share/doc/getmail-*". I thought installing
documentation from upstream installed ones in DESTDIR are better than
copying from the source tree. That was the reason why I changed from
"rm -rf" to "mv".
> > So when we drop getmail4 transition package, migration needs only
> > dropping it in the debian/control field.
>
> I think that would happen either way :)
Once we drop getmail4 in buster+1, we will be back to the
"single_binary_package"-type package unless we change dh_auto_install to
override its default by setting --destdir=debian/tmp.
I thought that is a bit overkill. Instead, I set
--destdir=debian/getmail since this is practically a single binary
package except for generating a dummy package. Then with "mv" already
applied, I just don't need to have *.install. That is what happened.
> anyway, just thought i'd explain my reasoning. I'm happy to follow your
> lead on the package.
No problem. Since I noticed your rationale, I just wanted to explain my
rationale ;-)
Osamu
Bug#884807: getmail: does not ship /usr/bin/getmail
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
Bug#884807: getmail: does not ship /usr/bin/getmail
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 So when we drop getmail4 transition package, migration needs only dropping it in the debian/control field. So I made a bit more changes to simplify packaging. Osamu
Bug#884807: getmail: does not ship /usr/bin/getmail
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! happy hacking, --dkg signature.asc Description: PGP signature
Bug#884807: getmail: does not ship /usr/bin/getmail
Package: getmail Version: 5.5-1 Severity: grave Justification: renders package unusable 0 dkg@alice:/tmp/cdtemp.ncMzG7$ apt download getmail 0 dkg@alice:/tmp/cdtemp.ncMzG7$ dpkg --contents getmail_5.5-1_all.deb | grep bin/get -rwxr-xr-x root/root 1636 2017-12-17 10:17 ./usr/bin/getmails 0 dkg@alice:/tmp/cdtemp.ncMzG7$ somehow /usr/bin/getmail got dropped from the getmail 5.5-1 packaging :/ This makes the package not useful! --dkg -- System Information: Debian Release: buster/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (500, 'oldstable'), (200, 'unstable-debug'), (200, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- no debconf information
