I am not 100% sure about this, but it seems that CPAN generates its own settings on first run based on paths compiled into Perl. On Slackware, the default Perl package lists the following paths:

As a result of the above, CPAN installs its modules in /usr/local/share/perl5 (and some other locations under /usr/local).

As all other software in Slackware appears to be using the /usr and not /usr/local path, would it be possible to compile the default shipped Perl package with appropriate arguments so that the /usr/local paths don't appear in its @INC statements? Hopefully, this will also convince CPAN to install modules by default under /usr, not /usr/share.

At the moment I have to modify manually /root/.cpan/CPAN/MyConfig.pm (after first CPAN run) and amend the following:

IMHO, is not a good idea to let CPAN install untracked files into /usr that should be left to files handled by pkgtools...

if someone needs CPAN badly, an option should be to use cpan2tgz.

@ponce Is there a particular reasoning behind advising against the use of CPAN? Using the settings I suggested above, CPAN installs its modules in /usr/share/perl5 - all in one place. Is there something particularly wrong or dangerous about using CPAN? I confess to not knowing a much about Perl or CPAN beyond installation and configuration of stuff.

CPAN doesn't track whatever is installed so if you have to upgrade, remove or whatever the stuff you installed using that you usually get into deep s**t (sorry for my french).

issues related to the use of CPAN have been reported a lot lately because, to make things worse, perl devs made slackware-14.2's perl binary incompatible with slackware-14.1's perl, so whoever had used CPAN to install perl modules in 14.1, after upgrading to 14.2, got a segfaulting perl interpreter: as the only way to fix these segfaults would have been cleaning every third party module and rebuilding them from CPAN, not having the possibility to track stuff had obviously became a PITA for people needing to upgrade.

that's the reason why it's recommended to use packages to install perl modules.

if you let CPAN install stuff in /usr instead of /usr/local, mixing this way modules and files installed via packages with others installed via CPAN, tracking things surely will become even a scarier nightmare.

1 members found this post helpful.

Well, first of all, although the path which goes in the CPAN config (which I suggested in my first post) is /usr, the CPAN stuff doesn't actually go directly into /usr. This is only used as the base to generate the install path, which, as I mentioned above, seems to be /usr/share/perl5 - which means they don't mix with files from other software or packages.

As to the second problem of Perl incompatibility between Slack 14.1 and 14.2, I got that on a number of machines as well. However, I simply deleted all CPAN modules (which at the time on these machines were in the default /usr/local/...) - and re-installed all modules through CPAN. I'm not sure how this is such a major PITA. I would say having to download, build and install separately about 20 Perl modules from slackbuilds (required in my case by Spamassassin), instead of using CPAN commands directly (which can also be told to install dependencies, incidentally) was a much bigger PITA.

I use the Slackware package manager for everything else, but frankly, in the case of Perl modules, I'm not sure I can see the point, when CPAN was designed specifically for that. On the other hand, everybody has different preferences, and if the "official" or "semi-official" line on Slackware is to discourage the use of CPAN, that is equally fine with me :-)

Edit: Also, according to the docs, "cpan -l" will list all the modules it has installed.

perl, git, linuxdoc-tools, samba and whatever you install from SBo, for example, install things in /usr/share/perl5.
binaries from perl modules are installed in $PREFIX/bin.

it depends on what you install: I seem to remember that some things (sorry if I don't recall which ones ATM), despite the CPAN default path being /usr/local, still install in /usr.
but if you install them in /usr by default surely you cannot easily remove them like you do when they're installed in /usr/local: also, if you install other stuff in /usr/local it will mix, for example, with perl binaries, making it difficult to discern them if removing is needed.
instead, installing spamassassin via sbopkg or something else is pretty easy (dependencies are handled) and removing or upgrading packages is absolutely painless.

let me state again, if needed, that my opinions are my own, they're not "official" or "semi-official"
if you look for "perl segfault" in this forum you can find some of the report I cited and you can see that, if you don't know very well what you're doing (if you know it you should be fine), installing from CPAN can mess very bad with your system.
but, in the end, everybody is free to do whatever he prefers with his own installation

that will list every module installed, via CPAN or via package.
also consider that CPAN, during its installation of stuff, can also upgrade perl core modules or things that you have installed via packages, potentially mixing/breaking things.

if you want to handle things via CPAN maybe the cleaner way should be to:
- remove the Slackware perl package;
- install your perl interpreter from source;
- rebuild the packages cited above provided with Slackware and whatever you installed from third party repos (SBo, etc.) that contains perl modules over this new perl;
- install whatever you want via CPAN.

You can track perl installations with CPAN using slacktrack from the 'd' package series.
Check its documents for examples.

2 members found this post helpful.

Thanks drmozes.

I didn't know about slacktrack.

Lots to learn and it looks interesting ...

I've scanned, not really read all the documentation.

Do you have any additional advice about slacktrack and production machines ?

Thanks !

-- kjh