Re: Could we generate d/control instead of working with "assembly level code" directly (was: Re: The noudeb build profile and dh-only rules files)
Hi,
On Tue, Jul 09, 2019 at 06:12:00AM +0000, Niels Thykier wrote:
> Instead, I have been toying with the idea of treating d/control as
> something we generate. While not entirely novel in itself, once you
> start generating d/control, you can do interesting rewrites such as:
I've started work in that direction with the debian-xcontrol package a few
years ago. The debian/control file is an API that is difficult to extend
because it lives at the boundary of an Internet service, so any change
basically requires writing adapter code that translates API versions, and
the control file is somewhat unversioned (Policy-Version exists, but is not
used as a switch).
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.
The way it was generally done with xcontrol was to regenerate the control
file and compare whether the generated file was equivalent to the existing
one, and fail the build if not. This is a bit fragile, but it's the best we
can do here without changing Policy.
Your proposal effectively reinvents debian-xcontrol, which wasn't a roaring
success because it was more annoying to use than just writing a few lines
by hand. It's not a bad idea per se, but it will need more benefit to fly.
Simon
Reply to: