[Build-common-hackers] generating files in debian/

[Emilio Pozuelo Monfort]

On 03/02/11 16:30, IOhannes m zmoelnig wrote:
> hi all,
> 
> i'm currently trying to create CDBS snippets for packaging
> kernel-modules, both traditional "-source" packages and modern "-dkms"
> packages.
> 
> i started with dkms rules, and now i have a number of questions. here is
> one:
> 
> 
> - dkms packages are supposed to install into /usr/src/<pkgname>-<version>
> now i do believe that once a package is properly packaged, a new
> upstream release should involve only a minimal set of changes in debian/
> apart from debian/changelog and a possible update of debian/patches/, i
> see no need to touch any other file (given that nothing has changed
> dramatically in the upstream sources). e.g. having to change
> <pkgname>.install to reflect the new upstream version is superfluous.
> so the idea is to autogenerate things whenever possible.
> e.g. one could generate debian/<pkgname>.install from
> debian/<pkgname>.install.in, by doing simple substitution (in my case i
> would substitute something like @VERSION@ for $(DEB_UPSTREAM_VERSION))
> 
> now i see 2 possible issues:
> - is this allowed at all? e.g. afair debian/control MUST NOT be
> generated automatically, does this also apply to other files normally
> found (and searched for!) in debian/
> - if it were allowed, what would be a good strategy to make this as
> modular as possible? e.g. imagine snippetX would like to generate
> debian/<pkgname>.install from debian/<pkgname>.install.in and snippetY
> would like to do so as well. i think the two substitutions should both
> be applied, but how do i do this properly?

We do that in pkg-gnome in e.g. gtk+2.0, gtk+3.0 and pango1.0. The first one is
using debhelper, the other two use CDBS in experimental.

Cheers,
Emilio