Bug 1464368 - RFE: avoid generating requires for 'lib*.so' on non-default library paths (e.g. %_libdir/pgsql)
RFE: avoid generating requires for 'lib*.so' on non-default library paths (e....
Status: NEW
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: packaging-team-maint
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-06-23 05:13 EDT by Pavel Raiskup
Modified: 2017-06-26 06:07 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-06-26 03:29:24 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Pavel Raiskup 2017-06-23 05:13:58 EDT
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 05:15:24 EDT
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 05:17:24 EDT
"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 05:20:35 EDT
I think this might be valid RFE for redhat-rpm-config instead, yes.
Comment 4 Pavel Raiskup 2017-06-23 05:22:35 EDT
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 02:37:49 EDT
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 03:29:24 EDT
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 06:07:54 EDT
(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.

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