We have a lot of serious problems because we lack a database of installed
distributions, releases and files. There are serious problems with
implementing one given A) the limitations of the standard Perl install and B)
wedging it into existing systems. But I think I have a solution. Its similar
Thoughts?
Seems a good idea.
Anybody wiling to submit a TPF grant to work on this? O:-)
On Sat, Dec 15, 2012 at 11:59 PM, Michael G Schwern wrote:
> We have a lot of serious problems because we lack a database of installed
> distributions, releases and files. There are serious problems with
> implementing one given A) the limitations of the standard Perl install and B)
> wedging it
On Sun, Dec 16, 2012 at 6:34 PM, Johan Vromans wrote:
> Debian, and most other systems have decent package- and install
> managers. *They* maintain the database with installed distributions,
> releases and files. The only good approach for us is to play with them.
>
> So, an enhanced META.yaml or
On 2012.12.16 1:10 PM, Leon Timmermans wrote:
> On Sun, Dec 16, 2012 at 6:34 PM, Johan Vromans wrote:
>> Debian, and most other systems have decent package- and install
>> managers. *They* maintain the database with installed distributions,
>> releases and files. The only good approach for us is t
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 packlists but also
> perllocal
I was thinking about what yo
a list of installed files and the contents of MYMETA should suffice. we talked
about trying to fix packlists some years ago but I don't have that ref handy
sorry. os package management isn't enough, needs to be per @INC path, I think.
-E
--
Sent from my Android phone with K-9.
On Mon, Dec 17, 2012 at 1:53 AM, Michael G Schwern wrote:
> I was thinking about what you said about packlists, and I wonder how much
> information one could scrape out of them. Would it be enough to reconstruct
> at least that a group of files belongs to a release? That would be enough to
> be
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
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
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
Michael G Schwern writes:
> We have a lot of serious problems because we lack a database of
> installed distributions, releases and files.
No, that is not our problem.
Our problem is that we want to handle it ourselves. This may have been a
good approach in the dark ages, but nowadays there are
[Quoting Leon Timmermans, on December 16 2012, 22:10, in "Re: How To Build A P"]
> There are many ways to deploy stuff, not everyone uses rpm/deb,
> there are good reasons not to do so: for starters it assumes you
> have root privileges.
Reality has overtaken these ancient views for a long time al
On 16/12/12 21:23, Johan Vromans wrote:
[Quoting Leon Timmermans, on December 16 2012, 22:10, in "Re: How To Build A P"]
There are many ways to deploy stuff, not everyone uses rpm/deb,
there are good reasons not to do so: for starters it assumes you
have root privileges.
Reality has overtake
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
On Mon, Dec 17, 2012 at 08:23:51PM +0100, Ask Bjørn Hansen wrote:
> 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"
On Mon, Dec 17, 2012 at 9:36 AM, Tim Bunce wrote:
> A separate install database for each install location seems like the only
> workable approach.
One minor complication of that is the strictest sense an "install
location" isn't all that well defined. Or perhaps I should say every
dist has 8 inst
Tim Bunce writes:
> A separate install database for each install location seems like the
> only workable approach.
Store the complete distribution in a git repository?
-- Johan
On Thu, Dec 20, 2012 at 11:42:06AM +0100, Leon Timmermans wrote:
> On Mon, Dec 17, 2012 at 9:36 AM, Tim Bunce wrote:
> > A separate install database for each install location seems like the only
> > workable approach.
>
> One minor complication of that is the strictest sense an "install
> locatio
-- Forwarded message --
From: Jan Dubois
Date: Thu, Dec 27, 2012 at 5:40 PM
Subject: Re: How To Build A Perl Package Database
To: Leon Timmermans
On Thu, Dec 20, 2012 at 2:42 AM, Leon Timmermans wrote:
> On Mon, Dec 17, 2012 at 9:36 AM, Tim Bunce wrote:
> > A
On Fri, Dec 28, 2012 at 2:44 AM, Jan Dubois wrote:
> I wonder if it isn't time to deprecate all the complex install combinations
> that may have made sense when hard disks was rather limited.
>
> In ActivePerl we enforce a pretty simplified install layout to be able to
> create an intuitive packag
On Fri, Dec 28, 2012 at 4:18 PM, Leon Timmermans wrote:
> > Anyways, I just wanted to say that without putting some restrictions on
> how
> > modules (and corresponding scripts) can be installed, creating a package
> > manager would seem to get even more complex than ExtUtils::Makemaker...
> :)
>
On Mon, Dec 31, 2012 at 6:50 PM, Jan Dubois wrote:
> Mostly I would prohibit sharing of directories between Perl installations,
> and even within a single installation, the sharing of directories between
> install locations.
>
> E.g. the default configuration right now has $Config{installbin} and
On Thu, Dec 20, 2012 at 05:48:10PM +0100, Johan Vromans wrote:
> Tim Bunce writes:
>
> > A separate install database for each install location seems like the
> > only workable approach.
>
> Store the complete distribution in a git repository?
>
One issue I had when trying to store distribution
On 31 December 2012 19:38, Leon Timmermans wrote:
> On Mon, Dec 31, 2012 at 6:50 PM, Jan Dubois wrote:
>> Mostly I would prohibit sharing of directories between Perl installations,
>> and even within a single installation, the sharing of directories between
>> install locations.
>>
>> E.g. the de
[Quoting Philippe Bruhat (BooK), on January 2 2013, 01:23, in "Re: How To Build
A P"]
> One issue I had when trying to store distributions with
> Git::CPAN::Hook is that if a file does not change between two
> versions of a distribution, then git won't "detect" it.
This doesn't look like a proble
On Sun, Dec 16, 2012 at 08:57:48PM +0100, Leon Timmermans wrote:
> On Sat, Dec 15, 2012 at 11:59 PM, Michael G Schwern wrote:
> > Storage is a problem. The only reliable "database" Perl ships with is DBM,
> > an
> > on disk hash, so we can't get too fancy. It might take several DBM files,
> >
On 1/4/13 4:41 AM, David Cantrell wrote:
> On Sun, Dec 16, 2012 at 08:57:48PM +0100, Leon Timmermans wrote:
>> On Sat, Dec 15, 2012 at 11:59 PM, Michael G Schwern
>> wrote:
>>> Storage is a problem. The only reliable "database" Perl ships with is DBM,
>>> an
>>> on disk hash, so we can't get to
I'll say it a second time...
Packlist 2.0
Take MYMETA, add an extra key with the list that will be installed, intall
it in the usual place as we do now.
Package manager scans the filesystem for the packlist files.
Might seem slow, but on SSDs scanning the filesystem like that is super
super fas
On Sat, Jan 05, 2013 at 10:33:04AM +1100, Adam Kennedy wrote:
> I'll say it a second time...
>
> Packlist 2.0
>
> Take MYMETA, add an extra key with the list that will be installed, intall
> it in the usual place as we do now.
>
> Package manager scans the filesystem for the packlist files.
>
On Sat, Jan 5, 2013 at 12:33 AM, Adam Kennedy wrote:
> I'll say it a second time...
>
> Packlist 2.0
>
> Take MYMETA, add an extra key with the list that will be installed, intall
> it in the usual place as we do now.
>
> Package manager scans the filesystem for the packlist files.
>
> Might seem
31 matches
Mail list logo
