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
