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/2684286...@github.com>
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
https://lists.rpm.org/mailman/listinfo/rpm-maint
