Upstream ticket:
https://pagure.io/389-ds-base/issue/49888

This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle.
Changing version to '29'.

This still seems valid in F29, to me:

[adamw@id ~]$ rpm -q --provides 389-ds-base-legacy-tools | 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)
[adamw@id ~]$ rpm -q 389-ds-base-legacy-tools
389-ds-base-legacy-tools-1.4.0.16-1.fc29.x86_64

Can confirm, this still happens in F30:

$ rpm -q --provides 389-ds-base-legacy-tools | 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)

~
$ rpm -q 389-ds-base 
389-ds-base-1.4.1.6-1.fc30.x86_64

I had previously followed:

https://docs.fedoraproject.org/en-US/packaging-guidelines/AutoProvidesAndRequiresFiltering/#Perl

and added:

%{?perl_default_filter}

What else needs to be done?

From specfile:

%package          legacy-tools
Summary:          Legacy utilities for 389 Directory Server (%{variant})
Group:            System Environment/Daemons
Obsoletes:        %{name} <= 1.4.0.9
Requires:         %{name} = %{version}-%{release}
%if %{use_perl}
# for setup-ds.pl to support ipv6
%if %{use_Socket6}
Requires:         perl-Socket6
%else
Requires:         perl-Socket
%endif
Requires:         perl-NetAddr-IP
# use_openldap assumes perl-Mozilla-LDAP is built with openldap support
Requires:         perl-Mozilla-LDAP
# for setup-ds.pl
Requires:         bind-utils
%{?perl_default_filter}
%endif
# End use perl


--> note "use_perl" is set to 1

This works for me:

%global __provides_exclude_from %{_libdir}/%{pkgname}/perl
%{?perl_default_filter}

yeah, just doing perl_default_filter isn't enough. perl_default_filter is this:

%perl_default_filter %{expand: \
%global __provides_exclude_from %{?__provides_exclude_from:%__provides_exclude_from|}^%{_docdir}
%global __requires_exclude_from %{?__requires_exclude_from:%__requires_exclude_from|}^%{_docdir}
%global __provides_exclude %{?__provides_exclude:%__provides_exclude|}^perl\\\\(VMS|^perl\\\\(Win32|^perl\\\\(DB\\\\)|^perl\\\\(UNIVERSAL\\\\)
%global __requires_exclude %{?__requires_exclude:%__requires_exclude|}^perl\\\\(VMS|^perl\\\\(Win32
}

so it's excluding deps based on files in the docdir, and a few specific 'known bad' things. The docs do cover this, a bit further down, under "Private libraries".

Note, as well as __provides_exclude_from you're going to want to do a __requires_exclude too - otherwise the auto-generated Provides will be filtered out, but there will still be *Requires* for those provides included.

In openqa.spec for e.g. I do this:

%global __provides_exclude_from %{_datadir}/openqa/lib
%global __requires_exclude perl\\((OpenQA|DBIx::Class::Timestamps|MojoDebugHandle|db_helpers|db_profiler|Perl::Critic)

as the docs say, this can be a bit of a pain to maintain - especially you have to keep an eye out for new ones popping up and add them to __requires_exclude - but there isn't really a better way ATM :/ I don't know why we can't have a __requires_exclude_from that matches __provides_exclude_from behaviour, but I guess there's a reason...

An alternative I guess would be to ask one of the perl packaging folks if there's a way you could tweak this stuff upstream such that the dependencies aren't generated in the first place. I dunno if there's a way to do that.

FEDORA-2019-ab85eef8cc has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-ab85eef8cc

(In reply to Viktor Ashirov from comment #6)
> This works for me:
> 
> %global __provides_exclude_from %{_libdir}/%{pkgname}/perl
> %{?perl_default_filter}

This causes rpm errors:

package 389-ds-base-legacy-tools-1.4.1.8-1.fc31.x86_64 requires perl(DSCreate), but none of the providers can be installed: package 389-ds-base-legacy-tools-1.4.1.8-1.fc31.x86_64 requires perl(DSMigration), but none of the providers can be installed: package 389-ds-base-legacy-tools-1.4.1.8-1.fc31.x86_64 requires perl(DSUpdate), but none of the providers can be installed: package 389-ds-base-legacy-tools-1.4.1.8-1.fc31.x86_64 requires perl(DSUtil), but none of the providers can be installed: package 389-ds-base-legacy-tools-1.4.1.8-1.fc31.x86_64 requires perl(Dialog), but none of the providers can be installed: package 389-ds-base-legacy-tools-1.4.1.8-1.fc31.x86_64 requires perl(DialogManager), but none of the providers can be installed: package 389-ds-base-legacy-tools-1.4.1.8-1.fc31.x86_64 requires perl(FileConn), but none of the providers can be installed: package 389-ds-base-legacy-tools-1.4.1.8-1.fc31.x86_64 requires perl(Inf), but none of the providers can be installed: package 389-ds-base-legacy-tools-1.4.1.8-1.fc31.x86_64 requires perl(Migration), but none of the providers can be installed: package 389-ds-base-legacy-tools-1.4.1.8-1.fc31.x86_64 requires perl(Resource), but none of the providers can be installed: package 389-ds-base-legacy-tools-1.4.1.8-1.fc31.x86_64 requires perl(Setup), but none of the providers can be installed: package 389-ds-base-legacy-tools-1.4.1.8-1.fc31.x86_64 requires perl(SetupLog), but none of the providers can be installed: cannot install both 389-ds-base-legacy-tools-1.4.1.6-1.fc31.1.x86_64 and 389-ds-base-legacy-tools-1.4.1.8-1.fc31.x86_64: conflicting requests

FEDORA-2019-d1edc3a2b8 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-d1edc3a2b8

As I said in comment #7, you're meant to filter *both* the provides *and* the requires :)

1.4.1.8-2 dropped %{?perl_default_filter} but didn't drop %global __provides_exclude_from %{_libdir}/%{pkgname}/perl . That isn't going to fix the problem in #c10. The __provides_exclude_from filters out the *Provides* from the packages that are produced...but it does not filter out the auto-generated *Requires* for those provides. As I said in #c7 must add a corresponding %global __requires_exclude line. That should look something like this:

%global __requires_exclude perl\\((DSCreate|DSMigration|DSUpdate|DSUtil|Dialog|DialogManager|FileConn|Inf|Migration|Resource|Setup|SetupLog)

Tested 389-ds-base & 389-ds-base-legacy-tools

$ rpm -q --provides 389-ds-base-legacy-tools | grep perl
$ rpm -q --requires 389-ds-base-legacy-tools | grep perl
/usr/bin/perl
perl-Mozilla-LDAP
perl-NetAddr-IP
perl-Socket

$ rpm -q --provides 389-ds-base | grep perl
$ rpm -q --requires 389-ds-base | grep perl
/usr/bin/perl
perl(:MODULE_COMPAT_5.28.2)
perl-Archive-Tar
perl-DB_File



None of these perl requirements are related to legacy tools or DS perlk modules, so I think we are finally good to go.  If there is another test I should do before I do a new build please let me know.

that looks fine. One note, you could probably also put the default filter back, it probably wasn't causing any problems in the first place.

This message is a reminder that Fedora 29 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '29'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 29 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

so, I'm not sure where we're up to here.

The bug is against F29, but no work on this seems to have been done on F29.

On F30, F31 and master, there was a commit on 2019-09-27 (so back when we were discussing it here) which tried to fix the filters. Then on F30 - but not on F31 or master - all the filtering stuff was removed on Oct 15 on the basis that it caused some kind of unspecified 'regressions'.

Mark, what is the current status here?

(In reply to Adam Williamson from comment #17)
> so, I'm not sure where we're up to here.
> 
> The bug is against F29, but no work on this seems to have been done on F29.
> 
> On F30, F31 and master, there was a commit on 2019-09-27 (so back when we
> were discussing it here) which tried to fix the filters. Then on F30 - but
> not on F31 or master - all the filtering stuff was removed on Oct 15 on the
> basis that it caused some kind of unspecified 'regressions'.
> 
> Mark, what is the current status here?

Sorry Adam, yeah so we have a 389-admin package that handles the frontend of the server, and it needs the perl modules "provided" by our 389-ds-base-legacy-tools subpackage.  Once we filtered out perl from 389-ds-base we could no longer install the 389-admin package:

 - package 389-admin-1.1.46-3.fc30.2.x86_64 requires perl(DSCreate), but none of the providers can be installed
 - package 389-admin-1.1.46-3.fc30.2.x86_64 requires perl(DSMigration), but none of the providers can be installed
 - package 389-admin-1.1.46-3.fc30.2.x86_64 requires perl(DSUpdate), but none of the providers can be installed
 - package 389-admin-1.1.46-3.fc30.2.x86_64 requires perl(DSUtil), but none of the providers can be installed
 - package 389-admin-1.1.46-3.fc30.2.x86_64 requires perl(Dialog), but none of the providers can be installed
 - package 389-admin-1.1.46-3.fc30.2.x86_64 requires perl(DialogManager), but none of the providers can be installed
 - package 389-admin-1.1.46-3.fc30.2.x86_64 requires perl(FileConn), but none of the providers can be installed
 - package 389-admin-1.1.46-3.fc30.2.x86_64 requires perl(Inf), but none of the providers can be installed
 - package 389-admin-1.1.46-3.fc30.2.x86_64 requires perl(Migration), but none of the providers can be installed
 - package 389-admin-1.1.46-3.fc30.2.x86_64 requires perl(Resource), but none of the providers can be installed
 - package 389-admin-1.1.46-3.fc30.2.x86_64 requires perl(Setup), but none of the providers can be installed
 - package 389-admin-1.1.46-3.fc30.2.x86_64 requires perl(SetupLog), but none of the providers can be installed
 - cannot install both 389-ds-base-legacy-tools-1.4.1.8-3.fc30.x86_64 and 389-ds-base-legacy-tools-1.4.1.6-1.fc30.x86_64
 - cannot install both 389-ds-base-legacy-tools-1.4.1.2-2.fc30.x86_64 and 389-ds-base-legacy-tools-1.4.1.8-3.fc30.x86_64
 - cannot install the best update candidate for package 389-ds-base-legacy-tools-1.4.1.6-1.fc30.x86_64
 - cannot install the best update candidate for package 389-admin-1.1.46-3.fc30.2.x86_64


Unfortunately, this kind of fell through the cracks as other fires popped up.  I'm not sure how to proceed in this case.  

FYI, in F32 389-admin has been removed so this then becomes a non-issue, but for now 389-admin needs them.

perhaps those would go away if you rebuilt it against the 389-ds-base with the provides stripped? I'm not 100% sure.

Fedora 29 changed to end-of-life (EOL) status on 2019-11-26. Fedora 29 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.