Hi, On 8/15/26 18:43, Simon McVittie wrote:
I'm not sure how much value we necessarily get from prematurely generalizing this.
The problem is similar to what we have on some ports: there are some packages that take up a lot of attention, but we can already tell with some confidence that there are zero users of the software on that port.
If we can solve that problem as well in the same iteration, maintainers only need to touch their packages once.
i386 is special because it's an architecture that we don't want to support on its native hardware (32-bit CPUs) any more, AND there's a significant amount of legacy binary-only software for it (either directly for i386-linux-gnu, or for 32-bit Windows via Wine), which we can conveniently run on newer-but-backward-compatible CPUs.
i386 is extra special because shifting the baseline can already break the old binary-only software, but exactly this bug compatibility is causing the problems for the numeric packages.
What makes it less special is that it's the same packages across a bigger set of architectures, and that set is also changing as we're adding low-power architectures.
armel, armhf, s390 and powerpc all have/had newer-but-backward- compatible CPUs that could run them (armhf/arm64, arm64, s390x and ppc64 respectively), but they never had a significant amount of binary-only software that we can run, and the 64-bit time_t transition has broken their ABIs anyway, so they don't seem practically useful as partial architectures.
armel, armhf and powerpc are useful as partial architectures because the hardware still exists and is still used, but the shifting baseline for the "modern" variant drops support for them.
Spending any porter or maintainer time to make numerical software run is a waste of time, like on i386, but for something like a BMC we absolutely want up-to-date network services.
It's a different scenario from i386 compatibility, but it seems to have a very similar solution.
[Short-term]
Perhaps architecture-properties:amd64 etc. Provides: architecture-is- full or architecture-is-not-partial, architecture-properties:i386 doesn't provide it, and your package Build-Depends on that name? That would be a generalization of having a Build-Depends: unsupported- architecture [i386], which is what can be done right now.
Yes, that's what I was thinking -- anything to avoid a fixed list of architectures, because that means mass changes to packages whenever the list changes.
The other obvious way I can see to do this with existing mechanisms is if the buildds could be configured to add some Build-Profiles when building i386;
I think this would most likely work, but especially
Build-Depends: unsupported-architecture <partial-arch>, ...
should be an intermediate solution, because it is still a hack that needs to be compensated for in other places -- e.g. if I want to know how well an architecture is holding up, and I see that there are 3000 packages with unfulfillable build dependencies, I have to dig deeper in whether these are actually meant to be unfulfillable or if it is qt6.
For the same reason, I'd like to move "arch-is-64-bit" and "arch-is-little-endian" into a dedicated mechanism at some point. This is not something we should need a dependency solver for.
I think that *having* that intermediate solution is valuable on its own, because it allows us to understand the problem fully before extending an interface that's documented in Debian Policy.
Simon
OpenPGP_signature.asc
Description: OpenPGP digital signature
