develooper Front page | | Postings from December 2012

Re: How To Build A Perl Package Database

Thread Previous | Thread Next
Leon Timmermans
December 17, 2012 01:31
Re: How To Build A Perl Package Database
Message ID:
On Mon, Dec 17, 2012 at 1:53 AM, Michael G Schwern <> wrote:
> I was thinking about what you said about packlists, and I wonder how much
> information one could scrape out of them.  Would it be enough to reconstruct
> at least that a group of files belongs to a release?  That would be enough to
> be able to fully uninstall a requested module.  For example, if the user asks
> to uninstall ExtUtils::MakeMaker the database could have seen that
> ExtUtils/ was in a packlist together with ExtUtils/ and
> so on and uninstall them.  Probably given their original purpose was to
> provide an uninstaller.

You can use them to uninstall (I assume that's the reason why Debian
disables them for vendor packages). It can get a little messy when
modules are split or some such, but that's relatively rare anyway.

> Also what's with this .meta directory I see popping up?  I missed a memo.

AFAIK that's cpanminus specific. AFAIK it stores meta information so
that carton can use it. Ask Miyagawa for the details.

> That's a good point about Storable.  JSON requires a dependency.
> ExtUtils::Install could bundle JSON::PP, but it would be simpler to use
> Data::Dumper.  It makes de/serialization faster and simpler.  The main
> disadvantage is its only readable by Perl, but that's ok since this pile of
> DBM files will be opaque to everything but the Perl API.  Too much of a mess
> to contemplate otherwise.

JSON::PP is already in modern perl releases, so it only requires a
dependency on older perls.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About