Re: How To Build A Perl Package Database

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