You aren't going to be able to store a installation file (makefile, build.pl, whatever) for every situation. That's a really hard problem that nobody has figured out, and once you do, some OS or library will change slightly, need special treatment, and muck it all up.

I'd much rather have something like ExtUtils::MakeMaker or Module::Build that knows how to do the right thing on my system. Anything you do will still have to look at my own Config.pm because I install my own Perl, and I don't have to tell anyone but my system where and how I did that, which configuration options I choose, and where I want modules to end up. Something still has to take all of that information and put it into the installation program.

Not only that, but I want to turn things on or off when I install things. I often use PREFIX, and less often I choose to give Makefile.PL values for other options. Your solution will have to handle all of those as well.

There is a problem with having only one version of a module installed because the module name maps directly onto the filesystem. A database won't fix that, though. We have to store the files different, but still make them available as plain files so we can look at them, grep them, and whatever other things we typically do with plain files.

Once you think about everything that has to happen, you're pretty much back to something like MakeMaker. You might not like it, and you may think its ugly, but you need to give credit where credit is due. People (not just Perlers) have been using make(1) for decades, so you want to be a bit cautious before you throw all of that experience away.

Besides that, I don't see much use for a database to query module names. People might use that with CPAN Search or Kobes Search, but the average user just wants to install the module he wants. I don't see finding modules as a big problem. Anything that you do will have to be completely replicated in a CPAN mirror so people can still use it offline (my most frequent place to install modules is in an airplane, for instance). I don't want to keep around hundreds of installation hints files for that, but I don't want to lose the ability to install something at a client site either.

A database won't provide for versioning, transactions, or backups either. It can do that for the data it contains, but it only stores information about the model we give it. To solve those problems, we need to affect the way Perl installs and stores modules and how it decides which one to use. That problem lives outside a dataase, and its a problem of process, not implmentation.

Perl 6 is already thinking about this sort of stuff, and it was a concern early on. I'm not sure which solution they are going to come up with (they have time :), but I hope they don't start with a technological idea first then shoehorn everything into that idea. I really hope they don't use some gatekeeper/bottleneck that controls access to the information.