|Summary:||rpmbuild: Perl excessive auto-Requires|
|Product:||[Fedora] Fedora||Reporter:||Jan Kratochvil <jan.kratochvil>|
|Component:||rpm||Assignee:||Panu Matilainen <pmatilai>|
|Status:||CLOSED RAWHIDE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||15||CC:||atu, ffesti, jan.kratochvil, jnovy, pmatilai, ville.skytta|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2012-08-07 18:04:57 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:|
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