Re: How To Build A Perl Package Database

On Mon, Dec 17, 2012 at 1:53 AM, Michael G Schwern <[email protected]> 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