Bug 679014

Summary: rpmbuild: Perl excessive auto-Requires
Product: [Fedora] Fedora Reporter: Jan Kratochvil <jan.kratochvil>
Component: rpmAssignee: Panu Matilainen <pmatilai>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 15CC: atu, ffesti, jan.kratochvil, jnovy, pmatilai, ville.skytta
Target Milestone: ---Keywords: Regression
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-08-07 18:04:57 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 694496    

Description Jan Kratochvil 2011-02-21 09:55:44 UTC
Description of problem:
cvs2cl is no longer installable in F15 due to unsatisfied Requires.

Version-Release number of selected component (if applicable):
rpm-build-4.9.0-0.beta1.7.fc15.x86_64
(used to build cvs2cl-2.72-4.noarch)

How reproducible:
Always.

Steps to Reproduce:
rebuild cvs2cl

Actual results:
rpm -q --requires cvs2cl
perl(CVS::Utils::ChangeLog::EntrySet::Output)
rpm -q --provides cvs2cl
<none>

Expected results:
rpm -q --requires cvs2cl
<none>
rpm -q --provides cvs2cl
<none>

Additional info:
/usr/bin/cvs2cl:
package CVS::Utils::ChangeLog::EntrySet::Output::Text;
use base qw( CVS::Utils::ChangeLog::EntrySet::Output );
package CVS::Utils::ChangeLog::EntrySet::Output;

It does not provide CVS::Utils::ChangeLog::EntrySet::Output for external linkage - --provides is correct.
But it has no external dependency on CVS::Utils::ChangeLog::EntrySet::Output.

Comment 1 Panu Matilainen 2011-02-21 11:34:34 UTC
Ville, any thoughts what to do about this?

Comment 2 Jan Kratochvil 2011-02-21 13:16:48 UTC
CPAN packaged Perl modules already contain the information:
Mail-Audit-2.225/META.yml:
module_name: Mail::Audit
[...]
requires:
  Fcntl: 0
  File::HomeDir: 0.61
  File::Temp: 0
  File::Tempdir: 0
  MIME::Entity: 0
  Mail::Internet: 0
  Mail::Mailer: 0
  Net::SMTP: 0
  perl: 5.6.0

etc., when the Perl packaging itself does not autodetect it why Fedora tries to?
There are autodetection tools to generate these meta-info files but these meta-info files are already done and provided by CPAN.

Comment 3 Panu Matilainen 2011-02-21 15:11:17 UTC
(In reply to comment #2)
> when the Perl packaging itself does not autodetect it why Fedora tries to?
> There are autodetection tools to generate these meta-info files but these
> meta-info files are already done and provided by CPAN.

Heh, now there's a fair question. I dont have a definitive answer, but for all I know it might as well be "it seemed like a good idea at the time" (this'd be around 1999).

More seriously, all rpm automatic dependency extraction happens from files in the buildroot, and the META.yml files don't seem to be generally installed at all (whether this is Fedora policy or perl policy I dont know). Anyway, rpm doesn't have a good mechanism from including dependencies from such metadata files. Silly as it is.

I might as well go and invent a mechanism to do just that...

Comment 4 Jan Kratochvil 2011-02-21 15:23:04 UTC
jnovy has recently developed even some scripts for generating .spec files from TeXLive upstream CTAN metadata.  Maybe Perl maintainers could choose such way for autogenerated.spec files provisioning even for CPAN.

Comment 5 Ville Skyttä 2011-02-21 20:20:07 UTC
(In reply to comment #1)
> Ville, any thoughts what to do about this?

I think it's something that should be just filtered out in the specfile.  Not adding the Provides is ok because this is a script and not a module, but then again extracting dependencies from use base qw(...) is also useful.

I suppose rpmbuild _could_ run the provides script for all perl files (including non-library ones) and filter out per-file self-dependencies in them based on that info (and _not_ add the Provides to the package except if the file is a perl module).  Not pretty, but would work around cases like this.

There are already various perl helpers such as cpanspec that generate dependencies.  I believe META.yml is usually not as autogenerated as comment 2 suggests - I think in the majority of cases it's just generated by ExtUtils::MakeMaker from the contents of Makefile.PL which is filled in by humans and will in a lot of cases omit some module dependencies that those humans assume being present because perl is installed, but Fedora's perl is split so that those assumptions may not hold...

Comment 6 Marcela Mašláňová 2011-03-24 14:34:28 UTC
(In reply to comment #4)
> jnovy has recently developed even some scripts for generating .spec files from
> TeXLive upstream CTAN metadata.  Maybe Perl maintainers could choose such way
> for autogenerated.spec files provisioning even for CPAN.

I'm aware of it, but it's not helpful for Perl packaging. We have our own tools, which tell us what should be in specfile as requires, but rpm is automatically finding more things. 

I will look at finding provides/requires in rpm for Perl and try to fix it.

Comment 7 Marcela Mašláňová 2011-03-24 14:39:46 UTC
(In reply to comment #5)
> There are already various perl helpers such as cpanspec that generate
> dependencies.  I believe META.yml is usually not as autogenerated as comment 2
> suggests - I think in the majority of cases it's just generated by
> ExtUtils::MakeMaker from the contents of Makefile.PL which is filled in by
> humans and will in a lot of cases omit some module dependencies that those
> humans assume being present because perl is installed, but Fedora's perl is
> split so that those assumptions may not hold...

You are right, META.yml is generated from Makefile.PL or Build.PL, but upstream usually don't bother to be precise about requirements also dependencies could change between releases.

Comment 8 Fedora End Of Life 2012-08-07 18:05:00 UTC
This message is a notice that Fedora 15 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 15. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '15' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)

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

Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 15 reached 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 to click on
"Clone This Bug" (top right of this page) and open it against that
version of Fedora.

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.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 9 Jan Kratochvil 2012-08-08 15:11:03 UTC
Not sure when it got fixed but the Comment 0 reproduced is fixed now.