[Rpm-maint] [rpm-software-management/rpm] RFE: Integrate ALT set-versions to improve ELF library dependency generation (Discussion #3634)
Gordon Messmer
notifications at github.com
Sun Jun 1 02:46:58 UTC 2025
> each symbol name is hashed, then the set of hashes is compressed.
OK, that makes sense.
> Note that video recording is also available
Sadly, having watched the video, I don't think it adds much to the slides.
TL;DR: What this system lacks in clarity, it makes up for in complexity.
Hash collisions aside, I think I see how this works. But the question I'd ask is simply: Is there value in having human-readable dependencies? Because, if there is, then it isn't great that this system produces dependencies that are just a set of hashes, and there is no way for a human to understand what is missing when something doesn't resolve. And if there is not, then why wouldn't we just convert *all* RPM dependencies to hashes that are resolved as sets? That would provide all of the same advantages, globally, that were described for this system over naive approaches of listing all of the symbols individually.
There's a description in the slides about the set system being "too clever". I would phrase that a different way. I think the set system *acknowledges* that there are scalability limitations to the dep solver, and instead of solving those limitations, the set system is just an end-run around the problem.
Arguably, *any* solution that doesn't let us include a full list of symbols is an end-run around the problem. But this one is much more complex than other solutions (e.g. adding a version to the description of a shared object). And I think a lot of developers would worry about maintenance overhead when adopting new features that "uses relatively uncommon algorithms" and "takes efforts and time to understand." What's the return on that additional complexity?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/3634#discussioncomment-13332100
You are receiving this because you are subscribed to this thread.
Message ID: <rpm-software-management/rpm/repo-discussions/3634/comments/13332100 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20250531/79c6b97a/attachment.htm>
More information about the Rpm-maint
mailing list