Quoting Simon McVittie (2020-12-01 11:56:28) > 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).
Yes - thanks for catching and tightening my far too sloppy framing of
the issue at hand.
> 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.
Thanks for the excellent explanation.
(and sorry for my failing memory: I am sure someone explained it to me
at least once before, related to debian-installer image building)
> 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
- Introduce a control field "Build-Dependencies-Require-Rebuild: no"
(similar to "Rules-Requires-Root: no")
I mean, we could limit BinNMUing to packages that pre-declares that they
have taken into account the possibility of version skew not only for
arch-specific but also arch-independent package relations.
Yes, It feels wrong to introduce an explicit control field for that, but
there is a real benefit here for packages using doxygen, and there is a
real benefit for JavaScript packages in general, and I am sure other
areas as well (including possibly the debian-installer images?).
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
