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
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 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
Lyle webmas...@cosmicperl.com 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
On 17/12/2012 13:52, Johan Vromans wrote:
Lyle webmas...@cosmicperl.com 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
Hello
On 16/12/12 17:34, Johan Vromans wrote:
So, an enhanced META.yaml or whatsoever may be a good idea, but *only*
to generate a deb control file, or rpm spec file, or innosetup file and
so on.
That is the problem. There are too many options out there. Can we
control all Linux
Alberto Simões al...@alfarrabio.di.uminho.pt writes:
That is the problem. There are too many options out there. Can we
control all Linux distributions packaging systems?
All? Maybe not. Many? Yes. All of the more popular? Certainly.
Installing (updating, removing) modules is currently dealt
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
[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
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
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 17/12/2012 00:43, Michael G Schwern wrote:
... Perl is a cross platform, cross environment
language. Not all the environments we work with have good package managers.
Off the top of my head: Windows, a huge, hidden number of our users, has
nothing usable and the Solaris package manger is a
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
23 matches
Mail list logo