develooper Front page | perl.module.build | Postings from December 2012

Re: How To Build A Perl Package Database

Thread Previous | Thread Next
From:
Leon Timmermans
Date:
December 17, 2012 01:31
Subject:
Re: How To Build A Perl Package Database
Message ID:
CAHhgV8in53ZzbXO5Mb2kdQR+NQYjWZSN_-_Fy4zB7herp4TSUw@mail.gmail.com
On Mon, Dec 17, 2012 at 1:53 AM, Michael G Schwern <schwern@pobox.com> 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/MakeMaker.pm was in a packlist together with ExtUtils/MM_Unix.pm 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.

Leon

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About