Re^4: Cannot find dependencies when creating packages on ActivePerl with PPM 4

Terrific... if you have a Internet connection available. ;-)

I'm starting asking myself why ActiveState have such feature (?) when generating a PPD file from a makefile. It would be more interesting if the documented process worked instead forcing a programmer to look for a solution that solves the problem correctly.

Thanks anyway, I look forward to try and use PPM::Make.

Alceu Rodrigues de Freitas Junior
---------------------------------
"You have enemies? Good. That means you've stood up for something, sometime in your life." - Sir Winston Churchill

Comment on Re^4: Cannot find dependencies when creating packages on ActivePerl with PPM 4

Replies are listed 'Best First'.
Re^5: Cannot find dependencies when creating packages on ActivePerl with PPM 4 by randyk (Parson) on Jan 22, 2007 at 21:41 UTC
The generated ppd file is coming from Perl tools (ExtUtils::MakeMaker or Module::Build); these make a guess about the package the prerequisites are found in (based on the specified module name), but sometimes the guess is wrong (eg, Win32::OLE is in the libwin32 package, not a Win32-OLE package). Deciding with certainty what package is required requires, ultimately, an internet connection, in order to have access to the CPAN indices where this information resides. ActiveState, with ppm4, is moving away from specifying package names as prerequisites, and moving to a REQUIRE field, which can specify elements listed in the PROVIDE field (which can be module names). When this gets fully implemented, this problem of needing to map module names to package names will disappear. See this message for details.	[reply]
Re^6: Cannot find dependencies when creating packages on ActivePerl with PPM 4 by glasswalk3r (Friar) on Jan 23, 2007 at 13:06 UTC
The generated ppd file is coming from Perl tools (ExtUtils::MakeMaker or Module::Build); these make a guess about the package the prerequisites are found in (based on the specified module name), but sometimes the guess is wrong (eg, Win32::OLE is in the libwin32 package, not a Win32-OLE package). This explains a lot. Looks like the same issue that happens with RPM packages on Linux: packagers choose a package name that best fits the requirements. This would be easier to solve if the PPM is capable to search the available Perl modules inside a PPD package. I would be able, at least, to maintain the dependency list in my PPD file, even if I have to do it manually. I tested all options against Hash-Util, without any results. Alceu Rodrigues de Freitas Junior --------------------------------- "You have enemies? Good. That means you've stood up for something, sometime in your life." - Sir Winston Churchill	[reply]
Re^5: Cannot find dependencies when creating packages on ActivePerl with PPM 4 by syphilis (Archbishop) on Jan 23, 2007 at 00:56 UTC
Thanks anyway, I look forward to try and use PPM::Make. My take on this is that PPM::Make will enable you to create a ppd file that works - but that ppd file will not contain the `<DEPENDENCY>` checks for the modules you specified ... and therefore you won't achieve your aim, anyway. PPM just currently doesn't have the capability to perform dependency checks on core and bundled modules - though that may change in the future. I could be wrong, however - in which case someone will hopefully correct me. Cheers, Rob	[reply] [d/l]
Re^6: Cannot find dependencies when creating packages on ActivePerl with PPM 4 by randyk (Parson) on Jan 23, 2007 at 03:57 UTC
I'm not sure in what sense you mean "dependency checks"?	[reply]
Re^7: Cannot find dependencies when creating packages on ActivePerl with PPM 4 by syphilis (Archbishop) on Jan 23, 2007 at 14:09 UTC
I'm not sure in what sense you mean "dependency checks"? As I understand it, a key aspect of what the op wanted, was for PPM to check that the installed versions of some specific modules (Carp, Win32::OLE, etc.) are >= a certain version number. Looks to me that PPM is incapable of doing that - though I haven't tested it out for myself. Cheers, Rob	[reply]