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)

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

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)

On Tue, 09 Jul 2019, 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 wo

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 +, 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 i

Could we generate d/control instead of working with "assembly level code" directly (was: Re: The noudeb build profile and dh-only rules files)

Simon McVittie: > On Mon, 08 Jul 2019 at 19:23:39 +0100, Colin Watson wrote: > [...] >> If the udeb stanzas in debian/control have "Build-Profiles: ", >> then debhelper will honour that when deciding which packages to build, >> so yes, anything built into debhelper should just work. > > Treating u