On 1/4/13 4:41 AM, David Cantrell wrote: > On Sun, Dec 16, 2012 at 08:57:48PM +0100, Leon Timmermans wrote: >> On Sat, Dec 15, 2012 at 11:59 PM, Michael G Schwern <schw...@pobox.com> >> wrote: >>> Storage is a problem. The only reliable "database" Perl ships with is DBM, >>> an >>> on disk hash, so we can't get too fancy. It might take several DBM files, >>> but >>> this is enough to record information and do simple queries. > > I'd just go for JSON or YAML, which are already supported by large parts > of the toolchain.
For performance reasons, I wish to avoid having to slurp in a gigantic JSON file before doing anything. OTOH one could go the .git route and use the filesystem itself as a key/value store. /$database/$table/$key.json. That would both avoid DBM bugs and allow the database to be human readable. Great idea! >>> And the basic operations we need to support. >>> >>> * Add a release (ie. install). >>> * Delete a release (and its files). > > and stuff that depends on it? That brings up two issues. The first is a reverse dependency database so you can both A) delete a release and all that depends on it but also B) prevent a user from deleting a release which still has dependencies. Thanks to MYMETA, the reverse dep database is easy to build. I don't recall if I had that in my list, good catch. There's a second feature which I really like, and that's when a package manager can tell the difference between what was explicitly asked for and what was installed automatically to resolve an issue. MacPorts has this feature and its handy to clean up a bloated installation. Unfortunately this will be difficult for ExtUtils::Install to know, but its worth keeping in mind. >>> * Delete an older version of a release, only if its in the same release >>> location. This is so CPAN installs don't delete vendor installed modules. >>> * Verify the files of a release. >>> * List distributions/releases installed. > > * Downgrade a release to a previously installed one? > * Rollback all modules to a point in time? That requires keeping a record of previously installed items, which would be useful for many things, but potentially a PITA to get right because its not simply a matter of storing a few JSON files but also their linkages. You could just keep a copy of everything after every operation, possibly using symlinks to slim down on disk space, but at a certain point you're creating a version control system. Pinto has been having similar problems. OTOH if its all file based you could use a version control system if available. Either way, worth recording the data for the future to work out what to do with it.
