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
