#49888 Auto-provides / requires for private perl modules should be filtered
Closed: wontfix 2 years ago by mreynolds. Opened 3 years ago by mreynolds.

Ticket was cloned from Red Hat Bugzilla (product Fedora): Bug 1607633

389-ds-base installs a number of perl modules to a private location:

[adamw@id ~]$ ls -l /usr/lib64/dirsrv/perl
total 264
-rw-r--r--. 1 root root  4394 Jun 21 10:10 DialogManager.pm
-rw-r--r--. 1 root root  7962 Jun 21 10:10 Dialog.pm
-rw-r--r--. 1 root root 54470 Jun 21 10:10 DSCreate.pm
-rw-r--r--. 1 root root  7143 Jun 21 10:10 DSDialogs.pm
-rw-r--r--. 1 root root 44895 Jun 21 10:10 DSMigration.pm
-rw-r--r--. 1 root root  4813 Jun 21 10:10 DSUpdateDialogs.pm
-rw-r--r--. 1 root root 18734 Jun 21 10:10 DSUpdate.pm
-rw-r--r--. 1 root root 57185 Jun 21 10:10 DSUtil.pm
-rw-r--r--. 1 root root 11662 Jun 21 10:10 FileConn.pm
-rw-r--r--. 1 root root  7642 Jun 21 10:10 Inf.pm
-rw-r--r--. 1 root root 11848 Jun 21 10:10 Migration.pm
-rw-r--r--. 1 root root  3530 Jun 21 10:10 Resource.pm
-rw-r--r--. 1 root root  7163 Jun 21 10:10 SetupDialogs.pm
-rw-r--r--. 1 root root  1876 Jun 21 10:10 SetupLog.pm
-rw-r--r--. 1 root root  7051 Jun 21 10:10 Setup.pm

the 389-ds-base package has auto-generated Provides for all these modules:

[adamw@id ~]$ rpm -q --provides 389-ds-base | grep perl
perl(DSCreate)
perl(DSDialogs)
perl(DSMigration)
perl(DSUpdate)
perl(DSUpdateDialogs)
perl(DSUtil)
perl(Dialog)
perl(DialogManager)
perl(DialogYesNo)
perl(FileConn)
perl(Inf)
perl(Migration)
perl(Resource)
perl(Setup)
perl(SetupDialogs)
perl(SetupLog)

(note, some/all of these scripts have been moved to 389-ds-base-legacy-tools in
F28 updates-testing / Rawhide - the bug is still valid, just obviously as
applied to that binary package).

per the perl packaging guidelines -
https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering#Perl
- these automatic Provides should probably be filtered out. This case is
directly comparable to the Pidgin example given:

"On a x86_64 machine, the pidgin-libnotify provides
pidgin-libnotify.so()(64bit) which it shouldn't as this library is not inside
the paths searched by the system for libraries. It's a private, not global,
"provides" and as such must not be exposed globally by RPM."

Note that there are also some automatic Requires generated for these modules -
those too should be filtered out, and any dependencies between binary packages
handled manually instead.

Especially as some of these Provides have quite generic names - there is
already a distribution called Setup in cpan, for instance - they could actually
be 'dangerous'. We don't want something that depends on a known perl module
called Setup, for instance, getting 389-ds-base (or 389-ds-base-legacy-tools)
installed instead of perl-Setup or whatever the 'normal' package is called.

Metadata Update from @mreynolds:
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1607633

3 years ago

Metadata Update from @mreynolds:
- Issue assigned to mreynolds

3 years ago

Metadata Update from @mreynolds:
- Custom field component adjusted to None
- Custom field origin adjusted to None
- Custom field reviewstatus adjusted to review
- Custom field type adjusted to None
- Custom field version adjusted to None
- Issue set to the milestone: 1.4.0 (was: 0.0 NEEDS_TRIAGE)

3 years ago

Metadata Update from @vashirov:
- Custom field reviewstatus adjusted to ack (was: review)

3 years ago

Metadata Update from @mreynolds:
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)

3 years ago

This doesn't seem to be fully resolved, at least not in F29.

Also I notice all these Provides for 389-ds-base which seem bogus:

libacctpolicy-plugin.so()(64bit)
libacctusability-plugin.so()(64bit)
libacl-plugin.so()(64bit)
libaddn-plugin.so()(64bit)
libattr-unique-plugin.so()(64bit)
libautomember-plugin.so()(64bit)
libback-ldbm.so()(64bit)
libbitwise-plugin.so()(64bit)
libchainingdb-plugin.so()(64bit)
libcollation-plugin.so()(64bit)
libcontentsync-plugin.so()(64bit)
libcos-plugin.so()(64bit)
libderef-plugin.so()(64bit)
libdistrib-plugin.so()(64bit)
libdna-plugin.so()(64bit)
libhttp-client-plugin.so()(64bit)
liblinkedattrs-plugin.so()(64bit)
libmanagedentries-plugin.so()(64bit)
libmemberof-plugin.so()(64bit)
libpam-passthru-plugin.so()(64bit)
libpassthru-plugin.so()(64bit)
libpbe-plugin.so()(64bit)
libposix-winsync-plugin.so()(64bit)
libpwdstorage-plugin.so()(64bit)
libreferint-plugin.so()(64bit)
libreplication-plugin.so()(64bit)
libretrocl-plugin.so()(64bit)
libroles-plugin.so()(64bit)
librootdn-access-plugin.so()(64bit)
libschemareload-plugin.so()(64bit)
libstatechange-plugin.so()(64bit)
libsyntax-plugin.so()(64bit)
libusn-plugin.so()(64bit)
libviews-plugin.so()(64bit)
libwhoami-plugin.so()(64bit)

those are all plugins of some kind which are not in a directory that's on the system linker path, AFAIK; they should not be listed as package Provides...

Metadata Update from @vashirov:
- Issue status updated to: Open (was: Closed)

2 years ago

Console and legacy pacakges are going away, closing....

Metadata Update from @mreynolds:
- Issue close_status updated to: wontfix
- Issue status updated to: Closed (was: Open)

2 years ago

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/2947

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.

Metadata