On Tue, Jul 09, 2019 at 12:24:40PM +0200, Simon Richter wrote:
> Your proposal of generating some of the fields doesn't affect the API
> itself, as long as the fields are populated at the right time. We don't
> have a mechanism for updating the control file at build time, because any
> part of the build process that would be able to do so is after the part
> where the control file is consumed for the first time, so it would give an
> inconsistent view.
I used to handle this back when I had the goal of making sure that
e2fsprogs from the git repository could successfully build as far back
as oldoldstable. The idea was that sometimes people would want to be
able to get an updated version of e2fsprogs with all of the bug fixes;
and while I'm not willing to manually extract large number of bug
fixes and backport them to ancient distro versions of Debian and
Ubuntu --- our backport process to Debian Obsolete^H^H^H^H^H^H^H^H
Stable is *not* fun for me, as far as I'm concerned), I could at least
make sure that modern versions of e2fsprogs could be trivially
repackaged for ancient versions of Debian/Ubuntu.
The way I did this was to make a default target in debian/rules called
debian-files, which would create (or re-create) debian/control from a
debian/control.in file. Then to build e2fsprogs on debian, one would
first unpack the e2fsprogs' upstream tarfile distribution, or check it
out from git, and then run:
./debian/rules
dpkg-buildpackage
The Debian source package would have the automagically generated
debian/control file, so it was fully compatible with all of Debian's
package tooling, but it would also have the debian/control.in file,
which as far as *I* was concerned was the preferred form for
modification.
Cheers,
- Ted
