Re^2: Top Seven (Bad) Reasons Not To Use Modules

in reply to Re: Top Seven (Bad) Reasons Not To Use Modules
in thread Top Seven (Bad) Reasons Not To Use Modules

Some systems like Debian have some strong conventions for how the integrate Perl into the larger operating system. Setting up and getting CPAN working smoothly on those systems is non-trivial.

Quite the contrary. The cpan shell works out-of-the-box on Debian systems, and doesn't conflict with the package manager at all.

And not only does Debian come with lots of perl modules as .deb packages, it also allows fairly easy generation of .deb packages from CPAN and custom perl modules via dh-make-perl or cpan2dist (distributed with CPANPLUS and thus with newer perl version in core).

And there's nothing easier in Debian than installing a .deb module (especially if you set up a mirror on your own and put them up there).

So if you want to solve the deployment problem on Debian based Linux distributions, you can get a clean solution pretty fast.

(I guess the same holds true for many other distributions, but I just talk about Debian because I'm familiar with it).

Comment on Re^2: Top Seven (Bad) Reasons Not To Use Modules

Replies are listed 'Best First'.
Re^3: Top Seven (Bad) Reasons Not To Use Modules by ELISHEVA (Prior) on Mar 13, 2009 at 08:56 UTC
Installing debs with apt-get is easy-peasy and very reliable on any Debian system. No doubt. But as for CPAN, ease depends in part on how one has set up Debian. A C compiler and make isn't a given on Debian, for instance, and many CPAN builds will fail without one. Nor are various networking and system tools a given: ssh clients, sudo, and many others need to be explicitly downloaded if you do a minimal install. Debian has a huge variety of download options - from a minimal 40MB install to a 650MB CD image. I haven't noticed problems with CPAN and apt-get/dpkg conflicting. However, that doesn't mean that there aren't conflicts with CPAN build scripts and Debian itself. Debian uses Perl as part of its own system core. It has a rather complicated policy to keep modules needed by the system separate from site installed modules and to prevent version conflicts between site and system versions. (see Debian Perl Policy). There is a reason why Debian spends so much time testing stuff for integration issues. Debian also sometimes has special versions of binaries that hard code Debian system locations. As a result, in general, I have found the .deb's retrieved by apt-get more reliable than CPAN - but they also tend to be several versions old and not everything on CPAN has a well tested .deb There are also different tolerance levels for sysadmin problems and complications depending on whether nix is running on a server managed by a professional system administrator or on the desktop machines of developers. Developers may know their programming language and design tools well but sometimes have only sketchy ideas of sysadmin issues, even when its their own development tools that are being installed by a deployment system. I rather doubt most monks fall in this category, but I've brought in team members for Java work who think I have horns when I tell them they must* learn basic command line skills. Best, beth	[reply]

Replies are listed 'Best First'.

Re^3: Top Seven (Bad) Reasons Not To Use Modules
by ELISHEVA (Prior) on Mar 13, 2009 at 08:56 UTC

Installing debs with apt-get is easy-peasy and very reliable on any Debian system. No doubt.

But as for CPAN, ease depends in part on how one has set up Debian. A C compiler and make isn't a given on Debian, for instance, and many CPAN builds will fail without one. Nor are various networking and system tools a given: ssh clients, sudo, and many others need to be explicitly downloaded if you do a minimal install. Debian has a huge variety of download options - from a minimal 40MB install to a 650MB CD image.

I haven't noticed problems with CPAN and apt-get/dpkg conflicting. However, that doesn't mean that there aren't conflicts with CPAN build scripts and Debian itself. Debian uses Perl as part of its own system core. It has a rather complicated policy to keep modules needed by the system separate from site installed modules and to prevent version conflicts between site and system versions. (see Debian Perl Policy). There is a reason why Debian spends so much time testing stuff for integration issues. Debian also sometimes has special versions of binaries that hard code Debian system locations. As a result, in general, I have found the .deb's retrieved by apt-get more reliable than CPAN - but they also tend to be several versions old and not everything on CPAN has a well tested .deb

There are also different tolerance levels for sysadmin problems and complications depending on whether *nix is running on a server managed by a professional system administrator or on the desktop machines of developers. Developers may know their programming language and design tools well but sometimes have only sketchy ideas of sysadmin issues, even when its their own development tools that are being installed by a deployment system. I rather doubt most monks fall in this category, but I've brought in team members for Java work who think I have horns when I tell them they *must* learn basic command line skills.

Best, beth

[reply]

In Section Meditations