[debhelper-devel] Bug#703201: Add an option to process per-arch/per-os *and* normal install files

[Gergely Nagy]

This can easily be done with dh-exec now, with much nicer syntax than
what I proposed two years ago:

Instead of foo.install-common, foo.install.$os, foo.install.$arch, one
can use a single executable foo.install file, with some special markup:

,----
| #! /usr/bin/dh-exec
| 
| ## Common stuff
| /usr/share
| 
| ## arch-specific stuff
| [any-amd64] /usr/lib/foo-amd64 /usr/lib
| [any-i386] /usr/lib/foo-i386 /usr/lib
| 
| ## os-specific stuff
| [linux-any] /usr/lib/foo-linux /usr/lib/foo/
| [freebsd-any] /usr/lib/foo-freebsd /usr/lib/foo/
`----

And so on and so forth, see dh-exec-install(1). The wildcards follow the
same syntax as dpkg-architecture(1).

This approach does not require splitting the files, and only works when
everything is in a single file, which may get lengthy. If there is a
need to support some kind of inclusion, I can very easily add that to
dh-exec. It's about 5-6 lines of code, and a few handful more for tests.

Since I have a little bit of free time, how about this:

If foo.install.common exists, auto-include foo.install.$arch and
foo.install.$os (if they exist), provided that foo.install is executable
and uses dh-exec.

Alternatively, an executable foo.install, and executable
foo.install.$arch/$os could also be a trigger, so foo.install.common
wouldn't be required, and could be rolled into foo.install.

A third option would be what I suggested in 2013: an explicit #include.

I'd only implement at most one of the above, let me know which would be
the most debhelper-ish way to accomplish the task (the currently
available syntax is an option too, of course).

-- 
|8]