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
