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

Is there any reasonable situation where modification (during build) of
ANY existing files under debian/ is a good idea?

I know modifying existing non-debian/ files is common to patch
source-level problems, but is modifying existing debian/ files wide
spread?  Could anyone do a archive-wide non-root rebuild with 'chmod -R
-w debian/' with debian/ owned by some other user?

/Simon

Chris Hofstaedtler <zeha@debian.org> writes:

debconf template translations get usually refreshed when building a
package (doing that in the _clean_ target is a common usecase) which
totally breaks if the package maintainer uses a workflow with
out-of-tree builds. Been bitten by that.

Do we have current usecases where debian/control gets modified during
build? I think the reject-faq dates back to the days when cdbs had
significant use and ftpmaster didn't like cdbs. I have never understood
that stance and ftpmaster didnt bother to explain.

Greetings
Marc

Several packages do generate d/control:
https://codesearch.debian.net/search?q=control.in+path%3Adebian%2Frules&literal=0


Le lun. 7 avr. 2025 à 15:12, Simon Josefsson <simon@josefsson.org> a écrit :

* Jérémy Lal <kapouer@melix.org> [250407 15:25]:

I'll note that these packages either avoid recreating d/control when
it already exists with different contents (aborting instead) or
relying on other mechanisms for the contents not to change.

I believe this would not be prohibited by the proposed wording.

Chris

As long as they don't do that from any build or binary target.  "linux"
also recreates debian/control in the clean target, but aborts the build
then.

Bastian

Hello,

Usually we prefer to have some rationale, so a couple of sentences would
be good.

I also think the patch should be more specific -- exactly which d/rules
targets must not modify the contents of the file?

debhelper creates files in debian/
so maybe we should stick with the original question.

debian/control is not autogenerated, but DEBIAN/control is
(by dpkg-gencontrol). This difference should be made clear in the rationale.

Cheers,

* Bill Allombert <ballombe@debian.org> [250408 09:46]:

I believe this is already clear from the context. The section is
titled:

    Debian source package template control files -- ``debian/control``

Chris

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

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

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

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

Plus -debug packages, which are automatic.

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

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

Assuming this means binary build time, I feel this will need a
complete list of allowed fields.
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

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

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.

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

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 :