Re: Architecture: all binNMUs (was: deduplicating jquery/)
On Tue, 01 Dec 2020 at 10:56:28 +0000, Simon McVittie wrote:
> We can and do autobuild arch-independent packages (since 2015: on the
> timescale of multi-release transitions, this is relatively recent).
>
> However, we cannot currently do arch-independent *binNMUs* [because...]
I've thought in the past that if the inability to do arch-independent
binNMUs can be fixed, it would be a good way to deal with some problems
that we currently face.
If I understand correctly, one of the ftp team's objections to discarding
and rebuilding maintainer-uploaded binaries is that if I upload foo_1.2-3,
and they discard my binary upload and rebuild it on the buildds, this
would result in having two binary builds of foo-bin_1.2-3_amd64.deb and two
binary builds of foo-data_1.2-3_all.deb with the same version number but
potentially different content, breaking the important design principle
that things that are different should have different names.
In the Open Build Service (OBS), which is analogous to wanna-build + sbuild,
the normal configuration is that binaries built by OBS *always* get a
build suffix. For example, if I upload foo_1.2-3 to the OBS instance used
by SteamOS, the result will usually be foo-bin_1.2-3+bsos1_amd64.deb and
foo-data_1.2-3+bsos1_all.deb, because SteamOS' OBS was configured to use
suffix +bsos<BUILD_COUNT> (where bsos is mnemonic for "built for SteamOS"
and <BUILD_COUNT> is an automatically incremented integer).
At the moment, builds in OBS cannot make use of Debian's binNMU machinery
for this, because if they did, they would break the same ${source:Version}
assumption I described in my previous message. The result is that they
have to behave as though +bsos1 was a new sourceful upload, and
foo-bin_1.2-3+bsos1_amd64.deb and foo-data_1.2-3+bsos1_all.deb both have
Source: foo (= 1.2-3+bsos1). Consumers have to "just know" that to
get the source code for foo-bin_1.2-3+bsos1_amd64.deb, you strip the
/\+bsos[0-9]+$/ suffix from the version number before looking for the
foo=1.2-3 source package. Obviously, this scales poorly if you are looking
at multiple derivatives each with its own pseudo-binNMU suffix.
If we had a way to do Architecture: all binNMUs, then OBS would be able to
use it for all builds: for instance, foo-bin_1.2-3+bsos1_amd64.deb and
foo-data_1.2-3+bsos1_all.deb could both have Source: foo (= 1.2-3).
Similarly, we could consider using it in Debian to address the ftp
team's valid concern about having buildd-built binaries whose version
matches different maintainer-built binaries. Instead of starting from
the absence of a binNMU suffix, the buildds could start from +b1, so
that we'd have this workflow:
- maintainer builds, tests and uploads foo_1.2-3
- maintainer's packages are foo_1.2-3.dsc, foo-bin_1.2-3_amd64.deb and
foo-data_1.2-3_all.deb
- or perhaps they would be foo_1.2-3.dsc, foo-bin_1.2-3+b0_amd64.deb and
foo-data_1.2-3+b0_all.deb
- (if NEW) ftp team inspects maintainer-built source and binaries
- ftp machinery discards maintainer-built binaries
- buildd receives foo_1.2-3.dsc
- buildds produce foo-bin_1.2-3+b1_ARCH.deb for each architecture
- Architecture: all buildd produces foo-data_1.2-3+b1_all.deb
and if, later, the release team triggers some binNMUs for a transition:
- buildds produce foo-bin_1.2-3+bN_ARCH.deb, N >= 2, for each architecture
and/or
- Architecture: all buildd produces foo-data_1.2-3+bN_all.deb, N >= 2
smcv
Reply to: