Take perl-Test-Fake-HTTPD-0.09-5.fc37 sources package, build it, and inspect which files are packaged: $ rpm -ql noarch/perl-Test-Fake-HTTPD-0.09-5.fc37.noarch.rpm |sort /usr/share/doc/perl-Test-Fake-HTTPD /usr/share/doc/perl-Test-Fake-HTTPD/Changes /usr/share/doc/perl-Test-Fake-HTTPD/README.md /usr/share/licenses/perl-Test-Fake-HTTPD /usr/share/licenses/perl-Test-Fake-HTTPD/LICENSE /usr/share/man/man3/Test::Fake::HTTPD.3pm.gz /usr/share/perl5/vendor_perl /usr/share/perl5/vendor_perl/Test /usr/share/perl5/vendor_perl/Test/Fake /usr/share/perl5/vendor_perl/Test/Fake/HTTPD.pm Especially pay attention to /usr/share/perl5/vendor_perl directory which, in my opinion, shouldn't be there because the %files section looks like this: %files %license LICENSE %doc Changes README.md %{perl_privlib}/* %{_mandir}/man3/* %{perl_privlib} expands to "/usr/share/perl5/vendor_perl". One could argue that the glob could expand to an empty string, hence to /usr/share/perl5/vendor_perl/ which should be equivalent to /usr/share/perl5/vendor_perl. But then why %{_mandir}/man3/* expands only to /usr/share/man/man3/Test::Fake::HTTPD.3pm.gz and "/usr/share/man/man3" is missing? Something is inconsistent here. I would prefer not including the /usr/share/perl5/vendor_perl directory. Observed with rpm-build-4.18.0-0.alpha1.6.fc37.x86_64.
Compare to perl-HTTP-Message-6.36-2.fc37 has a very similar %files section: %files %license LICENSE %doc Changes CONTRIBUTING.md README.md %{perl_vendorlib}/* %{_mandir}/man3/* but the /usr/share/perl5/vendor_perl directory is not packaged: $ rpm -qlp noarch/perl-HTTP-Message-6.36-2.fc37.noarch.rpm | sort /usr/share/doc/perl-HTTP-Message /usr/share/doc/perl-HTTP-Message/Changes /usr/share/doc/perl-HTTP-Message/CONTRIBUTING.md /usr/share/doc/perl-HTTP-Message/README.md /usr/share/licenses/perl-HTTP-Message /usr/share/licenses/perl-HTTP-Message/LICENSE /usr/share/man/man3/HTTP::Config.3pm.gz /usr/share/man/man3/HTTP::Headers.3pm.gz /usr/share/man/man3/HTTP::Headers::Auth.3pm.gz /usr/share/man/man3/HTTP::Headers::ETag.3pm.gz /usr/share/man/man3/HTTP::Headers::Util.3pm.gz /usr/share/man/man3/HTTP::Message.3pm.gz /usr/share/man/man3/HTTP::Request.3pm.gz /usr/share/man/man3/HTTP::Request::Common.3pm.gz /usr/share/man/man3/HTTP::Response.3pm.gz /usr/share/man/man3/HTTP::Status.3pm.gz /usr/share/perl5/vendor_perl/HTTP /usr/share/perl5/vendor_perl/HTTP/Config.pm /usr/share/perl5/vendor_perl/HTTP/Headers /usr/share/perl5/vendor_perl/HTTP/Headers/Auth.pm /usr/share/perl5/vendor_perl/HTTP/Headers/ETag.pm /usr/share/perl5/vendor_perl/HTTP/Headers.pm /usr/share/perl5/vendor_perl/HTTP/Headers/Util.pm /usr/share/perl5/vendor_perl/HTTP/Message.pm /usr/share/perl5/vendor_perl/HTTP/Request /usr/share/perl5/vendor_perl/HTTP/Request/Common.pm /usr/share/perl5/vendor_perl/HTTP/Request.pm /usr/share/perl5/vendor_perl/HTTP/Response.pm /usr/share/perl5/vendor_perl/HTTP/Status.pm I found that many Perl packages now package that directory and they should not. At least that is not in intention of current Perl packaging guidelines <https://docs.fedoraproject.org/en-US/packaging-guidelines/Perl/#_directory_ownership>. This is how I discovered this issue.
Indeed /path/* should not package /path itself, so something's amiss here. Good spotting, thanks for the report.
Yeah, %files globbing is janky at the moment, we have a PR pending that should help with that, although it remains to be seen if this is related. Assigning to self as I'm currently looking into that piece of code anyway.
> %{perl_privlib} expands to "/usr/share/perl5/vendor_perl". Except that it doesn't, at least here on F35: [pmatilai🎩︎localhost]$ rpm --eval "%{perl_privlib}" /usr/share/perl5 [pmatilai🎩︎localhost]$ rpm --eval "%{perl_vendorlib}" /usr/share/perl5/vendor_perl And that's why %{perl_privlib}/* ends up packaging /usr/share/perl5/vendor_perl. I don't know the alleged difference between %{perl_privlib} and %{perl_vendorlib} but this is not an rpm bug, this is a packaging issue. Reassigning to perl-Test-Fake-HTTPD but if more packages are using %{perl_privlib} when they should be using %{perl_vendorlib} then then maybe there's a more generic issue, maybe one with packaging guidelines?
Oh my god. I should less trust my eyes. Thanks.