Hi! On Sun, 2026-10-11 at 03:31:34 +0900, Simon Richter wrote: > I have a package where my build dependencies change based on host > endianness, and I also need to generate dependencies in the binaries > based on endianness.
To avoid hardcoding arch lists in theory you could use one of the virtual packages from architecture-properties in build dependencies, such as: architecture-is-64-bit | foo-for-32-bit, architecture-is-little-endian | bar-for-big-endian, But this is rather hackish, and in addition it should not work on Debian buildds where (AFAIR) only the first alternative is ever considered. For run-time dependencies you could inject the arch list via a substvar, by fetching the values from something like: dpkg-architecture --match-bits 64 --list-known dpkg-architecture --match-endian little --list-known > 1. Does it make sense to add arch restrictions [bigendian] and > [littleendian] so I don't have to list the known big and little > endian architectures? I think it would be nice, alongside bitness, but not by using the same namespaces as architectures. This same thing was requested in #962848, (and I thought I replied, but perhaps only on IRC or private mail or something? Or maybe in conversations with Niels, that ended up with the current architecture-properties approach). I also now just found references to something like this in #630342. Reusing the arch namespace means that declaring these dependencies will silently not get satisfied until all resolvers get updated, which I think would be rather bad. To me this calls for a breaking change, by adding some new syntax that hopefully separates this notation from existing arch names. I've just not been sure what to use here, and I shudder at this type of "update all resolvers" kind of change. And the existing approach while a bit cumbersome (and TBH a workaround for a limitation in the base tools), just works for most stuff right now (but not your first case) and requires no ecosystem-wide changes to the syntax. If our arch tuples were a bit more rich, then we could probably match on those attributes, but then there are other attributes that we might eventually also want to match on that would not be present anyway. The first thing that comes to mind might be something like: arch:32-bit arch:64-bit arch:little-endian arch:big-endian or perhaps: arch:bits:32 arch:bits:64 arch:endian:little arch:endian:big or variations on that, perhaps arch:<attr>=<value>, dunno. Where this could make it possible to extend to other arch attributes (although I'm not sure any other attributes might be very useful), such as for example: arch:char:signed arch:char:unsigned arch:exec:elf arch:exec:mach-o … In any case there might be other/better ways to represent this. And the prefix at least feels a bit redundant when used in an Architecture field. I guess another problem is that resolvers would need (ideally) to get the information about these attributes from the dpkg arch tables, but that might be annoying to deploy or rely on. Thus this might need input from at least the major resolver implementations. > 2. Does it make sense to add a predefined substvar "Endian" that > gives the same value as "dpkg-architecture -qDEB_HOST_ARCH_ENDIAN"? Probably, and I actually had implemented this some time ago, but was not sure whether it was worth it, so ended up not merging it: https://git.hadrons.org/cgit/debian/dpkg/dpkg.git/commit/?h=next/substvars-arch&id=87b68cee48a3ce66cd93c145d78491c67e9ed8aa But if there's demand, I'm happy to merge it, after I've cleaned this a bit. Thanks, Guillem
