Bug 1129443
Summary: | repeatly deps to perl-devel | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Harald Reindl <h.reindl> |
Component: | perl-ExtUtils-MakeMaker | Assignee: | Petr Pisar <ppisar> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 23 | CC: | awilliam, cweyl, iarnell, jplesnik, kasal, mmaslano, perl-devel, ppisar, psabata, rc040203, tcallawa |
Target Milestone: | --- | Keywords: | Reopened |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | perl-Encode-2.84-9.fc25 perl-ExtUtils-ParseXS-3.30-3.fc25 perl-ExtUtils-MakeMaker-7.10-4.fc25 perl-IPC-Cmd-0.94-3.fc25 perl-ExtUtils-MakeMaker-7.10-4.fc24 perl-ExtUtils-MakeMaker-7.04-348.fc23 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2016-05-18 02:52:50 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Harald Reindl
2014-08-12 19:05:30 UTC
What I can gather from this mess, is that there is a dependency between perl-IPC-Cmd and perl-ExtUtils-MakeMaker which is (correctly!) pulling in perl-devel. From IPC/Cmd.pm: ... require ExtUtils::MakeMaker; my @possibles; if( File::Spec->file_name_is_absolute($command) ) { return MM->maybe_command($command); } else { for my $dir ( File::Spec->path, File::Spec->curdir ) { next if ! $dir || ! -d $dir; my $abs = File::Spec->catfile( IS_WIN32 ? Win32::GetShortPathName( $dir ) : $dir, $command); push @possibles, $abs if $abs = MM->maybe_command($abs); } } ... maybe_command originates from MakeMaker. One resolution to this problem would be to eliminate this use case of "maybe_command" in perl(IPC::Cmd). I'm sorry the dependencies defined by upstream code pollute your system but that's how it is. As Ralf pointed out correctly the issue is that perl-ExtUtils-MakeMaker gets installed into your system. perl-ExtUtils-MakeMaker is a development tool, hence it pulls in perl-devel, yet it's a Perl core module which many other packages use because it provides nifty functions. If we cut the dependency between perl-ExtUtils-MakeMaker and perl-devel, users would lose capability to build XS Perl modules which is one common drawback presenting in other distributions and one people, usually web application deployers, often complain. Therefore the best solution is to split perl-ExtUtils-MakeMaker to separate the nifty functions, however it requires upstream blessing and that's a thing I cannot see bright. yes, but that is new in F20 perl-SOAP-WSDL-2.00.99_3-3.fc20.20140812.rh.noarch is just a unchanged rebuild of the F19 src.rpm and on F19 there where no devel-dependencies the same problem for spamassasin on F20 https://bugzilla.redhat.com/show_bug.cgi?id=1056723#c2 the same mess in the past with mod_perl https://bugzilla.redhat.com/show_bug.cgi?id=748362 https://bugzilla.redhat.com/show_bug.cgi?id=803290 The MM::maybe_command() exists in various implementations specific for each operating system these implementations requires ExtUtils::MakeMaker back. So it's unlikely that IPC::Cmd upstream would like bundle the MM::maybe_command(). Also it's unlikely that ExtUtils-MakeMaker upstream will move maybe_command() into separate module because of the back-requirements to ExtUtils::MakeMaker. I could patch perl-ExtUtils-MakeMaker to move MM_Unix::maybe_command() into a new module, sub-package it and patch perl-IPC-Cmd to use that module. However this will be a hack specific for Fedora and I'm not sure if this is worth to do that considering there can be other perl-ExtUtils-MakerMaker users like this perl-IPC-Cmd. however, pull perl-devel, glibc-devel, glibc-header and kernel-headers just for http://search.cpan.org/~pmevzek/Net-DRI-0.96/lib/Net/DRI.pm to register domains is somehow pervert spamassissin uses ExtUtils::MakeMaker from sa-compile.raw like this: my $ccopt = $Config{optimize}; # typically "-O2" open(FILE, ">Makefile.PL") or die "cannot create Makefile.PL: $!"; print FILE <<"EOT" or die "error writing to Makefile.PL: $!"; use ExtUtils::MakeMaker; WriteMakefile( 'NAME' => '$modname', 'VERSION_FROM' => '$PMFILE', 'ABSTRACT_FROM' => '$PMFILE', 'OBJECT' => '\$(O_FILES)', 'OPTIMIZE' => '$ccopt', 'AUTHOR' => 'A. U. Tomated <automated\@example.com>', ); EOT See the OPTIMIZE (and following not quoted XS code)---it fiddles with CFLAGS. Therefore spassassin is the case why perl-ExtUtils-MakeMaker needs perl-devel. This is classic counterexample for your complain "We don't need perl-devel". (In reply to Harald Reindl from comment #5) > however, pull perl-devel, glibc-devel, glibc-header and kernel-headers just > for http://search.cpan.org/~pmevzek/Net-DRI-0.96/lib/Net/DRI.pm to register > domains is somehow pervert Harald, this is how binary distribution works. They provide full-fledged packages. If you can come with a rule how to recognize which packages needs perl-devel and which not, if you persuade upstreams to do comply to it, I will be happy to improve Fedora. Otherwise your request cripple distribution for the other half of Fedora users. i would accept the "perl-devel" but in F19 "perl-devel" did not pull "glibc-headers", "glibc-devel" and "kernel-headers" F19: * perl-devel * perl-ExtUtils-CBuilder * perl-ExtUtils-Install * perl-ExtUtils-MakeMaker * perl-ExtUtils-ParseXS * perl-IPC-Cmd * perl-Module-Build * perl-Net-DRI * perl-SOAP-WSDL no kernel/glibc development stuff pulled (In reply to Harald Reindl from comment #8) > i would accept the "perl-devel" but in F19 "perl-devel" did not pull > "glibc-headers", "glibc-devel" and "kernel-headers" > > F19: > * perl-devel > * perl-ExtUtils-CBuilder > * perl-ExtUtils-Install > * perl-ExtUtils-MakeMaker > * perl-ExtUtils-ParseXS > * perl-IPC-Cmd > * perl-Module-Build > * perl-Net-DRI > * perl-SOAP-WSDL > > no kernel/glibc development stuff pulled And that was wrong because perl-devel delivers header files which include header files from glibc-devel, thus perl-devel requires glibc-devel. I cannot see anything wrong with it. These binary packages requires something from perl-ExtUtils-MakeMaker: bucardo-0:4.5.0-7.fc21.noarch clusterssh-0:4.02.03-2.fc21.noarch dnssec-tools-perlmods-0:2.0-10.fc21.x86_64 hyperestraier-perl-0:1.4.13-18.fc21.x86_64 mod_perl-0:2.0.8-8.20140624svn1602105.fc21.i686 mod_perl-0:2.0.8-8.20140624svn1602105.fc21.x86_64 mod_perl-devel-0:2.0.8-8.20140624svn1602105.fc21.i686 mod_perl-devel-0:2.0.8-8.20140624svn1602105.fc21.x86_64 perl-Alien-ROOT-0:5.34.3.1-5.fc21.noarch perl-App-cpanminus-0:1.7004-2.fc21.noarch perl-core-0:5.18.2-303.fc22.x86_64 perl-CPAN-0:2.00-303.fc22.noarch perl-Dancer-0:1.3126-1.fc22.noarch perl-DepGen-Perl-Tests-0:0.1.1-2.fc21.noarch perl-devel-4:5.18.2-303.fc22.i686 perl-devel-4:5.18.2-303.fc22.x86_64 perl-Dist-Zilla-0:5.015-2.fc21.noarch perl-ExtUtils-AutoInstall-0:0.63-24.fc21.noarch perl-ExtUtils-Install-0:1.59-303.fc22.noarch perl-ExtUtils-MakeMaker-CPANfile-0:0.06-1.fc22.noarch perl-Glib-devel-0:1.305-1.fc21.i686 perl-Glib-devel-0:1.305-1.fc21.x86_64 perl-Inline-0:0.67-1.fc22.noarch perl-Inline-C-0:0.60-1.fc22.noarch perl-IPC-Cmd-1:0.92-2.fc21.noarch perl-Module-Build-2:0.42.06-1.fc22.noarch perl-Module-Depends-0:0.15-7.fc21.noarch perl-Module-Install-0:1.06-7.fc21.noarch perl-Module-ScanDeps-0:1.14-1.fc22.noarch perl-Module-Util-0:1.09-4.fc21.noarch perl-Padre-0:0.90-12.fc21.noarch perl-PAR-Dist-0:0.49-5.fc21.noarch perl-PAR-Packer-Tk-0:1.019-1.fc22.noarch perl-PDL-0:2.7.0-4.fc21.x86_64 perl-SVK-0:2.2.3-12.fc21.noarch perl-Test-Fixme-0:0.04-9.fc21.noarch perl-Test-HasVersion-0:0.012-10.fc21.noarch perl-Test-Prereq-0:1.037-14.fc21.noarch perl-Tk-devel-0:804.032-1.fc22.i686 perl-Tk-devel-0:804.032-1.fc22.x86_64 perl-Wx-0:0.9922-2.fc21.x86_64 perlbrew-0:0.66-2.fc21.noarch qdbm-perl-0:1.8.78-14.fc21.x86_64 redhat-lsb-languages-0:4.1-27.fc21.i686 redhat-lsb-languages-0:4.1-27.fc21.x86_64 spamassassin-0:3.4.0-7.fc21.x86_64 vim-perl-support-0:5.2-2.fc21.noarch I will review dependency on perl-devel for each package which posses it now. E.g. perl-ExtUtils-Install does not need it. thank you! honestly i created a meta-package on the machine running EPP services which is the only one pulling that dependencies and all continues to work fine (yet registered a new customer domain) Provides: glibc-devel Provides: kernel-headers Provides: glibc-headers Provides: glibc-devel Provides: systemtap-sdt-devel Provides: perl-devel Provides: gdbm-devel Provides: libdb-devel Obsoletes: glibc-devel Obsoletes: kernel-headers Obsoletes: glibc-headers Obsoletes: glibc-devel Obsoletes: systemtap-sdt-devel Obsoletes: perl-devel Obsoletes: gdbm-devel Obsoletes: libdb-devel I did a review before upgrading to 5.18. So I will have to rereview it again. These were my findings so far: Encode-devel Useful but no strictly needed. It generates XS files which need Perl headers to be usefull. ExtUtils-CBuilder Needed by ExtUtils::CBuilder (Compile and link C code for Perl modules). ExtUtils-Embed Generates perl bindings and returns compiler options for linking to perl. It's like a pkg-config file, it should need it. ExtUtils-Install Does not need perl-devel. It only installs files and handle packlists. ExtUtils-MakeMaker TODO: Entry point for Makefile.PL to build not only XS modules. Consider splitting. ExtUtils-Manifest Not needed. ExtUtils-ParseXS Not needed. Self-contained converter from XS to C. Module-Build TODO: The same case as ExtUtils-MakeMaker. core Header files are part of Perl core. Needed. sounds promising - thank you! This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. 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 '20'. 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 20 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. This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle. Changing version to '23'. (As we did not run this process for some time, it could affect also pre-Fedora 23 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23 *** Bug 1327808 has been marked as a duplicate of this bug. *** perl-Encode-devel fixed in perl-Encode-2.84-9.fc25. perl-ExtUtils-ParseXS fixed in perl-ExtUtils-ParseXS-3.30-3.fc25 I copied the MM_Unix::maybe_command() function to an independent sub-package in perl-ExtUtils-MakeMaker-7.10-4.fc25. perl-IPC-Cmd fixed in perl-IPC-Cmd-0.94-3.fc25. Thanks a lot for taking care of this! My affected cases are running F23 (the Fedora openQA boxes) so if the change could make it back there that'd be great, otherwise never mind, we can just live with the extra deps till the machines get upgraded :) I will give the changes some time for testing, and then I will try to port them to older Fedoras. perl-ExtUtils-MakeMaker-7.10-4.fc24 perl-IPC-Cmd-0.94-3.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-ff63e4a24e perl-ExtUtils-MakeMaker-7.10-4.fc24, perl-IPC-Cmd-0.94-3.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-ff63e4a24e perl-ExtUtils-MakeMaker-7.10-4.fc24, perl-IPC-Cmd-0.94-3.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report. perl-ExtUtils-MakeMaker-7.04-348.fc23 perl-IPC-Cmd-0.94-3.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-d075ee19e8 perl-ExtUtils-MakeMaker-7.04-348.fc23, perl-IPC-Cmd-0.94-3.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-d075ee19e8 perl-ExtUtils-MakeMaker-7.04-348.fc23, perl-IPC-Cmd-0.94-3.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report. |