Bug 1464368
Summary: | RFE: avoid generating requires for 'lib*.so' on non-default library paths (e.g. %_libdir/pgsql) | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Pavel Raiskup <praiskup> |
Component: | rpm | Assignee: | Panu Matilainen <pmatilai> |
Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | rawhide | CC: | kardos.lubos, mdomonko, packaging-team-maint, pmatilai, ppisar, vmukhame |
Target Milestone: | --- | Keywords: | Reopened, Triaged |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2024-01-24 09:42:25 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: |
Description
Pavel Raiskup
2017-06-23 09:13:58 UTC
How RPM knows target's ld.so.conf? IMO should be handled by packagers why really know that this is private libdir. "Somebody" should know what are the default paths. Perhaps that's not RPM itself but really.. it doesn't make sense to bother maintainers. I think this might be valid RFE for redhat-rpm-config instead, yes. FWIW, libtool want's to deal with default paths (for rpath handling) by: http://git.savannah.gnu.org/cgit/libtool.git/tree/m4/libtool.m4?id=6ca5e224bc7bcc114a9ba2cf5dcf0fbf0ec40c9f#n2898 This was added into the spec file: +# https://bugzilla.redhat.com/1464368 +%filter_provides_in %{_libdir}/pgsql +%filter_setup But one should define __provides_exclude_from macro <https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering#Preventing_files.2Fdirectories_from_being_scanned_for_deps_.28pre-scan_filtering.29>. The filter_* macros are deprecated and should not be used because they break file coloring in some cases and in general, are incompatible with the new *_exclude* macros. This is one of those annual requests... If provides get filtered then requires need to be filtered too, and then like Igor notes one should parse ld.so.conf[.d] and even that's not really enough because there's rpath - see eg libreoffice and it's subcomponents for a case where dependencies to libraries in what's decidedly a private path are actually necessary, and then the provides for those need to be present. How's rpm supposed to know? Sorry, WONTFIX and the same goes for redhat-rpm-config. This needs to be dealt with on per-package level as nobody else knows the kinks of that specific package. What I do agree with is that the whole thing could and should be *nicer*. The *_exclude* macros were only ever intended as a low-level mechanism to make filtering *possible*, on top of which something nicer could be created. Only that never happened. Also the *exclude* filter macros are not suited for part global, part local filters at all. Private directories are one of the more common filtering situations of course, perhaps there could be a way to declare them in some nice spec-level directive. But that's beyond the scope of this bug. (In reply to Panu Matilainen from comment #6) > This is one of those annual requests... Right, so let's resolve it :) ! > If provides get filtered then requires need to be filtered too, and then > like Igor notes one should parse ld.so.conf[.d] and even that's not really > enough because there's rpath If parsing of ld.so.conf is needed, please do so. If that's too complicated, teach ld to provide some more useful info so we don't have to parse it ourselves ... but please let's find a solution. > - see eg libreoffice and it's subcomponents for > a case where dependencies to libraries in what's decidedly a private path > are actually necessary, and then the provides for those need to be present. > How's rpm supposed to know? This is ugly, because searching through subdirs + exclude is now "opt-out", having "opt-in" feature would be much nicer (as there's considerably more packages *not* using %_libdir/SUBDIR for libs then vice-versa). How it comes that packages which play fairly with the system and install *only* libraries into %_libdir/ (without adjusting ld.* conf) need to install some filtering hacks? > Sorry, WONTFIX and the same goes for redhat-rpm-config. This needs to be > dealt with on per-package level as nobody else knows the kinks of that > specific package. Feel free to switch against whatever component is needed; and I don't think the situation is that bad ... > What I do agree with is that the whole thing could and should be *nicer*. > The *_exclude* macros were only ever intended as a low-level mechanism to > make filtering *possible*, on top of which something nicer could be created. > Only that never happened. Also the *exclude* filter macros are not suited > for part global, part local filters at all. > > Private directories are one of the more common filtering situations of > course, perhaps there could be a way to declare them in some nice > spec-level directive. But that's beyond the scope of this bug. I would be OK if we had _that_ solution; if it wouldn't require me to doing hacks in spec file. But so far it seems to be valid RFE at least. *** This bug has been marked as a duplicate of bug 2259260 *** Just in case somebody misses the closing comment on the dupe: I started an upstream discussion on this: https://github.com/rpm-software-management/rpm/discussions/2872 Let's continue this there. For anybody not on GH, discussions are gated to rpm-maint email list too. |