Packlist 2.0 MYMETA + installed file details
? On Dec 17, 2012 12:36 AM, "Tim Bunce" <tim.bu...@pobox.com> wrote: > 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. >
