[Rpm-maint] [rpm-software-management/rpm] RFE: multi-arch dependencies (Issue #2197)
Panu Matilainen
notifications at github.com
Wed Feb 26 08:37:44 UTC 2025
pmatilai left a comment (rpm-software-management/rpm#2197)
I still can't help the feeling just piling this data into the dependency tokens themselves in the header is wrong.
For real multiarch, we'd need something like:
1) collect the architectures detected in a package into an array, calling it RPMTAG_ARCHES for now, using notation such as we've been discussing here
2) add a new RPMSENSE_* bit tag to indicate an arch-specific dependency, set for dependencies which carry the arch info - an arch-specific require cannot be satisfied by a provide of the same name from some other architecture (including noarch)
3) for packages with arch-specific dependencies, add index arrays that allow looking up the associated architecture name
4) rpmds* collects this data and emits it in the kind of form we've been discussing here, eg `libfoo.so.1(x86-64l)`
5) when 1) carries more than one arch, this overrides the traditional RPMTAG_ARCH behavior - if a package can carry both x86_64 and ppc64 then we just cannot call it x86_64 or ppc64, can we?
Now, repomd doesn't have a way to carry all this info, and may need to settle for carrying the arch-specific data verbatim. But that doesn't mean that rpm has to be designed to the lowest common denominator.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2197#issuecomment-2684286522
You are receiving this because you are subscribed to this thread.
Message ID: <rpm-software-management/rpm/issues/2197/2684286522 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20250226/a9f3af25/attachment.htm>
More information about the Rpm-maint
mailing list