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/<binpackagename>
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
