in reply to Re: Problems with "PPM::PPD::init: not a PPD and not a file"
in thread Problems with "PPM::PPD::init: not a PPD and not a file"

Well, it does appear to be the problem with that particular package, and a few of the others. I am still digging around getting all the info together on which packages this is the problem--and which ones have valid PPD's but still error out (some still seem to).

On the plus side, I did figure out where it's getting the version information from: There were a couple XML and PPM files amongst all the PPDs.. The XML includes what looks like each of the full SOFTPKG entries for the entire repository (this is what normally goes in each PPD, right?), and the PPM files have summary information (I'm guessing to aid in searching).

I am starting to wonder if maybe this particular package problem is related to how and when the trouchelle repository (and possibly others) update their stores; The information seems disjoint between the XML and PPM files. For example, the ConfigReader-Simple package lists in one as version 1.24, and in another as 1.25. (The site seems to have the 1.23, 1.24 and 1.25 ZIP files, as well. Just no valid PPD file for them.)

Is there some perlmonk out there who can confirm this.. or better yet, suggest some solution? I am wary of fiddling with the internals of the PPM code--But it would certainly be nice if I could modify PPM to print the error, then continue processing the rest of the commands instead of dumping me back to the command-line with only half the packages processed. (Maybe it's even possible to "build" a valid PPD from the package.xml file? It looks like a complete SOFTPKG entry..)

One more last minute note, again as I'm writing this (I keep working in a command window as I write ;-)).. Some of the packages which previously processed OK are now showing this error, and some of the ones which previously had errors are now working OK. Just more reason I'm starting to think it's a problem with de-sync during the rep's update process..

  • Comment on Re^2: Problems with "PPM::PPD::init: not a PPD and not a file"

Replies are listed 'Best First'.
Re^3: Problems with "PPM::PPD::init: not a PPD and not a file"
by syphilis (Archbishop) on Aug 19, 2007 at 10:32 UTC
    I did figure out where it's getting the version information from

    Yes, http://trouchelle.com/ppm/package.xml seems to contain the info ... well spotted. But why did your search report version 1.24 of ConfigReader-Simple, and not version 1.25 ?

    Cheers,
    Rob
[reply]

      Yes, I noticed that too.. Which is why I think something got messed up during an update. But then I went back to look at the "Last Modified" time for the files, and since that was some time ago (many days or more), so that didn't make sense, either.

      But then I saw why.. The summary.ppm and searchsummary.ppm both list 1.24 as the current version. Things are starting to make sense.. But I still don't know if this is a problem with this particular repository or with the PPM system of tools--Or what can be done to handle it more gracefully. Nor does it explain why I get some of the same odd errors with other repositories and packages (which I have not yet been able to consistently reproduce, so might just be a httpd server issue--At this point, I'm even willing to believe it's got something to do with the alignment of the planets and phases of the moon, as long as it has a solution :-P)

      Maybe some perlmonk will wake up and explain it all.. Until then, I will continue my own expedition into it.. ;-)

      C. M.

[reply]
        Maybe some perlmonk will wake up and explain it all

        Yes, sooner or later randyk will come along. He has a pretty good understanding of ppm. I find (the recent versions of) PPM annoyingly opaque, and I consequently try to stand well clear. There's a somewhat more transparent version of PPM on CPAN but, of course, it doesn't provide the features that are available with PPM3 and PPM4. It won't work with zip files (and therefore the trouchelle rep) either, though I've submitted a patch to rt.cpan that I think addresses that issue.

        I notice that my ppm search ConfigReader-Simple produced  Downloading ActiveState Package Repository packlist but there was no corresponding action for the trouchelle rep. Therein, perhaps, lies the reason that you're still getting reports of 1.24 (instead of 1.25).

        Cheers,
        Rob
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom