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
