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 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

Either way, worth recording the data for the future to work out what to
do with it.

Search Discussions

Discussion Posts


Follow ups

Related Discussions



site design / logo © 2018 Grokbase