Re: building fewer packages or reduced functionality on i386

On Sat, 15 Aug 2026 at 05:20:27 +0900, Simon Richter wrote:
>On 8/14/26 23:24, Charles Plessy wrote:
>>I would appreciate if there would be easier way to turn off (and on)
>>i386 or any future new partial relesease without having to update
>>control fields and reupload a package and its whole dependency chain.

I'm not sure how much value we necessarily get from prematurely 
generalizing this. 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. Is 
there any other architecture where we can expect both facts to be true?

amd64 has a significant amount of binary-only software, but I don't see 
us discontinuing amd64 in the next few decades. (If we imagine a future 
where x86 hardware is no longer produced, we'd probably still want an 
amd64 partial architecture that could run old software under emulation, 
but I don't think that's a realistic possibility any time soon!)

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.

(Of course armhf does have a significant amount of binary-only software 
*for Android*, but I don't think that's directly relevant here.)

>Short-term we could probably reuse the build-dependency hack, where an 
>empty package is only available on a subset of architectures, so 
>buildds can never build the package on any others.

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.

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; and then we could build it with a "partial-arch" profile, 
and packages that don't want to be buildable on i386 could use:

     Build-Depends: unsupported-architecture <partial-arch>, ...

Building i386 with the noudeb build profile would also be an immediate 
reduction in how much compiling is needed, because i386 no longer has 
d-i, so there is nothing that will use the udebs.

Perhaps someone involved in operating the buildds could comment on 
whether setting some Build-Profiles by default for an architecture is 
easy or difficult to achieve?

That could also make it easier for a source package to build on i386 
with reduced functionality (for example disabling a GUI, or something 
needed during boot), instead of having an all-or-nothing choice between 
building it fully-functional or not at all:

     Build-Depends:
       libbasic-dev,
       libgui-dev <!partial-arch>,

     ...

     Package: foo-gui
     Build-Profiles: <!partial-arch>

If we want other equivalence classes of architectures, then build-profiles 
or the architecture-properties package seem like they would be the way 
to gate that.

For example we could classify architectures into those where a GUI might 
be practically useful (everything except s390x) and those where it isn't 
(s390x), or those that could be useful for "heavy" CPU-bound computation 
like scientific software (amd64, arm64) and those that most likely 
aren't (riscv64, loong64).

As with any feature reduction, turning off packages per-architecture 
without breaking dependencies needs to start from leaf packages, and work 
inwards towards core packages.

     smcv