Re: Why NOARCH packages aren't available on all architectures?

Am 06.08.22 um 09:40 schrieb Tatsuki Makino:
> Hmmm, it seems to me that this is a problem due to the difference between noarch being a tag-like classification and packages being provided in a tree-like classification for each architecture.

Yes, this is the result of how NO_ARCH packages are being built on each 
architecture.

The NO_ARCH macro causes the machine part of the architecture to be set
to "*" in the package, but it does not actually lead to such packages
being shared between architectures.

In a prior discussion about this topic bapt mentioned that ports marked as
NO_ARCH should only be built once and then distributed to all repositories.
But this is not a trivial change to the build system.

> And other things, like that reason for the file system not being able to create hard links of directory.
> Like, we can' t bypass the tree map and follow it... etc...

I'd think that a package marked NO_ARCH that has successfully been built
on one architecture could be made available in all repositories. But such
packages would not be available if depended on in the current build batch.

One possible solution could be to build all NO_ARCH packages (and all their
build dependencies) on one architecture that has fast package builders, e.g.
amd64, then to seed all repositories for all architectures with the resulting
NO_ARCH packages before they are started based on the same ports commit that
had been used to generate those NO_ARCH packages. This would make at least
all NO_ARCH packages available that can be built in e.g. amd64. If some have
not been provided in the initial NO_ARCH build on amd64, they still might be
built for individual architectures with all the architecture dependent ports.

Such a procedure would require finishing the initial NO_ARCH build before the
builds for all architectures are started, but if NO_ARCH packages were built
on the fastest package builders, this could even reduce overall build times.

This would make more NO_ARCH packages available than are currently provided,
but if the reason a NO_ARCH package cannot be built on some architecture is
a missing interpreter (e.g. Python version 3.9) than this interpreter will
also be required at run time - the NO_ARCH package would therefore be of
little use ...

Regards, STefan