dh-make-perl --cpan Your::Module --build --install

It makes .debs for simple packages easy, and for the hard ones, well, possible :-)

What benefits does this give over just installing thru the CPAN shell?

What benefits does this give over just installing thru the CPAN shell?

Debian's package management system is, in a word, beautiful. I have a cron job run every night to pull over the list of the latest packages. Then, when I want to make sure that my system is up to date, I run 'apt-get upgrade', and all packages that have a newer version out there get upgraded. I'm not sure that I'd want this in an enterprise environment, but for me personally, it's a Good Thing. Also, with apt, you can have programs that use perl modules have apt dependencies for them.

thor

Feel the white light, the light within
Be your own disciple, fan the sparks of will
For all of us waiting, your kingdom will come

A big advantage of doing it this way is you can create a standard install to roll out across multiple servers, all with the same versions of CPAN modules.

The packages on the debian archive are usually out of date but with this tool (which I didn't actually know about until now), managing production enviroments becomes so much easier.

In addition to the other replies: Once you make this .deb, you can install (and uninstall!) it on machines even if they are not connected to the internet or if they don't have a compiler installed. (In production environments, this is often the case.)

Perl has been removed from the base system, and should be installed either from a pre-built package or from the Ports Collection. Building Perl as a part of the base system created a number of difficulties which made updates problematic. The base system utilities that used Perl have either been rewritten (if still applicable) or discarded (if obsolete). sysinstall(8) will now install the Perl package as a part of most distribution sets, so most users will not notice this change.

Mac OSX just comes with perl. It does get upgraded through software update. It comes with a few scripting languages by default. tcsh, python and ruby (aside from perl).

Just a note about Perl on Mac OS X.

Apple does not update the Perl distribution during the lifecycle of a given major version of the system. For example, under Jaguar 10.2.6 it was the same Perl 5.6.0 that it was under 10.2.0 (which was used since 10.0). Similarly, under Panther (10.3.x) it's Perl 5.8.1 RC3.

The source of the Perl Apple include in Mac OS X can be found on their opensource site.

1. AS does packaging of Perl (and Tcl, for one I know) much in more regular basis than earlier. It was 2 years between consequent releases 561 and 580, but now they released 584 and 586 versions quite soon after official release.
2. Linux installation of AS perl has quite similar logic as on Win32, but they provide both RPM and TGZ versions
3. cygwin... those are quite recent versions, I have it installed but don't know many. However interesting to note, perlTk could be built with X, and this is quite interesting to see...
4. personally, recently I was pleased by RedHat binaries of Perl because they provided PPC linux binaries, which I was not able to cross-compile, but now, thank to them, I have GCC (to compiler newer perls) and recent perl (they also provide 586) on my PPC linux.
   so please consider their binaries as good quality ones.
   my PPC linux, BTW, is satellite receiver, I am very happy for it to run perl :):)
5. WinCE binaries are available at SF site http://perlce.sf.net but those binaries are far from perfect, unfortunately. I even think WinCE port needs some kind of rework, but this is true for many WinCE ports (including tcl)

My other distro, SuSE, has rpms of several modules, but doesnt keep them uptodate (new versions in new distro releases, but not inbetween, as far as Ive noticed).. I produce my own new RPMs of actual perl versions, and install modules by hand or with CPANPLUS on there.

C.

"ActiveState on Win32" made "the installation location independent, that is, you can install it anywhere on your hard disk."

Not quite. PPM (among others?) will fail unless you fix the paths in Config.pm. At least, that's the case for ActivePerl 5.6.1 (build 633, IIRC)

Update: Oops, misread, yes, it can be installed anywhere. You can even move it after it's been installed if you update the paths in Config.pm (simple search and replace), and you fix the .pl file association (if you have one).

The Mandrake distro is divided in 2 "media". The main media is supported by MandrakeSoft; contrib is not. Additionally, there is update that contains security update. Finally, there is plf, that contains rpms packaged by the Penguin liberation Front. These packages have a dubious or incompatible legal status that makes them ineligible for distribution by Mandrakesoft.

The core of Perl is split in 4 rpms: perl-base, perl-doc, perl, perl-devel. The perl-base rpm contains a minimum perl distro useful in the boot process where the whole Perl would be too big. The perl rpm is the rest of core perl minus perl-doc, that contains the doc and perl-devel that contains the C headers.

Rafael is the packager of Perl and of 119 Perl modules as testified by: rpmmon -q rgarciasuarez@mandrakesoft.com | grep perl- | wc -l
Other Perl modules are packaged by other people. The policy is to update immediately the update media when there is a security update for a perl module. Also, cooker, the experimental distro is fairly up to date. I am using cooker and does urpmi.update -a; urpmi --auto-select to keep my host up to date and I regularly see Perl related updates in the logs.

There is a lot of stuff that is proper to Mandrake but can be of a larger interest. For example the MDK::Common package contained in the rpm perl-MDK-common. The urpmi command is a Perl script that is updated by rgs almost daily (but this is relevant only for people under cooker).

Also, in the next major release MandrakeSoft will probably distribute the non threaded version of Perl as default. The rational is that threaded Perl is slow and buggy.