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
