Bug 1464368 - RFE: avoid generating requires for 'lib*.so' on non-default library paths (e.g. %_libdir/pgsql)
Summary: RFE: avoid generating requires for 'lib*.so' on non-default library paths (e....
Keywords:
Status: CLOSED DUPLICATE of bug 2259260
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Panu Matilainen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-06-23 09:13 UTC by Pavel Raiskup
Modified: 2024-01-24 09:43 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2024-01-24 09:42:25 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github rpm-software-management/rpm/discussions/2872 0 None None None 2024-01-24 09:42:25 UTC

Description Pavel Raiskup 2017-06-23 09:13:58 UTC
For postgresql, we install /usr/lib64/pgsql/libpqwalreceiver.so plugin,
which causes generating of 'libpqwalreceiver.so()(64bit)' provides (on
x86_64).

It would be nice if this provides was filtered out by default -- without
using explicit %filter_provides_in %_libdir/pgsql macro.

There are many more plugins in %_libdir/pgsql, but seems like the 'lib*'
prefix causes that rpm thinks this is library instead of plugin.

Comment 1 Igor Gnatenko 2017-06-23 09:15:24 UTC
How RPM knows target's ld.so.conf?

IMO should be handled by packagers why really know that this is private libdir.

Comment 2 Pavel Raiskup 2017-06-23 09:17:24 UTC
"Somebody" should know what are the default paths.  Perhaps that's not RPM
itself but really..  it doesn't make sense to bother maintainers.

Comment 3 Igor Gnatenko 2017-06-23 09:20:35 UTC
I think this might be valid RFE for redhat-rpm-config instead, yes.

Comment 4 Pavel Raiskup 2017-06-23 09:22:35 UTC
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

Comment 5 Petr Pisar 2017-06-26 06:37:49 UTC
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.

Comment 6 Panu Matilainen 2017-06-26 07:29:24 UTC
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.

Comment 7 Pavel Raiskup 2017-06-26 10:07:54 UTC
(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.

Comment 8 Panu Matilainen 2024-01-24 09:42:25 UTC

*** This bug has been marked as a duplicate of bug 2259260 ***

Comment 9 Panu Matilainen 2024-01-24 09:43:22 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.