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 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
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
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
Thoughts?
Seems a good idea.
Anybody wiling to submit a TPF grant to work on this? O:-)
Michael G Schwern schw...@pobox.com 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
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 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 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
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 library root
and the tools using the database will need to know to do
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 2012.12.16 1:10 PM, Leon Timmermans wrote:
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
19 matches
Mail list logo
