On Sun, Dec 16, 2012 at 04:53:49PM -0800, Michael G Schwern wrote: > On 2012.12.16 11:57 AM, Leon Timmermans wrote: > > >> * Where to put the database? What about non-standard install locations?
> >> Another is to have a separate install database for non-standard install > >> locations. A separate install database for each install location seems like the only workable approach. > >> This makes sense to me, but it brings in the sticky problem > >> of having to merge install databases. Sticky, but still a SMOP. Once you > >> have to implement merging anyway, it now makes sense to have an install > >> database for each install location. One for core. One for vendor. One > >> for > >> perl. And one for each custom location. This has a lot of advantages to > >> better fit how Perl layers module installs. > >> > >> * allows separation of permissions > >> * allows queries of what's installed based on what's in @INC Perhaps that could be taken one step further: one per installed distribution. Then, what's kept at each install location is a cached summary of what's installed below it. One that can be cross-checked against the individual distribution 'databases' and rebuilt from it. That seems more robust against various kinds of 'damage'. > >> That second one is important. When a normal user queries the database, > >> they > >> want to get what's installed in the standard library location. When a > >> local::lib user queries the database, they want to get what's installed in > >> the > >> standard library locations AND their own local lib. I.e., the default view is "what's installed in my @INC". > > The combination of these is problematic. You might upgrade EU::Install > > in your local module path, but not have write permissions on the > > system paths. In practice, we might have to support all our older > > versions :-| > > Erg, good point. That very likely scenario is definitely going to require > some thought. *nods* Here's where "one install database per distribution with a cache database at the install location" offers another benefit. The "per distribution install database" can be kept in a very simple plain text format that targets readability and future-proofing, while the "cache database at the install location" can target performance. If an install location has an incompatible version of the db, the per distribution dbs could be read instead. That's slow but workable and seems reasonable for that presumably uncommon case. I can think of a few further options as well. Tim.
