[Rpm-maint] [rpm-software-management/rpm] elfdeps: Add full multiarch deps support (#1038)
notifications at github.com
Wed Sep 9 10:23:29 UTC 2020
Been thinking about this on and off. I'm totally convinced that we should record the dependency architecture, rather than the existing super dumb ()64bit() marker thing. I'm just far less convinced that the architecture should be embedded in each and every dependency string we store.
If we store the extracted dependency strings as-is, and associate the arch via a separate indexed arch table there are several benefits available:
- The dependency strings are identical across architectures, making data compress better and making comparisons and queries saner, dependency on zlib is always "libz.so.1" and not some associated mumble
- As the extracted dependency architectures are stored as an array of their own, we gain a kind of an automatic RPMTAG_ARCH replacement that is an array consisting of all the architectures this package depends on/provides something for. A "normal" package would of course only have one arch in there, but it might open up interesting possibilities to handle this generally.
- Constructing dep(marker) style strings out of these arrays is easy if needed for eg repodata (in the short term)
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Rpm-maint