XPost: linux.debian.bugs.dist, linux.debian.policy
From: smcv@debian.org

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

--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)

XPost: linux.debian.bugs.dist, linux.debian.policy
From: zeha@debian.org

Package: debian-policy
X-Debbugs-CC: debian-dpkg@lists.debian.org, ftpmaster@debian.org, jspricke@debian.org, josch@debian.org

Dear Policy Editors,

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].

Below is a minimal patch, mostly as a discussion starter. I've
ponderred if listing examples of things breaking would be good, but
decided against it for the policy text.

This change suggestion started when Jochen et al discovered that the
"pcp" package currently rewrites its d/control file, which causes
rebuilds of the in-archive package to produce a different result. [2]


Thanks,
Chris


[1] https://ftp-master.debian.org/REJECT-FAQ.html "debian/control breakage #2" [2] https://reproduce.debian.net/amd64/#pcp and https://bugs.debian.org/1102289

(CC'ed people I expect to be interested.)


diff --git i/policy/ch-controlfields.rst w/policy/ch-controlfields.rst
index 3151816..cffca22 100644
--- i/policy/ch-controlfields.rst
+++ w/policy/ch-controlfields.rst
@@ -98,7 +98,8 @@ Debian source package template control files -- ``debian/control``

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.

The first stanza of the control file contains information about the
source package in general. The subsequent stanzas each describe a

--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)

XPost: linux.debian.bugs.dist, linux.debian.policy
From: alexandre.detiste@gmail.com

Hi,

I'm always more in favor of removing old cruft than adding complicated wording to document old cruft forever.

Here there could be a compromise that (some of...) the existing usage
are grandfathered,
like the provision in Policy 4.7.2 for /usr/games/{thing} that
conflicts with /usr/games/{thing}
that made a lot of packages instantaneously RC-buggy in 4.7.1

BTW I removed DEB_AUTO_UPDATE_DEBIAN_CONTROL from cdbs.
And lownmu'd the single last half-abandoned package still recommending
it in a comment.
I hope it makes FTP Master life easier.

Greetings

Alexandre

Le mar. 8 avr. 2025 à 14:56, Simon McVittie <smcv@debian.org> a écrit :

There is a relatively long tail of obsolete libraries that are no longer
used by GNOME, no longer maintained upstream and would ideally be
removed from Debian altogether, but cannot be removed yet because they
still have other packages depending on them. In general the team still carries out minimal maintenance on those obsolete libraries to keep them
on life-support, but fixing non-critical issues in them is not anyone's top priority.

--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)

XPost: linux.debian.bugs.dist, linux.debian.policy
From: smcv@debian.org

On Tue, 08 Apr 2025 at 14:30:53 +0200, Chris Hofstaedtler wrote:

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

As far as I'm aware, binary packages don't have Uploaders (that field is
purely a source package thing).

But, if you take an old GNOME-team package and do a no-changes sourceful upload, debian/control gets regenerated from debian/control.in during `debian/rules clean`, and if the list of GNOME Team members in
gnome-pkg-tools has changed (or if its heuristic to decide who to put
in Uploaders has changed), the Uploaders field in the debian/control
member of the new debian.tar.xz might not be identical to the old.
Similarly, the Uploaders field in the .dsc, which ends up being copied
into the apt Sources index by the ftp team's machinery, will reflect
that change.

I agree that this is odd, and I've never been particularly comfortable
with it myself, but I don't think it is/should be a policy violation,
and the release team has generally been willing to tolerate it for the
purposes of freeze exceptions and stable updates (they do allow
documentation updates, and Uploaders is basically documentation).

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

I don't like it either, and as far as I'm aware neither do any of the currently-active GNOME team members, but it clearly seemed like a good
idea to someone in the past.

The fact that it's surprising is why the team has been phasing out this practice, in favour of maintaining the Uploaders list by hand like most
other packages do. But I'm reasonably confident that not every package
that had the generated Uploaders list has been re-uploaded without it.
There is a relatively long tail of obsolete libraries that are no longer
used by GNOME, no longer maintained upstream and would ideally be
removed from Debian altogether, but cannot be removed yet because they
still have other packages depending on them. In general the team still
carries out minimal maintenance on those obsolete libraries to keep them
on life-support, but fixing non-critical issues in them is not anyone's top priority.

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

Right, but those don't really affect the ftp team's ability to control
the namespace: they've made a specific exception for those, accepting
that by allowing foobar into the archive, they are also allowing
foobar-dbgsym to exist.

smcv

--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)

XPost: linux.debian.bugs.dist, linux.debian.policy
From: zeha@debian.org

Hello Simon,

thank you for the insights.

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

* Simon McVittie <smcv@debian.org> [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

--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)