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
Metadata Update from @mreynolds: - Issue assigned to mreynolds
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)
Metadata Update from @vashirov: - Custom field reviewstatus adjusted to ack (was: review)
Metadata Update from @mreynolds: - Issue close_status updated to: fixed - Issue status updated to: Closed (was: Open)
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)
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)
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.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Login to comment on this ticket.