On Tue, 01 Dec 2020 at 11:05:54 +0100, Jonas Smedegaard wrote:
> Can someone remind me: Why is it that we cannot do arch-independent
> auto-building?
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 a
large number of packages have patterns like this:
Source: foo
Package: foo-bin
Architecture: any
Depends: foo-data (= ${source:Version})
Package: foo-data
Architecture: all
which is based on the assumption that foo-data cannot be binNMU'd.
For example, consider foo_1.2-3, and suppose it has been binNMU'd 5
times on amd64, so we have foo-bin_1.2-3+b5_amd64.deb and
foo-data_1.2-3_all.deb. foo-bin Depends: foo-data (= 1.2-3) and the
dependency is satisfied.
Now suppose we also binNMU foo-data. We get foo-data_1.2-3+b1_all.deb,
which no longer satisfies foo-data (= 1.2-3), so foo-bin is uninstallable.
https://lintian.debian.org/tags/maybe-not-arch-all-binnmuable.html lists
622 affected packages. I don't know whether there are other problematic
patterns that Lintian does not detect.
Possible solutions:
- Change at least 622 packages so they have something more like
Depends: foo-data (>= ${source:Version}), foo-data (<< ${source:Version}+c)
(also hope that all of their maintainers can get those runes right, taking
into account what the binNMU suffix is, and hope that it won't break
derivatives like Ubuntu that use a source-upload suffix like ubuntu1 that
compares less than +b1)
- Change at least 622 packages so that when foo-data is binNMU'd, it
automatically gets Provides: foo-data (= 1.2-3)
- Change some more central component so that the dependencies are edited
or the Provides is added globally
- Something clever that I haven't thought of
smcv
