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:
https://github.com/rpm-software-management/rpm/pull/1038#issuecomment-689471380
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
