LinuxQuestions.org
Review your favorite Linux distribution.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 05-11-2017, 07:38 PM   #1
xj25vm
Member
 
Registered: Jun 2008
Posts: 360

Rep: Reputation: 35
Slackware Perl compiled with /usr/local paths


Does anybody know why Perl is compiled with a bunch of /usr/local paths in its options? It seems most unusual, as no other Slackware package seems to make use of /usr/local. It is also a bit of a nuisance, as Perl will then put its modules under /usr/local. Or maybe there is a good reason for all this?
 
Old 05-11-2017, 09:44 PM   #2
Ztcoracat
LQ Guru
 
Registered: Dec 2011
Distribution: Slackware, MX 18
Posts: 9,467
Blog Entries: 15

Rep: Reputation: 1158Reputation: 1158Reputation: 1158Reputation: 1158Reputation: 1158Reputation: 1158Reputation: 1158Reputation: 1158Reputation: 1158
No clue why that happened but this thread might explain some things about the modules and why they installed to usr/lib.

http://www.linuxquestions.org/questi...ckware-675910/

I looked on my system and all modules were in /var/lib/sbopkg.
I also looked in /usr/local/lib64/perl5/ but the directory was empty.

This might help too:-
http://alvinalexander.com/perl/edu/articles/pl010015
 
Old 05-12-2017, 12:07 AM   #3
ponce
Senior Member
 
Registered: Aug 2004
Location: Pisa, Italy
Distribution: Slackware
Posts: 4,792

Rep: Reputation: Disabled
Quote:
Originally Posted by xj25vm View Post
Does anybody know why Perl is compiled with a bunch of /usr/local paths in its options? It seems most unusual, as no other Slackware package seems to make use of /usr/local. It is also a bit of a nuisance, as Perl will then put its modules under /usr/local. Or maybe there is a good reason for all this?
I suppose that is to try to separate what you install via CPAN or manually from what you install via package, avoiding to have files untracked by the package manager in /usr.

if you prefer to have untracked perl modules in /usr you should be able to force PREFIX=/usr (like when packaging perl modules) when you setup CPAN, passing it when it asks for any additional <makepl_arg>, but as we have seen not so many time ago with some perl version updates, in general it's not a good idea as you can find yourself in the need of removing every module installed via CPAN and rebuild them.

EDIT: I seemed to recall we talked about this not so much time ago...

Last edited by ponce; 05-12-2017 at 01:51 AM.
 
Old 05-12-2017, 02:06 AM   #4
xj25vm
Member
 
Registered: Jun 2008
Posts: 360

Original Poster
Rep: Reputation: 35
Hi ponce. Yes - you are right - I started the other thread. I thought I only asked about cpan, not Perl itself - but now looking at the thread, I did raise the issue of the Perl compilation options as well. I understand the intended goal - the separation of modules from SBo and the ones installed from CPAN directly - but somehow having only one package on the system using /usr/local, which is not used by any other package in Slackware as a standard path, seems like a hack to me. Isn't there a more elegant and logical solution - maybe compiling perl with the "sitescripts" option for /usr/lib64/perl5/cpan or something like that? I looked on an older machine and I think the path used to be something like /usr/lib/perl5/site_scripts.
 
Old 05-12-2017, 04:08 AM   #5
orbea
Senior Member
 
Registered: Feb 2015
Distribution: Slackware64-current
Posts: 1,639

Rep: Reputation: Disabled
Well, if you want a "non-hacky" solution install that one perl module with a slackbuild instead of cpan. Having modules installed by cpan in /usr/local seems like the correct behavior to me.
 
Old 05-12-2017, 04:31 AM   #6
xj25vm
Member
 
Registered: Jun 2008
Posts: 360

Original Poster
Rep: Reputation: 35
Well - in the end I did go down the SBo route - but that is not problem free. Every time I install Spamassassin from SBo, something doesn't work. On one machine I had to force install Image::Info with cpan as the SBo script kept on failing, on another machine it was Encode::Detect which refused to install from SBo. Honestly, Spamassassin is the worst software (installation-wise) I am dealing with, by far. I must have installed it 20-30 times so far, and it's never been a smooth process. And this was after removing Perl, and removing by hand all locations where Perl modules are - to start with a clean slate - on Slackware -current. And because of the above, I always end up with at least a few modules installed through cpan.
 
Old 05-12-2017, 05:12 AM   #7
ponce
Senior Member
 
Registered: Aug 2004
Location: Pisa, Italy
Distribution: Slackware
Posts: 4,792

Rep: Reputation: Disabled
I think the main issue here is that you assume SBo scripts have to work on current exactly as they work on stable: they could but they also could not.
In the specific case of perl they often don't work painlessly if the underlying core version changes.
They are tested on stable and they should work on that platform: if they don't reporting the issue for the specific SlackBuild to its maintainer can help fix it for everybody.
IMHO, if they don't work on current, it's still worth to fix the specific SlackBuild issue (in the dedicated topic here, if the maintainer can't solve it himself) than installing untracked files in the system.
 
Old 05-12-2017, 06:02 AM   #8
arahmadi
LQ Newbie
 
Registered: May 2017
Location: Samarinda, ID
Distribution: Slackware
Posts: 16

Rep: Reputation: Disabled
Personally, installing complicated software like SpamAssassin on -current is not a wise idea. I've been there once. It is better to use stable branch.
Second, installation wise for SpamAssassin, CPAN is the way to go. Simply, there are too much packages to maintain. Maintaining false positive behaviors of Postfix UCE, SpamAssassin, and RBLs themselves are proven to be a challenge. At least that is what I usually do. In addition to that, using SBo to install is hectic. [A little background: I, voluntarily, maintain at least 5 servers, two of them are mail servers, while I am not a fully fledged sysadmin, rather a researcher in agricultural faculty].

SBo works great with Stable, [if] the designed version is in use. I.e. SBo for a program-3.1.4 sometime needs a small fine tune with program-3.2.0 version. As you said with the case of SpamAssassin, to maintain SBo installation compatibility for ~30 modules is quite a work.
 
Old 05-12-2017, 11:33 AM   #9
xj25vm
Member
 
Registered: Jun 2008
Posts: 360

Original Poster
Rep: Reputation: 35
Well, most of the thoughts above make sense in their own way. But given that Slackware releases are now a few years apart (not complaining, just saying), and the fact that most of my servers run all sorts of other software and services, sooner or later I have to give in and upgrade them to -current in order to get one thing or another working. Of course reporting packages which don't compile to SBo is a good idea - and I try to do it as often as I can. But SBo (I believe) tracks the last stable release - so keeping a Slackware server fairly up to date while at the same time using SBo - specially for a messy software such as Spamassassin, with so many little dependencies, is, well, quite a challenge. Frankly I prefer to (and use to) have servers staying on the same versions of software for as long as possible - but I'm afraid software such as Clamav and Spamassassin need to be updated frequently, by the very nature of their purpose.

Last edited by xj25vm; 05-12-2017 at 01:35 PM.
 
1 members found this post helpful.
Old 05-12-2017, 02:36 PM   #10
bassmadrigal
LQ Guru
 
Registered: Nov 2003
Location: West Jordan, UT, USA
Distribution: Slackware
Posts: 6,022

Rep: Reputation: 3687Reputation: 3687Reputation: 3687Reputation: 3687Reputation: 3687Reputation: 3687Reputation: 3687Reputation: 3687Reputation: 3687Reputation: 3687Reputation: 3687
Quote:
Originally Posted by xj25vm View Post
But given that Slackware releases are now a few years apart (not complaining, just saying)
So far, 14.2 is the only release that has spanned more than two years between the previous release. Prior to that, there was at least one release per year with the longest gap being between 13.37 and 14.0 at 1 year 5 months (27 APR 2011 and 28 SEP 2012 respectively).

Unfortunately, we don't know if 14.2's development process was a unique case or will be the way future releases are planned until it's either announced or a new release is... well, released.
 
Old 05-12-2017, 03:15 PM   #11
arahmadi
LQ Newbie
 
Registered: May 2017
Location: Samarinda, ID
Distribution: Slackware
Posts: 16

Rep: Reputation: Disabled
Quote:
Originally Posted by xj25vm View Post
Well, most of the thoughts above make sense in their own way. But given that Slackware releases are now a few years apart (not complaining, just saying), and the fact that most of my servers run all sorts of other software and services, sooner or later I have to give in and upgrade them to -current in order to get one thing or another working. Of course reporting packages which don't compile to SBo is a good idea - and I try to do it as often as I can. But SBo (I believe) tracks the last stable release - so keeping a Slackware server fairly up to date while at the same time using SBo - specially for a messy software such as Spamassassin, with so many little dependencies, is, well, quite a challenge. Frankly I prefer to (and use to) have servers staying on the same versions of software for as long as possible - but I'm afraid software such as Clamav and Spamassassin need to be updated frequently, by the very nature of their purpose.
I am a conservative (other said: obsolete ) when it comes to a production server. Even for a stable like 14.2, we review it for at least a year or two, before installing it as a server OS. For most of our systems, we now run 13.37 after 12.1, and prior to that 10.1. We skip 14.0 and 14.1. The 14.2 is a candidate for our production servers. Our mailing system,in this case, handles > 3000 active accounts.

Clamav does need update at least once a week for the rules, but not that often for the engine.
We fine tune the SpamAssassin rules to suite with our client behaviors by statistically analyzing logs with a bunch of tools (i.e. pflogsum), hence sometime we dont update that often.
We stick to any program version, unless there is security update.
 
1 members found this post helpful.
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Change shipped Perl package compile options to use /usr, not /usr/local xj25vm Slackware 7 02-03-2017 06:42 AM
/usr vs /usr/local (& /opt) when describing non system software (debate welcomed) Alpha90 Linux - Software 2 07-07-2012 03:22 AM
/usr/local/lib or /usr/local/lib64 rigelan Slackware 9 07-24-2009 06:32 PM
local versus /usr/bin why, howto (Perl) acummings Linux - Software 6 03-02-2005 01:14 AM
Installing software, /usr/lib directory and /usr/local millertime Linux - Software 2 07-10-2004 09:21 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 02:30 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration