On Wed, Sep 14, 2022 at 01:38:01PM +0200, Guillem Jover wrote: >... > [ Mostly to summarize the status re dpkg. ] >... > * Lack of bits/endianness arch "aliases" (#962848). The main problem > with this one is that we cannot simply add such aliases, as then > those would silently be considered as regular arches, and they do > not map into the current naming convention at all. These would need > to be added with a breaking syntax (say with some non-accepted > char, such as % or whatever) so that they do not introduce silent > breakage. This would then need to be supported by anything > handling arch restrictions (field and dependencies) which can be a > rather large surface. Then there is the problem that architectures > are evaluated as ORed lists, and the bits/endianness might require > to be treated as ANDed lists some times (of course the latter > could be handled by combining them into single aliases, but meh).
If we limit the problem to avoiding build failures in cases that upstream does not support, there would be the trivial solution of having a package ship Provides like: - architecture-is-64bit - architecture-is-32bit - architecture-is-little-endian - architecture-is-big-endian - architecture-has-64bit-timet -... Build-Depends: architecture-is-64bit, architecture-is-little-endian,... would be a package that only supports 64bit little endian architectures, and that would never be attempted to build on 32bit or big endian architectures. The buildd page would then show for i386: mypackage build-depends on missing: - architecture-is-64bit Not building a source package on one specific architecture could already today be achieved with: Build-Depends: package-is-broken-on-ppc64el [ppc64el],... This might not be the most elegant solution, but it should be sufficient to solve the problem in this thread and it does not require any tool changes. > Thanks, > Guillem cu Adrian
