I know this isn't a SCL-specific question, but something I'm sure all of us have dealt with in one form or another building Perl packages. I'm not sure the best way to deal with this current problem I'm dealing with.
I'm building packages for a perl516 collection and I've run into an issue where Moose says it requires Devel::PartialDump >= 0.14 and Devel::PartialDump v0.15 says it requires Moose.
Many times I'll see that the stock dependency generator creates package dependencies from modules named in scripts and example files. Sometimes those named modules are bogus or made-up. Sometimes, a developer will leave in a she-bang that references something like /usr/local/perl/bin/perl resulting in a bad dependency. Adding a sed or perl line to "fix" the offending line usually fixes this.
In this particular case, I've looked at the module tarball and the dependencies *look* valid. Moose has Devel::PartialDump in its META.yml file and Devel::PartialDump has Moose in its META.yml file.
I'm not familiar with it, but someone told me there was a "noreqs" or "noreq" directive you could put in a spec file that disabled the auto-resolution of required dependencies. Is that even wise?!
Thanks in advance for your help.
On 06/14/2013 06:41 PM, Doran Barton wrote:
I know this isn't a SCL-specific question, but something I'm sure all of us have dealt with in one form or another building Perl packages. I'm not sure the best way to deal with this current problem I'm dealing with.
I'm building packages for a perl516 collection and I've run into an issue where Moose says it requires Devel::PartialDump >= 0.14 and Devel::PartialDump v0.15 says it requires Moose.
Many times I'll see that the stock dependency generator creates package dependencies from modules named in scripts and example files. Sometimes those named modules are bogus or made-up. Sometimes, a developer will leave in a she-bang that references something like /usr/local/perl/bin/perl resulting in a bad dependency. Adding a sed or perl line to "fix" the offending line usually fixes this.
In this particular case, I've looked at the module tarball and the dependencies *look* valid. Moose has Devel::PartialDump in its META.yml file and Devel::PartialDump has Moose in its META.yml file.
I'm not familiar with it, but someone told me there was a "noreqs" or "noreq" directive you could put in a spec file that disabled the auto-resolution of required dependencies. Is that even wise?!
Hi,
the best way is used a macro %perl_bootstrap for resolving circular dependencies in Perl modules. The macro is described in /etc/rpm/macros.perl-srpm.
If the macro is not defined globally for Perl, you should define it directly in a spec file.
The macro is used in Fedora spec file for perl-Devel-PartialDump. If you create a SCL spec from that file, you'll only need to add "%global perl_bootstrap 1" at the beginning of spec file. After that, you are able to build the rpms. Then, you remove the local definition of the macro and rebuild the perl-Devel-PartialDump.
Regards, Jitka
softwarecollections@lists.fedorahosted.org