Bug 1320954
Summary: | rpm: Support equivalent of Debian's symbols files for finer-grained ELF dependencies | |||
---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Florian Weimer <fweimer> | |
Component: | rpm | Assignee: | Packaging Maintenance Team <packaging-team-maint> | |
Status: | CLOSED WORKSFORME | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | |
Severity: | unspecified | Docs Contact: | ||
Priority: | unspecified | |||
Version: | rawhide | CC: | codonell, glebfm, igor.raits, jorton, jzeleny, ksrot, lslebodn, ngompa13, novyjindrich, packaging-team-maint, pknirsch, samuel-rhbugs | |
Target Milestone: | --- | Keywords: | FutureFeature | |
Target Release: | --- | |||
Hardware: | Unspecified | |||
OS: | Unspecified | |||
Whiteboard: | ||||
Fixed In Version: | Doc Type: | Enhancement | ||
Doc Text: | Story Points: | --- | ||
Clone Of: | ||||
: | 1320960 (view as bug list) | Environment: | ||
Last Closed: | 2021-06-27 18:31:03 UTC | Type: | Bug | |
Regression: | --- | Mount Type: | --- | |
Documentation: | --- | CRM: | ||
Verified Versions: | Category: | --- | ||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
Cloudforms Team: | --- | Target Upstream Version: | ||
Embargoed: | ||||
Bug Depends On: | ||||
Bug Blocks: | 1320960 |
Description
Florian Weimer
2016-03-24 11:06:54 UTC
So here's a thought... Could we use the new richop 'with' to provide this kind of capability? For example: "Provides: libc.so.6(GLIBC_2.18)(64bit) with libc.so.6(__cxa_thread_atexit_impl)(64bit)" This is similar to what we're doing in Rust for handling features[1]. You can see it in action in the Rust playground COPR[2]. By generating granular Provides and Requires in this manner, you would achieve the same goal. [1]: https://fedoraproject.org/wiki/PackagingDrafts/Rust [2]: https://copr.fedorainfracloud.org/coprs/g/rust/playground/ (In reply to Neal Gompa from comment #1) > So here's a thought... Could we use the new richop 'with' to provide this > kind of capability? > > For example: > > "Provides: libc.so.6(GLIBC_2.18)(64bit) with > libc.so.6(__cxa_thread_atexit_impl)(64bit)" I don't see what this would accomplish. There is a benefit from rich dependencies, though. We could write Requires: libc.so.6(GLIBC_2.18)(64bit) or libc.so.6(__cxa_thread_atexit_impl)(64bit) with just: Provides: libc.so.6(__cxa_thread_atexit_impl)(64bit) for backports. This would provide compatibility with already-released glibc packages, and we wouldn't have to add symbol-based Provides: to all future glibc packages. > This is similar to what we're doing in Rust for handling features[1]. > [1]: https://fedoraproject.org/wiki/PackagingDrafts/Rust This doesn't make sense to me, either. It is something that BuildConflicts should be able to handle with regular Provides:. I sent a pretty detailed answer to why in rpm-ecosystem ML[1], but the long and short of it is that your strategy only works as long as it's only one level. Once you have multiple levels, BuildConflicts breaks your build. As for using the richop, the idea is to avoid doing too much weird mangling. Consider the following: (libc.so.6(GLIBC_2.18)(64bit) with libc.so.6(__cxa_thread_atexit_impl)(64bit)) The above clause indicates that it is glibc 2.18 with the function symbol __cxa_thread_atexit_impl. It maintains compatibility with function symbol-less dependencies, and so on. Your proposed idea of having both current style and your full symbol would work as well, but it contains the redundant GLIBC_2.18 symbol. Heck, we could probably slim it down a bit more by not including "(64bit)" on the function symbol name. One thing I don't particularly like is the usage of "(64bit)" instead of the actual system architecture (or even just %{?_isa}), but that's how we do things now anyway... If we had my way, the generate library dependency names would look something like this: (libc.so.6(GLIBC_2.18)(x86-64) with libc.so.6(__cxa_thread_atexit_impl)) Or even if we did it the way you propose with: libc.so.6(__cxa_thread_atexit_impl)(x86-64) [1]: http://lists.rpm.org/pipermail/rpm-ecosystem/2017-February/000471.html I think the existing dependency generator framework can be used to implement this on a per-package basis if needed. |