Re: How To Build A Perl Package Database
[email protected] (Adam Kennedy) Mon, 17 Dec 2012 09:42:41 -0800
| Newsgroups | perl.cpan.workers,perl.module.build,perl.makemaker |
|---|---|
| Message-ID | <CAAVyNAxyEJU+-kJGh+UCSBgSHzw9p2uY-iWfO+RsJvdKOnYqog@mail.gmail.com> |
--047d7b6042fa74c26004d10fe8e9 Content-Type: text/plain; charset=ISO-8859-1 Packlist 2.0 MYMETA + installed file details ? On Dec 17, 2012 12:36 AM, "Tim Bunce" <[email protected]> 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. > --047d7b6042fa74c26004d10fe8e9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <p>Packlist 2.0</p> <p>MYMETA + installed file details</p> <p>?</p> <div class=3D"gmail_quote">On Dec 17, 2012 12:36 AM, "Tim Bunce" = <<a href=3D"mailto:[email protected]">[email protected]</a>> wrot= e:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"margi= n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On Sun, Dec 16, 2012 at 04:53:49PM -0800, Michael G Schwern wrote:<br> > On <a href=3D"tel:2012.12.16%2011" value=3D"+12012121611">2012.12.16 1= 1</a>:57 AM, Leon Timmermans wrote:<br> ><br> > >> * Where to put the database? =A0What about non-standard insta= ll locations?<br> <br> > >> Another is to have a separate install database for non-standa= rd install<br> > >> locations.<br> <br> A separate install database for each install location seems like the only<b= r> workable approach.<br> <br> > >> This makes sense to me, but it brings in the sticky problem<b= r> > >> of having to merge install databases. =A0Sticky, but still a = SMOP. =A0Once you<br> > >> have to implement merging anyway, it now makes sense to have = an install<br> > >> database for each install location. =A0One for core. =A0One f= or vendor. =A0One for<br> > >> perl. =A0And one for each custom location. =A0This has a lot = of advantages to<br> > >> better fit how Perl layers module installs.<br> > >><br> > >> =A0 =A0 * allows separation of permissions<br> > >> =A0 =A0 * allows queries of what's installed based on wha= t's in @INC<br> <br> Perhaps that could be taken one step further: one per installed distributio= n.<br> <br> Then, what's kept at each install location is a cached summary of what&= #39;s<br> installed below it. One that can be cross-checked against the individual<br= > distribution 'databases' and rebuilt from it.<br> <br> That seems more robust against various kinds of 'damage'.<br> <br> > >> That second one is important. =A0When a normal user queries t= he database, they<br> > >> want to get what's installed in the standard library loca= tion. =A0When a<br> > >> local::lib user queries the database, they want to get what&#= 39;s installed in the<br> > >> standard library locations AND their own local lib.<br> <br> I.e., the default view is "what's installed in my @INC".<br> <br> > > The combination of these is problematic. You might upgrade EU::In= stall<br> > > in your local module path, but not have write permissions on the<= br> > > system paths. In practice, we might have to support all our older= <br> > > versions :-|<br> ><br> > Erg, good point. =A0That very likely scenario is definitely going to r= equire<br> > some thought.<br> <br> *nods*<br> <br> Here's where "one install database per distribution with a cache<b= r> database at the install location" offers another benefit.<br> The "per distribution install database" can be kept in a very sim= ple<br> plain text format that targets readability and future-proofing,<br> while the "cache database at the install location" can target<br> performance.<br> <br> If an install location has an incompatible version of the db,<br> the per distribution dbs could be read instead. That's slow but workabl= e<br> and seems reasonable for that presumably uncommon case.<br> I can think of a few further options as well.<br> <br> Tim.<br> </blockquote></div> --047d7b6042fa74c26004d10fe8e9--