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