Bug#1102295: d/control must not change during build

Hello Simon,

thank you for the insights.

(I've tried to trim some context, not sure how successful I was.)

* Simon McVittie <[email protected]> [250408 11:33]:
>On Mon, 07 Apr 2025 at 14:08:23 +0200, Chris Hofstaedtler wrote:
>>[1] https://ftp-master.debian.org/REJECT-FAQ.html "debian/control breakage #2"
>
>I am not a ftp team member, but I believe that point is specifically 
>forbidding the set of built packages from changing during the build, 
>and not the rest of debian/control:
>
>- regenerating debian/control during clean to rewrite "less important"   
>fields like Uploaders or Description: reluctantly allowed
>
>- regenerating debian/control during clean so it does or doesn't list   
>libfoo-data according to some external factor: not OK
>
>>The ``debian/control`` file contains the most vital (and
>>version-independent) information about the source package and about the
>>-binary packages it creates.
>>+binary packages it creates. The file must stay unchanged when building
>>+a package.
>
>I think this would make several GNOME and GNOME-adjacent packages no 
>longer Policy-compliant. The GNOME team has historically used the 
>gnome-pkg-tools package (dh-sequence-gnome) to generate d/control from 
>d/control.in, with a substitution into Uploaders, during
>"debian/rules clean". I'm fairly sure there are non-GNOME packages 
>that do similarly.
>
>I never liked that, and the team has been phasing it out during the 
>trixie cycle (mostly in Jeremy Bícha's uploads), but I suspect we 
>still have a few less-active packages where the d/control regeneration 
>has not yet been removed.

So, these packages will have a different set of Uploaders: in the 
binary packages than in the Source package?

If so, is this really a good idea? Not saying this should become a 
policy violation, but I would find this surprising.

>I think there are some principles for handling of debian/control that 
>we *can* say are definitely required, which follow from how dpkg-dev 
>and the buildds work:
>
>- the Build-{Depends,Conflicts}{,-Arch,-Indep} that appear in the   
>uploaded source package (.dsc) must be sufficient to build the   
>package (ref: "CDBS" in the REJECT-FAQ, and also common sense because   
>sbuild will only satisfy the build-dependencies at the beginning, so   
>by the time dpkg-buildpackage runs code from debian/rules, it's too   
>late to introduce new build-dependencies)
>  - if d/control is regenerated during build, it must not add     
>build-dependencies
>  - and if d/control is regenerated during build, it must not add     
>build-conflicts
>
>- perhaps we can also say that the Build-{Depends,Conflicts}{,-Arch,-Indep}
>  must not change *at all* during build (ref: "CDBS" in the REJECT-FAQ)

This thing started because a package was found that *removed* a 
Build-Depends item. I think this should also be forbidden.

>- the binary packages built by a source must be a subset of the binary   
>packages listed in the uploaded .dsc (ref: "debian/control breakage 
>#2",   and more specifically I think the ftp team require this because 
>if it   isn't true, they lose their ability to control the binary 
>package   namespace)

Plus -debug packages, which are automatic.

>and there are some other things that I think are not RC issues, but 
>that I think we can say are good design principles:
>
>- if debian/control is a generated file, it should either be generated   
>by the maintainer ahead of time ("make -f debian/rules control" or   
>similar before upload, as seen in e.g. gcc), or generated during the   
>clean step; it should not change during the build{,-arch,-indep} or   
>binary{,-arch,-indep} steps

I think I agree. Maybe someone can point out problems with allowing 
it at "clean" time.

>- if debian/control is generated at build time, it should be a 
>deterministic   function of the package contents and the 
>build-dependencies   (because otherwise we don't have reproducible 
>builds)
>
>- if debian/control is generated at build time, ideally it should be a   
>deterministic function of the package contents only, with newer or   
>older build-dependencies not affecting its contents
>  (because otherwise we don't have a reproducible .dsc)
>  - note that dh-sequence-gnome Uploaders processing does not fully 
>obey     this principle, which is one of the reasons I don't like it

I wonder how these two options will affect reproducible builds, 
and/or introduce other hard-to-detect FTBFS scenarios.

> - if debian/control is generated at build time, the parts of it that    
>can change should be limited to descriptive fields such as Uploaders    
>or Description, and functionally-significant fields should not change

Assuming this means binary build time, I feel this will need a 
complete list of allowed fields.

>But I think the proposed patch is too strong. As I said, I don't 
>*like* the GNOME team's historical regeneration of Uploaders, and I'm 
>glad we're phasing it out, but I don't think it is or should be a 
>Policy violation.

Right. Generally what I want is: tools should be able to look at a 
source package, and derive various parameters from it, most of them 
will come from d/control (and d/changelog). If d/control changes 
after the tools extracted the relevant info, this becomes messy.

Even for fields like Uploaders:, I believe various tools look at the 
values of the source d/control, possibly to do NMU detection.

Chris