On Mon, Dec 17, 2012 at 1:53 AM, Michael G Schwern <schw...@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
