Re: building fewer packages or reduced functionality on i386

Simon Richter <[email protected]> Sat, 15 Aug 2026 20:13:32 +0900
Newsgroups	gmane.linux.debian.devel.general
Message-ID	<[email protected]>
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 (application/pgp-signature, 488 B)