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:
Package: debian-policyjspricke@debian.org, josch@debian.org
X-Debbugs-CC: debian-dpkg@lists.debian.org, ftpmaster@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/controlbreakage #2"
[2] https://reproduce.debian.net/amd64/#pcp andhttps://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``debian/control``
--- i/policy/ch-controlfields.rst
+++ w/policy/ch-controlfields.rst
@@ -98,7 +98,8 @@ Debian source package template control files --
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
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
Is there any reasonable situation where modification (during build) of
ANY existing files under debian/ is a good idea?
Several packages do generate d/control: >https://codesearch.debian.net/search?q=control.in+path%3Adebian%2Frules&literal=0
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.
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?
On Mon, Apr 07, 2025 at 03:07:54PM +0200, Simon Josefsson wrote:
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?
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.
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"
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.
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.
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.
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.
- 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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 482 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 69:15:03 |
| Calls: | 9,571 |
| Calls today: | 2 |
| Files: | 13,663 |
| Messages: | 6,142,216 |