Re: Bug#1102295: d/control must not change during build

Simon McVittie <[email protected]> Tue, 8 Apr 2025 13:55:48 +0100
Newsgroups gmane.linux.debian.devel.dpkg.general
Message-ID <[email protected]>
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