Hello Simon,
thank you for the insights.
(I've tried to trim some context, not sure how successful I was.)
* Simon McVittie <s...@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
