Re: "Avoiding the vendor perl fad diet"
On Fri, Jan 27, 2012 at 8:30 PM, Michael Alan Dorman
> Gabor Szabo <email@example.com> writes:
>> I'd appreciate a lot if you could provide a detailed step-by-step
>> explanation on what you do and how you do that?
>> I think this would be extremely useful to people like myself, who
>> struggle between aptitude, local::lib and perlbrew.
> I would be happy to do a writeup of some sort, Gabor. Not, perhaps, at
> this very instant---I do actually have work I should be doing ;)---but
> in the next week or two.
> However, I could make it more useful if I could get some guidance from
> you (and others) about what things you specifically find vexing about
> going the aptitude route that leads you to look at local::lib or
> perlbrew---otherwise I suspect that the things that others might be
> fighting are things I figured out how to work with so long ago that I
> don't remember them as obstacles.
I was trying to figure out what is really the issue but I am not sure it is not
just plain lack of knowledge. The fact that I have never used dh-make-perl.
I am using Ubuntu and not Debian but theoretically this should not make
any difference in this discussion. Let me know if you think it does.
I think my main worry is that I don't want to mix vendor supplied
stuff and site supplied stuff.
Using local::lib and installing everything in my home directory makes
it easy to wipe out all the site
stuff while keeping all the vendor stuff.
If I am not mistaken the @INC order was not really "correct" prior to
(hmm, I thin 5.12 but I am not sure)
but recently it has been fixed and now site comes before vendor so
this *should* not be an issue.
Still I hear - though never actually checked - that some modules still
install themselves in other
places and not in "site".
The thing is that I am running several applications on the same server.
As it is today, with the current setup using local::lib they all use
the same modules and the same versions
of the modules. (this would be the same if I used dh-make-perl and
installed them as .deb).
This is a bit worrying as this means when I install a new application
that needs a newer version of dependency.
that module is upgraded to all the other applications that I have not
tested with the new version of the module.
So I recently thought how to solve this.
One solution could be to use separate local::lib directories for each
application. That would include some duplicate module installations
but that would reduce the risk. Actually I should probably do real
Configuration Management for all my dependencies and should not
install them from CPAN. At least not on the production system.
I am not sure if this helps you in any way to remind you what
obstacles have you seen :)