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 schw...@pobox.com
wrote:
Storage is a problem. The only reliable database Perl ships with is DBM,
an
on disk hash, so we can't get
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.
Or the
On Sat, Jan 5, 2013 at 12:33 AM, Adam Kennedy a...@ali.as 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
On 31 December 2012 19:38, Leon Timmermans faw...@gmail.com wrote:
On Mon, Dec 31, 2012 at 6:50 PM, Jan Dubois j...@activestate.com wrote:
Mostly I would prohibit sharing of directories between Perl installations,
and even within a single installation, the sharing of directories between
[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 problem if
On Thu, Dec 20, 2012 at 05:48:10PM +0100, Johan Vromans wrote:
Tim Bunce tim.bu...@pobox.com 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
On Fri, Dec 28, 2012 at 4:18 PM, Leon Timmermans faw...@gmail.com 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
On Mon, Dec 31, 2012 at 6:50 PM, Jan Dubois j...@activestate.com 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
On Fri, Dec 28, 2012 at 2:44 AM, Jan Dubois j...@activestate.com 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
-- Forwarded message --
From: Jan Dubois j...@activestate.com
Date: Thu, Dec 27, 2012 at 5:40 PM
Subject: Re: How To Build A Perl Package Database
To: Leon Timmermans faw...@gmail.com
On Thu, Dec 20, 2012 at 2:42 AM, Leon Timmermans faw...@gmail.com wrote:
On Mon, Dec 17, 2012
On Mon, Dec 17, 2012 at 08:23:51PM +0100, Ask Bjørn Hansen wrote:
On Dec 17, 2012, at 9:36, Tim Bunce tim.bu...@pobox.com 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
On Mon, Dec 17, 2012 at 9:36 AM, Tim Bunce tim.bu...@pobox.com 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
Tim Bunce tim.bu...@pobox.com 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 tim.bu...@pobox.com 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
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
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
On 17 December 2012 01:53, Michael G Schwern schw...@pobox.com 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
[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
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 overtaken
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 schw...@pobox.com 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
On Sun, Dec 16, 2012 at 6:34 PM, Johan Vromans jvrom...@squirrel.nl 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
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 you
On Mon, Dec 17, 2012 at 1:53 AM, Michael G Schwern schw...@pobox.com 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
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
25 matches
Mail list logo
