On Dec 17, 2012, at 9:36, Tim Bunce wrote:
> A separate install database for each install location seems like the only
> workable approach.
It seems to me that the database indeed will have to be[1] "per library root"
and the tools using the database will need to know to do lookups everywhere
Thoughts?
Seems a good idea.
Anybody wiling to submit a TPF grant to work on this? O:-)
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 separ
On 17/12/2012 13:52, Johan Vromans wrote:
Lyle writes:
Michael is right. I deal with setting up Perl driven software are a
wide variety of systems. This often means setting up Perl itself
because the system doesn't have one, or to have a non system instance.
It can be a real pain, it shouldn't
Packlist 2.0
MYMETA + installed file details
?
On Dec 17, 2012 12:36 AM, "Tim Bunce" 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
> location
Lyle writes:
> Michael is right. I deal with setting up Perl driven software are a
> wide variety of systems. This often means setting up Perl itself
> because the system doesn't have one, or to have a non system instance.
> It can be a real pain, it shouldn't be, it should be easy and straight
>
On 17 December 2012 01:53, Michael G Schwern wrote:
> On 2012.12.16 11:57 AM, Leon Timmermans wrote:
>> I can agree with all of that. Actually, starting a discussion about
>> this was on my todo-list for the last QA hackathon but I didn't get
>> around to it. Ideally, it should replace not only pa
