Re: generating debian/control while building source package
On 04/01/2015 09:57 PM, Johan Van de Wauw wrote:
> I noticed there are quite a few packages that generate part of the
> control file while building a source package from git. I noticed this
> for grass and postgis.
> I don't really like this approach. Eg when trying to backport the
> recent security changes for postgis to ubuntu (trusty) this leads to a
> number of new changes which are only visible when making a debdiff. It
> also seems that the control file in the actual package may contain
> different things depending on the installed postgresql version.
I generally agree, I'm also not fond of generating control files and
prefer making the changes explicitly.
It does increase the maintenance burden, preventing automating (most of)
the build process.
It has it's pros and cons.
For grass it's mostly the version detection required for the paths and
dependencies. This could be changed to the hardcoding the version and
changing it every major and minor version change, but it then requires
the maintainer to know/remember what to change.
The postgis package is special because the source package is also used
in the pgapt repository maintained by the postgres project, which builds
the package for every supported postgres version instead of only one in
Debian. I don't want to force the postgres people to maintain their own
fork of the source package to continue to support their use case.
> I wonder: is there a way to build a source package without rebuilding
> the control file?
Disable the control file generation in the rules file, you can make it
conditional depending on an env var for instance.
> Would it not be better to make this a separate step
> in the build proces which is not run automatically?
It depends :-)
> I think in a way the arguments against autobuilding (see ) also
> apply to adding these dependencies while building the actual source
> package from vcs - I'm much more likely to check the debian/control
> file in the vcs tree then in the source package.
The CDBS example in the ftp-master REJECT-FAQ is quite similar, but a
more hidden change than the control file generation done by the rules
> I'm not at all an expert so feel free to convince me I'm not right :-)
I've remove control file generation in a number of packages, those that
still have some I consider useful enough to keep.
In general I think that control file generation should be avoided by
default and only done when there are sufficient arguments for it. To
remember which steps to take when updating a package, reviewing the VCS
log is often good enough for example.
But if you want to take the Don't Repeat Yourself approach, control file
generation has its rightful place.
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1