The build system already scans every file in a split package for ELF metadata (for dependency and provision detection). This same
data can determine the package's architecture automatically rather than inheriting it from the parent recipe's archs field.
The rule:
- All ELF files share the same architecture → package arch is that architecture
- No ELF files present → package arch is any
- Mixed ELF architectures → build error
This would allow arch-independent split packages (like ca-certs, which contains only certificate files) to be correctly tagged as
any without any recipe changes. An any-arch package built once could be shared across all architectures in the repo, avoiding
redundant builds.
The archs field in the recipe continues to serve its current purpose: declaring which architectures the recipe is intended to be
built on. The package-level arch becomes an output of the build, not an input.
The build system already scans every file in a split package for ELF metadata (for dependency and provision detection). This same
data can determine the package's architecture automatically rather than inheriting it from the parent recipe's archs field.
The rule:
- All ELF files share the same architecture → package arch is that architecture
- No ELF files present → package arch is any
- Mixed ELF architectures → build error
This would allow arch-independent split packages (like ca-certs, which contains only certificate files) to be correctly tagged as
any without any recipe changes. An any-arch package built once could be shared across all architectures in the repo, avoiding
redundant builds.
The archs field in the recipe continues to serve its current purpose: declaring which architectures the recipe is intended to be
built on. The package-level arch becomes an output of the build, not an input.