Debian recommendation

[Octavian Râşniţă]

Hi,

I've seen a recommendation on this list for Debian for running perl apps,
and recently I started to use this distro.

I've seen that I can install perl modules very hard under Debian if I use
the CPAN shell.
For example if I run

$ cpan
cpan> install Class::MOP

it gives an "Unknown error" and it doesn't want to install and the same with
Catalyst::Runtime.

But if I do then

cpan> look ModuleName
$ perl Makefile.PL
$ make
$ make test
$make install

I can install the modules without problem (usually).
However, I need to manually install each dependency.

I've seen this strange thing under 2 Debian systems so I think it is not a
Debian bug.

Does this happen to you? If yes, how do you solve it?

Thank you.

Octavian


_______________________________________________
List: Catalyst@...
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@.../
Dev site: http://dev.catalyst.perl.org/

[Ari Constancio-3]

2009/10/16 Octavian Râşniţă <orasnita@...>:
> Does this happen to you? If yes, how do you solve it?

Hello,

Sometimes, in a hurry, I install modules through apt-get/aptitude.

Regards.
Ari Constancio

_______________________________________________
List: Catalyst@...
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@.../
Dev site: http://dev.catalyst.perl.org/

[Juan Miguel Paredes]

2009/10/17 Octavian Râşniţă <orasnita@...>:

> Hi,
>
> I've seen a recommendation on this list for Debian for running perl apps,
> and recently I started to use this distro.
>
> I've seen that I can install perl modules very hard under Debian if I use
> the CPAN shell.
> For example if I run
>
> $ cpan
> cpan> install Class::MOP
>
> it gives an "Unknown error" and it doesn't want to install and the same with
> Catalyst::Runtime.
>
> But if I do then
>
> cpan> look ModuleName
> $ perl Makefile.PL
> $ make
> $ make test
> $make install
>
> I can install the modules without problem (usually).
> However, I need to manually install each dependency.
>
> I've seen this strange thing under 2 Debian systems so I think it is not a
> Debian bug.
>
> Does this happen to you? If yes, how do you solve it?
>

Hi, Octavian.

Are you running cpan with root or a normal user account? Under a
non-root account, it would be advisable to install and use local::lib,
maintaining your own directory of perl modules under your home
directory. Some modules would be better installed with the distro
package manager (aptitude / apt-get), like Module::Install. In all,
Debian and Ubuntu have worked pretty well for me.

Regards,

Juan:

_______________________________________________
List: Catalyst@...
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@.../
Dev site: http://dev.catalyst.perl.org/

[J. Shirley]

2009/10/16 Octavian Râşniţă <orasnita@...>

Hi,

I've seen a recommendation on this list for Debian for running perl apps, and recently I started to use this distro.

I've seen that I can install perl modules very hard under Debian if I use the CPAN shell.
For example if I run

$ cpan
cpan> install Class::MOP

it gives an "Unknown error" and it doesn't want to install and the same with Catalyst::Runtime.

But if I do then

cpan> look ModuleName
$ perl Makefile.PL
$ make
$ make test
$make install

I can install the modules without problem (usually).
However, I need to manually install each dependency.

I've seen this strange thing under 2 Debian systems so I think it is not a Debian bug.

Does this happen to you? If yes, how do you solve it?

Thank you.

Octavian

My Debian steps are:

(as root)
1. Upgrade CPAN (Bundle::CPAN)
2. Upgrade CPANPLUS
3. Upgrade/Install Module::Install
4. Upgrade/Install Module::Build
5. Install local::lib

(as app user)
6. Install deps for application

I've never had a problem with things not building doing this, but haven't tried other ways.

-J

_______________________________________________
List: Catalyst@...
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@.../
Dev site: http://dev.catalyst.perl.org/

[Octavian Râşniţă]

From: "J. Shirley" <jshirley@...>

> Hi,
>
> I've seen a recommendation on this list for Debian for running perl apps,
> and recently I started to use this distro.
>
> I've seen that I can install perl modules very hard under Debian if I use
> the CPAN shell.
> For example if I run
>
> $ cpan
> cpan> install Class::MOP
>
> it gives an "Unknown error" and it doesn't want to install and the same
> with Catalyst::Runtime.
>
> But if I do then
>
> cpan> look ModuleName
> $ perl Makefile.PL
> $ make
> $ make test
> $make install
>
> I can install the modules without problem (usually).
> However, I need to manually install each dependency.
>
> I've seen this strange thing under 2 Debian systems so I think it is not a
> Debian bug.
>
> Does this happen to you? If yes, how do you solve it?
>
> Thank you.
>
> Octavian
>
>

My Debian steps are:

(as root)
1. Upgrade CPAN (Bundle::CPAN)
2. Upgrade CPANPLUS
3. Upgrade/Install Module::Install
4. Upgrade/Install Module::Build
5. Install local::lib

(as app user)
6. Install deps for application

I've never had a problem with things not building doing this, but haven't
tried other ways.

-J

I guess your installing the deps for the application using local::lib,
right?

Good idea. Is there a way of using Makefile.PL of the application to
automaticly install all the dependencies using local::lib?

Thanks.

Octavian


_______________________________________________
List: Catalyst@...
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@.../
Dev site: http://dev.catalyst.perl.org/

[Octavian Râşniţă]

From: "Juan Miguel Paredes" <juan.paredes@...>
...
> I can install the modules without problem (usually).
> However, I need to manually install each dependency.
>
> I've seen this strange thing under 2 Debian systems so I think it is not a
> Debian bug.
>
> Does this happen to you? If yes, how do you solve it?
>

Hi, Octavian.

Are you running cpan with root or a normal user account? Under a
non-root account, it would be advisable to install and use local::lib,
maintaining your own directory of perl modules under your home
directory. Some modules would be better installed with the distro
package manager (aptitude / apt-get), like Module::Install. In all,
Debian and Ubuntu have worked pretty well for me.

I have tried to install them using the root account, but it seems to be a
good idea to install them using local::lib, because I could easier copy to
another similar system.

I've seen that I can install the modules very easy with cpanp under Debian,
so it is not a big issue that cpan doesn't work under this distro very well,
but I will try to find more about installing the modules using local::lib.

Octavian



_______________________________________________
List: Catalyst@...
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@.../
Dev site: http://dev.catalyst.perl.org/

[Tomas Doran]

Octavian Râşniţă wrote:
> Good idea. Is there a way of using Makefile.PL of the application to
> automaticly install all the dependencies using local::lib?

perl Makefile.PL && make install

HTH
t0m


_______________________________________________
List: Catalyst@...
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@.../
Dev site: http://dev.catalyst.perl.org/

[J. Shirley]

2009/10/16 Octavian Râşniţă <orasnita@...>

From: "J. Shirley" <jshirley@...>

Hi,

I've seen a recommendation on this list for Debian for running perl apps,
and recently I started to use this distro.

I've seen that I can install perl modules very hard under Debian if I use
the CPAN shell.
For example if I run

$ cpan
cpan> install Class::MOP

it gives an "Unknown error" and it doesn't want to install and the same
with Catalyst::Runtime.

But if I do then

cpan> look ModuleName
$ perl Makefile.PL
$ make
$ make test
$make install

I can install the modules without problem (usually).
However, I need to manually install each dependency.

I've seen this strange thing under 2 Debian systems so I think it is not a
Debian bug.

Does this happen to you? If yes, how do you solve it?

Thank you.

Octavian

My Debian steps are:

(as root)
1. Upgrade CPAN (Bundle::CPAN)
2. Upgrade CPANPLUS
3. Upgrade/Install Module::Install
4. Upgrade/Install Module::Build
5. Install local::lib

(as app user)
6. Install deps for application

I've never had a problem with things not building doing this, but haven't
tried other ways.

-J

I guess your installing the deps for the application using local::lib, right?

Good idea. Is there a way of using Makefile.PL of the application to automaticly install all the dependencies using local::lib?

Thanks.

Octavian

Yes, this works just fine as you would expect.  Just run "make" should do it.

My usual post-deployment command is: perl Makefile.PL && make && make test && make clean

Assuming exit status is 0, I had a successful deployment.

-J

_______________________________________________
List: Catalyst@...
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@.../
Dev site: http://dev.catalyst.perl.org/

[Daniel Pittman]

Octavian Râşniţă <orasnita@...> writes:

G'day Octavian.

> I've seen a recommendation on this list for Debian for running perl apps,
> and recently I started to use this distro.  I've seen that I can install
> perl modules very hard under Debian if I use the CPAN shell.

If you forgive me descending into opinion, I think you are approaching this
from a point of view that will make Debian, more or less, unhelpful to you.
Installing Debian, then putting everything else in place from CPAN (at least
system-wide) is going to cause problems in the longer term.

Debian has two key advantages over distributions:

1. It has a long "stable" release cycle, and strong assurances of security
   during that cycle.

2. It has a very big pool of packages (2,065 Perl libraries, presently)
   compared to many of the other distributions.


The first means that you can safely keep updates in place and be confident
that your system will stay working; this includes Perl modules that have
security issues and the like, because Debian work very hard to backport
security fixes to the same module version.

(OTOH, it is also a drawback: if Debian/stable ships with version 1.23 it will
 still have version 1.23 two years later.)


The second means that you have a huge selection of code that you know is going
to work together, effectively, and be supported by someone else.  If security
issues come up, or a library changes incompatibly or whatever, Debian look
after it for you.


If you just install from CPAN directly then you lose those values: Debian
don't do security stuff on your CPAN installed code, so point one is lost.

You also don't get the compatibility stuff: the Debian packaging
infrastructure and CPAN are not directly integrated, so you can't use a CPAN
installed module to satisfy a Debian Perl dependency.

That means that you actually have to do /more/ work if you upgrade an existing
module under Debian with CPAN, not less, which /really/ misses the point.


So, I strongly advise that for, say...

[...]

> cpan> install Class::MOP

...this, you instead use 'aptitude install libclass-mop-perl', which uses the
Debian supplied version of Class::MOP.  Then you can work with that specific
version in your software, and know that for the next few years it will stay
secure and stable.


If you do need packages outside those in Debian, or to upgrade a Debian
supplied Perl package, the best strategy is to build a platform package from
the CPAN distribution, and manage it with the Debian tools — not the CPAN
tool.

There are a bunch of ways to do that, including dh-make-perl, dh-make,
CPANPLUS::Dist::Deb, and hand-packaging[1].  Then, shove those hand-made
packages into your own private Debian package repository, and it integrates
nicely into the tools and everything.


If you do just want to use cpan directly, either use local::lib, or use a
distribution that makes direct installation from CPAN the standard mechanism
for getting access to Perl.

I understand that the BSDPAN tool, in *BSD ports, as well as Gentoo, offer
very good tools in this regard, certainly better and easier than the Debian
tools.  I can't say much more, though, because I don't have enough deployment
experience with them to comment — and there are doubtless other platforms that
make CPAN(-alike) tools easier to integrate with the distribution.

Regards,
        Daniel

Footnotes:
[1]  This is probably surprisingly easy, actually, since CPAN packages are
     simple to configure, build and install, so Debian packages of them are
     correspondingly easy.  Go Perl!

--
✣ Daniel Pittman            ✉ daniel@...            ☎ [phone]
               ♽ made with 100 percent post-consumer electrons
   Looking for work?  Love Perl?  In Melbourne, Australia?  We are hiring.

_______________________________________________
List: Catalyst@...
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@.../
Dev site: http://dev.catalyst.perl.org/

[Paul Makepeace-4]

On Fri, Oct 16, 2009 at 7:01 PM, Daniel Pittman <daniel@...> wrote:

>
> Octavian Râşniţă <orasnita@...> writes:
>
> G'day Octavian.
>
> > I've seen a recommendation on this list for Debian for running perl apps,
> > and recently I started to use this distro.  I've seen that I can install
> > perl modules very hard under Debian if I use the CPAN shell.
>
> If you forgive me descending into opinion, I think you are approaching this
> from a point of view that will make Debian, more or less, unhelpful to you.
> Installing Debian, then putting everything else in place from CPAN (at least
> system-wide) is going to cause problems in the longer term.

> There are a bunch of ways to do that, including dh-make-perl, dh-make,
> CPANPLUS::Dist::Deb, and hand-packaging[1].  Then, shove those hand-made
> packages into your own private Debian package repository, and it integrates
> nicely into the tools and everything.

I recently have completely tossed using Debian's perl packages
because, while I do love Debian and all its package awesomeness, there
simply wasn't the package lib*-perl support in stable/lenny and even
testing/squeeze didn't have all the goods needed for a (what I think
is) fairly regular Catalyst install.

So my question then is: given you've presumably done this, which of
your quoted solutions do you like best? I tried dh-make-perl many
moons ago and gave up due to annoyances around following dependencies.
Maybe CPP::Dist::Deb or something else solves that.

I'm hoping local::lib + cpan + git solves this but curious how
Debian-integrated solutions work too.

Paul

_______________________________________________
List: Catalyst@...
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@.../
Dev site: http://dev.catalyst.perl.org/

[Jason Galea]

On Sat, Oct 17, 2009 at 12:33 PM, Paul Makepeace <paulm@...> wrote:

I recently have completely tossed using Debian's perl packages
because, while I do love Debian and all its package awesomeness, there
simply wasn't the package lib*-perl support in stable/lenny and even
testing/squeeze didn't have all the goods needed for a (what I think
is) fairly regular Catalyst install.

So my question then is: given you've presumably done this, which of
your quoted solutions do you like best? I tried dh-make-perl many
moons ago and gave up due to annoyances around following dependencies.
Maybe CPP::Dist::Deb or something else solves that.

I'm hoping local::lib + cpan + git solves this but curious how
Debian-integrated solutions work too.

Paul

I would have to agree with Paul here. I went the dh-make-perl & CPANPLUS::Dist::Deb routes, had my own repositories and packaged my own modules as debs. I basically found it complicated everything too much for my liking. I pursued this for quite a while
knowing Debian used Perl extensively in it's own admin scripts and messing with them carried the threat of screwing with more than my own stuff. I encounted repeated issues with the automated packaging systems and more trying to manage my own repository. I currently have cpanp configured on my servers so I can install modules to a user's home directory. I then modify other users' .bashrc to add that directory to inc. Getting cpanp configured and set up this way has proved to be tricky so in future I will be trying the local::lib method.

I love Debian and settled on it as my dist of choice many years ago but wanting to use the latest & greatest Perl modules means not sticking with 100% Debian packages. Catalyst & DBIx::Class (as examples) move way too quickly for that and the benefits that the latest versions offer are often too good to refuse. I still use aptitude as my first port-o-call for installing Perl modules whenever I can but when that fails cpanp easily picks up the slack and as a last resort I can always use cpanp as root. I've been running like this for a year or so now and in that time I haven't had to spend more than 10 minutes ugrading or installing any module I've needed.

..just my 2c

cheers,

J
 

--
Jason Galea
Web Developer

Ph 07 40556926
Mob [phone]
www.eightdegrees.com.au


_______________________________________________
List: Catalyst@...
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@.../
Dev site: http://dev.catalyst.perl.org/

[Daniel Pittman]

Paul Makepeace <paulm@...> writes:

> On Fri, Oct 16, 2009 at 7:01 PM, Daniel Pittman <daniel@...> wrote:
>> Octavian Râşniţă <orasnita@...> writes:
>>
>> > I've seen a recommendation on this list for Debian for running perl apps,
>> > and recently I started to use this distro.  I've seen that I can install
>> > perl modules very hard under Debian if I use the CPAN shell.
>>
>> If you forgive me descending into opinion, I think you are approaching this
>> from a point of view that will make Debian, more or less, unhelpful to you.
>> Installing Debian, then putting everything else in place from CPAN (at least
>> system-wide) is going to cause problems in the longer term.
>
>> There are a bunch of ways to do that, including dh-make-perl, dh-make,
>> CPANPLUS::Dist::Deb, and hand-packaging[1].  Then, shove those hand-made
>> packages into your own private Debian package repository, and it integrates
>> nicely into the tools and everything.
>
> I recently have completely tossed using Debian's perl packages because,
> while I do love Debian and all its package awesomeness, there simply wasn't
> the package lib*-perl support in stable/lenny and even testing/squeeze
> didn't have all the goods needed for a (what I think is) fairly regular
> Catalyst install.

Presumably the packaged Catalyst wasn't sufficient either. ;)

> So my question then is: given you've presumably done this, which of your
> quoted solutions do you like best? I tried dh-make-perl many moons ago and
> gave up due to annoyances around following dependencies.

dh-make-perl or debhelper (>= 7.0) are the nicest options, in terms of package
quality, but don't do anything about following dependencies.

dh-make-perl was unmaintained and awful in earlier releases; Lenny is better,
and Sid (unstable) better still, but they are still not /great/.

CPANPLUS::Dist::Deb is the easiest, but has some quirks; the biggest is that
it doesn't check if a packaged-but-not-installed Perl module meets a
dependency.


Anyway, if it helps: the best answer is to hand the maintenance of the
infrastructure to an appropriate expert in the company, and work with them.

That may mean Debian packages, or something else, and it probably /also/ means
that you can't just deploy the latest CPAN everything — which, yes, is a
trade-off on all sorts of levels.[1]

> I'm hoping local::lib + cpan + git solves this but curious how
> Debian-integrated solutions work too.

If you do want to go the Debian route, you are going to need someone who has a
reasonably deep knowledge of Debian Perl packaging at some point, sadly.[2]

I generally consider using the dh-make-perl / debhelper 7 tools and manually
following dependencies to be a reasonable strategy.  This is more work, but
results in better considered and higher quality outcomes.

(case in point: JSON 1 vs JSON 2, with their incompatible API.  If you don't
 pay attention, upgrading can break other application deployments.)


FWIW, local::lib (or the hand-rolled equivalent) is probably the best strategy
I can identify for addressing this with the ability to use random CPAN stuff,
without breaking other applications, and without the overheads of central
management.[3]


...and, again FWIW, my original point was not that the Debian approach is
necessarily the best approach, but rather than Debian won't return nearly the
same value if you don't accept the costs of their approach. :)

        Daniel

Footnotes:
[1]  ...and, yes, I do get annoyed by this when I wear a developer hat and
     all.  Heck, for my own local utilities have something like 60 or so Perl
     modules hand-packaged on Debian/unstable.  (Down from 80, because
     apparently upstream Debian/perl people have the same taste in CPAN
     modules that I do, so they keep packaging them for me. ;)

[2]  I strongly suspect this is true of cpan2rpm, and BSDPAN, and the Gentoo
     tools also, but I have not used them hard enough to find out.

[3]  I don't think this is actually worth the trade-off in the longer term,
     since you now have to address questions like deploying bug-fixes in
     modules for every application (server) independently, but YMMV.

--
✣ Daniel Pittman            ✉ daniel@...            ☎ [phone]
               ♽ made with 100 percent post-consumer electrons
   Looking for work?  Love Perl?  In Melbourne, Australia?  We are hiring.

_______________________________________________
List: Catalyst@...
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@.../
Dev site: http://dev.catalyst.perl.org/

[Octavian Râşniţă]

From: "Daniel Pittman" <daniel@...>
Octavian Râşniţă <orasnita@...> writes:

G'day Octavian.

> I've seen a recommendation on this list for Debian for running perl apps,
> and recently I started to use this distro.  I've seen that I can install
> perl modules very hard under Debian if I use the CPAN shell.

If you forgive me descending into opinion, I think you are approaching this
from a point of view that will make Debian, more or less, unhelpful to you.
Installing Debian, then putting everything else in place from CPAN (at least
system-wide) is going to cause problems in the longer term.


Yes I think you are right. I think I would like a distro that allow me to
install packages like libpng, libgd and others like these very easy, like
yum and apt-get do, but also let me install perl modules with cpan because
no distro's repository would be as well updated as CPAN directly.

The solution seems to be to use Debian and install perl modules using
local::lib.

Now, I've started to use a fresh installed Debian and I've installed very
many CPAN modules using CPAN in the default perl modules location.
What would you recommend me to do in this case? Can I just rename/delete the
files and dirs installed into

/usr/local/share/perl/5.10.0

and install them using local::lib?

Octavian


_______________________________________________
List: Catalyst@...
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@.../
Dev site: http://dev.catalyst.perl.org/

[Octavian Râşniţă]

From: "J. Shirley" <jshirley@...>

>>
>> cpan> look ModuleName
>> $ perl Makefile.PL
>> $ make
>> $ make test
>> $make install
>>
>> I can install the modules without problem (usually).
>> However, I need to manually install each dependency.
>>
>> I've seen this strange thing under 2 Debian systems so I think it is not
>> a
>> Debian bug.
>>
>> Does this happen to you? If yes, how do you solve it?
>>
>> Thank you.
>>
>> Octavian
>>
>>
>>  My Debian steps are:
>
> (as root)
> 1. Upgrade CPAN (Bundle::CPAN)
> 2. Upgrade CPANPLUS
> 3. Upgrade/Install Module::Install
> 4. Upgrade/Install Module::Build
> 5. Install local::lib

Well, after upgrading these modules, the installation of other modules seems
to work better with the cpan shell.

> (as app user)
> 6. Install deps for application
>
> I've never had a problem with things not building doing this, but haven't
> tried other ways.

Can you tell me more about this last step?

I have tried to put in Makefile.PL:

use FindBin;
use local::lib "$FindBin::Bin/support";

But when I run it, it still tries to write to /var/www which is the home dir
of www-data user (the current user).

So I have also tried removing those 2 lines and doing:

$ perl -Mlocal::lib

Then
$ perl Makefile.PL

But it asked me:

[sudo] password for www-data:

and I must give the root password (and www-data is not in the sudoers
group).

I have tried with another user:

# adduser octavian
# su octavian
$ cd /home/octavian
$ perl -Mlocal::lib
...
$ perl Makefile.PL

But it also asked me:

[sudo] password for octavian:

...when trying to install Catalyst::Runtime, so I must be doing something
wrong.

For the first time I tried to su www-data and use this user because it is
the user used by Apache and if I'd use another user and generate a temporary
file, for example a compiled TT template, when Apache tries to re-write that
file, it gives an error telling that it doesn't have the necessary
permissions to overwrite it.

Thanks.

Octavian


_______________________________________________
List: Catalyst@...
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@.../
Dev site: http://dev.catalyst.perl.org/

[Daniel Pittman]

Octavian Râşniţă <orasnita@...> writes:
> From: "Daniel Pittman" <daniel@...>
> > Octavian Râşniţă <orasnita@...> writes:

As a side note, Octavian, your mail client didn't quote any of my text, which
made it quite tricky to work out what you and I both said. ;)

> >> I've seen a recommendation on this list for Debian for running perl apps,
> >> and recently I started to use this distro.  I've seen that I can install
> >> perl modules very hard under Debian if I use the CPAN shell.
> >
> > If you forgive me descending into opinion, I think you are approaching this
> > from a point of view that will make Debian, more or less, unhelpful to you.
> > Installing Debian, then putting everything else in place from CPAN (at least
> > system-wide) is going to cause problems in the longer term.
>
> Yes I think you are right. I think I would like a distro that allow me to
> install packages like libpng, libgd and others like these very easy, like
> yum and apt-get do, but also let me install perl modules with cpan because
> no distro's repository would be as well updated as CPAN directly.
>
> The solution seems to be to use Debian and install perl modules using
> local::lib.

*nod*  That, or perhaps investigate something with a ports-alike system,
either on *BSD, or Gentoo, or perhaps some other Linux distro.

> Now, I've started to use a fresh installed Debian and I've installed very
> many CPAN modules using CPAN in the default perl modules location.  What
> would you recommend me to do in this case? Can I just rename/delete the
> files and dirs installed into
>
> /usr/local/share/perl/5.10.0
>
> and install them using local::lib?

If you installed all the modules under /usr/local then you should be pretty
OK; Debian deliberately keep that for local software installation, so no
package will put things there.

You could even keep installing things there if you want; it won't *break*
anything — it just won't give you too much value from the "Debian" part of the
equation either. ;)

At this point I would suggest one of two things:

1. Delete /usr/local/share/perl/5.10.0/* entirely, and use local::lib

2. Just keep using /usr/local to install stuff system-wide, and accept that
   this is potentially going to make the wonderful stuff people say about
   Debian less applicable to your machine.

        Daniel
--
✣ Daniel Pittman            ✉ daniel@...            ☎ [phone]
               ♽ made with 100 percent post-consumer electrons
   Looking for work?  Love Perl?  In Melbourne, Australia?  We are hiring.

_______________________________________________
List: Catalyst@...
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@.../
Dev site: http://dev.catalyst.perl.org/

[Tomas Doran]

On 17 Oct 2009, at 13:38, Octavian Râşniţă wrote:

>
> Can you tell me more about this last step?
>
> I have tried to put in Makefile.PL:
>
> use FindBin;
> use local::lib "$FindBin::Bin/support";
>
> But when I run it, it still tries to write to /var/www which is the  
> home dir of www-data user (the current user).
>
> So I have also tried removing those 2 lines and doing:
>
> $ perl -Mlocal::lib
>
> Then
> $ perl Makefile.PL
>
> But it asked me:
>
> [sudo] password for www-data:

You are doing it wrong.

Just running perl -Mlocal::lib will print out the shell variables  
which you need to set for local::lib to work.

Printing stuff out is not the same as telling your shell about it.

See: http://search.cpan.org/~apeiron/local-lib-1.004008/lib/local/lib.pm#The_bootstrapping_technique

Specifically, you need to say something like:  echo 'eval $(perl -I
$HOME/perl5/lib/perl5 -Mlocal::lib)' >>~/.bashrc

Cheers
t0m


_______________________________________________
List: Catalyst@...
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@.../
Dev site: http://dev.catalyst.perl.org/

[Octavian Râşniţă]

From: "Tomas Doran" <bobtfish@...>

...

> So I have also tried removing those 2 lines and doing:
>
> $ perl -Mlocal::lib
>
> Then
> $ perl Makefile.PL
>
> But it asked me:
>
> [sudo] password for www-data:

> You are doing it wrong.
> Just running perl -Mlocal::lib will print out the shell variables  which
> you need to set for local::lib to work.
> Printing stuff out is not the same as telling your shell about it.

Ok, finally I understood that that command line just prints the commands I
should use, and not executes those commands and just inform me which they
were.

(For the 'intelligent' people like me I think it could be useful if that
command would also print a commented line that tells that the user should
execute those commands, or to add that line to .bashrc that executes them
after login.)

But there is still something that doesn't work. I followed the tutorial on
the Cat wiki and I was able to do everything if I also download and install
local::lib locally (on /home/user/perl5/...), but if I follow J. Shirley's
recommendation to install local::lib using the root account, then to install
the other modules using local::lib, it gives me the following error if I try
to install a perl module:

Cannot create directory /root/.cpan/prefs

All the other steps are the same and the env vars seem to be right:

t2@ebroker:~$ pwd
/home/t2
t2@ebroker:~$  set | egrep "MODULEBUILDRC|PERL5LIB|PERL_MM_OPT|PATH"
MODULEBUILDRC=/home/t2/perl5/.modulebuildrc
PATH=/home/t2/perl5/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
PERL5LIB=/home/t2/perl5/lib/perl5:/home/t2/perl5/lib/perl5/x86_64-linux-gnu-thread-multi
PERL_MM_OPT=INSTALL_BASE=/home/t2/perl5
t2@ebroker:~$ perl -MCPAN -e 'install CGI::Application'
CPAN: Storable loaded ok (v2.21)
Going to read '/home/t2/.cpan/Metadata'
  Database was generated on Sat, 17 Oct 2009 09:27:07 GMT
CPAN: YAML loaded ok (v0.70)
Running install for module 'CGI::Application'
Cannot create directory /root/.cpan/prefs

Is it really possible to install locally perl modules using the module
local::lib if this module is installed in the default location by root?

Thank you.

Octavian


_______________________________________________
List: Catalyst@...
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@.../
Dev site: http://dev.catalyst.perl.org/

[Andrew Rodland]

On Saturday 17 October 2009 03:20:49 pm Octavian Râşniţă wrote:
> Is it really possible to install locally perl modules using the module
> local::lib if this module is installed in the default location by root?
>
Yes, you just need to not have a CPAN config that has /root/.cpan has a
"cpan_home". If you have a ~/.cpan/CPAN/MyConfig.pm then edit that file (using
a text editor or CPAN.pm) and fix the cpan_home, build_dir, hist_file, and
keep_source_where options so that they point somewhere you can actually write
to. If you don't (if the CPAN/Config.pm in effect is global), then just cp it
into your local PERL5LIB and then edit it as such.

Andrew

_______________________________________________
List: Catalyst@...
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@.../
Dev site: http://dev.catalyst.perl.org/

[Evan Carroll-3]

I just wanted to buzz in and be slightly more explicit. Debian doesn't
understand Perl, and they don't care about CPAN. Debian hand-hacks
stuff in the most virulent and ridiculous fashion: they'll open up a
perl class, hack in an extra method, make random other methods die
explicitly, and then they'll make your system dependent on it. I use
CPAN too, and Debian as my primary distribution but that doesn't
change a thing. They could for instance, subclass a module for use by
the system into a ::Debian package, but instead they choose the dirty
hack-it-in method which makes life difficult for those of us who want
to simply get a job done. The Debian packages don't have to pass the
natural tests, they're not published under the same namespaces, they
don't change version numbers, and they're hardly sound improvements.

Debian will justify this because they want the system configured
through /etc, and not at the whim of each individual author, but
unfortunately that doesn't help us here, or people that depend on the
non-debian behavoir.

Use CPAN at your risk, it might work -- it might not. I do, and I feel
comfortable saying most programmers on this list can probably navigate
around the problems Debian creates, but for the end perl user, Debian
is a horrible platform.

--
Evan Carroll
System Lord of the Internets

_______________________________________________
List: Catalyst@...
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@.../
Dev site: http://dev.catalyst.perl.org/

[J. Shirley]

On Mon, Oct 26, 2009 at 2:08 PM, Evan Carroll <lists@...> wrote:

I just wanted to buzz in and be slightly more explicit. Debian doesn't
understand Perl, and they don't care about CPAN. Debian hand-hacks
stuff in the most virulent and ridiculous fashion: they'll open up a
perl class, hack in an extra method, make random other methods die
explicitly, and then they'll make your system dependent on it. I use
CPAN too, and Debian as my primary distribution but that doesn't
change a thing. They could for instance, subclass a module for use by
the system into a ::Debian package, but instead they choose the dirty
hack-it-in method which makes life difficult for those of us who want
to simply get a job done. The Debian packages don't have to pass the
natural tests, they're not published under the same namespaces, they
don't change version numbers, and they're hardly sound improvements.

Debian will justify this because they want the system configured
through /etc, and not at the whim of each individual author, but
unfortunately that doesn't help us here, or people that depend on the
non-debian behavoir.

Use CPAN at your risk, it might work -- it might not. I do, and I feel
comfortable saying most programmers on this list can probably navigate
around the problems Debian creates, but for the end perl user, Debian
is a horrible platform.

The difference between a troll and a critique?

Citations and references.
 

_______________________________________________
List: Catalyst@...
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@.../
Dev site: http://dev.catalyst.perl.org/