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: <!noudeb>",
>> then debhelper will honour that when deciding which packages to build,
>> so yes, anything built into debhelper should just work.
>
> Treating udebs as implicitly having Build-Profiles: <!noudeb> might be a
> reasonable feature request for debhelper, but I don't think it implements
> that right now. Like everything else in udebs, it might be too niche to
> be considered a worthwhile investment of effort.
>
> [...]
I have been tempted to do something like this but have decided against
it. The debhelper tools are not the only tools reading d/control, so
there is a limit to how many packaging papercuts we can work around in
debhelper (e.g. see the "related" issue for Rules-Requires-Root in
#884999). This one "just might work with a bit of abuse", but the next
one will probably fall flat on its face (or, indeed, the previous
request did).
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:
Input file (fiction):
"""
Source: foo
...
Package: new-package
<regular fields here that the maintainer need>
Package: old-package
Replaced-By: new-package (= 1.0)
Package: new-udeb
Package-Type: udeb
"""
Generated output:
"""
Source: foo
...
Package: new-package
<regular fields here that the maintainer need>
Breaks: old-package (<< 1.0~)
Replaces: old-package (<< 1.0~)
Package: old-package
Priority: optional
Section: oldlibs
Architecture: all
Depends: new-package (>= 1.0~)
Description: transitional package - replaced by new-package
This package is for transitional purposes and can safely be removed.
Package: new-udeb
Package-Type: udeb
Build-Profiles: <!noudeb>
Section: debian-installer
Priority: optional
<Other fields if I forgot any in my hand-written unplanned demo>
"""
It is not perfect for packages that uses dpkg-control/dh_control with -v
to set a "per-binary" version, but I still think it would be a great
reduction in cognitive burden for the maintainer to work with a
d/control that is on a higher level than "assembly".
Unfortunately, the whole act of generating d/control introduces its own
set of papercuts/learning curve as most tools need a d/control or a .dsc
(which itself needs a d/control).
The alternative would be to have *all* tools working on d/control have a
shared interface on deciding the defaults. But that becomes a mess as
because we probably have thousands of places to update in/around the
Debian infrastructure alone.
Comparison with debdry (which I assume someone would bring up in
response): debdry had the goal of relying on tools to generate the
d/control along with most other packaging files (e.g. d/rules rewriting
would also be in scope). Most of its changes to the d/control syntax
revolved around merging manual changes with the automatic ones. The
rewrites I propose above and debdry's approach can be combined/composed
(including by adding this feature directly to debdry and have it be the
reference implementation for these rewrites)
Thanks,
~Niels
Reply to: