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

On Mon, 07 Apr 2025 at 14:08:23 +0200, Chris Hofstaedtler wrote:
>it appears that currently there is no requirement for d/control to 
>stay the same before and after a build. However, many things require 
>this to be the case, and ftp-master also requires this in their 
>reject-faq [1].
>
>[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.

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)

- 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)

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

- 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

  - 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

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.

     smcv