Modify @INC in Perl (or which perl5 folder should I use?)

[Cyberwizzard]

Hi,

I've got zero experience with Perl and I am trying to get a piece of software to work on Gentoo. They place scripts in a /usr/share/perl5 folder to be globally included. I didn't have this folder but I figured dumping stuff somewhere in /usr/lib64/perl5/5.8.8/<something> was not the way to go.

How can I modify the @INC for Perl so it scans /usr/share/perl5 for the modules?

Or if this proves difficult, in which folder should 3rd party modules be put?

[Kulfaangaren!]

THIS (perl.org) is what you need

[Cyberwizzard]

It seems the site you linked is meant to modify the path in the scripts itself. However, I didn't write those and there are a lot of them so I opted to put the scripts in the existing @INC paths.

Which brings me to my new problem: is /usr/lib64/perl5/site_perl a suitable location for 3rd party apps?

[Kulfaangaren!]

Hi again.

Ok, I think I understand your question now. You want to know if the perl binary can be modified to look for modules/add-ons in /usr/share/perl5 and the answer is Yes, but only at compile time.
To accomplish this within the emerge/portage, you would have to patch the .ebuild file of the perl version of your choice. Below is a patch that I created using perl-5.8.8-r5.ebuild that should allow for placement of modules in /usr/share/perl5. If you need to add other directories I think you should add them colon separated with no spaces to the patch as ...

Code: Select all

+               -Dotherlibdirs=/usr/share/perl5:/usr/share/perl5/special_modules \

The patch looks like ...

Code: Select all

--- perl-5.8.8-r5.ebuild        2009-09-23 12:06:31.657914897 +0200
+++ perl-5.8.8-r5-localfix.ebuild       2009-09-23 12:08:51.902915361 +0200
@@ -280,6 +280,7 @@
                -Dman3dir=/usr/share/man/man3 \
                -Dinstallman1dir=/usr/share/man/man1 \
                -Dinstallman3dir=/usr/share/man/man3 \
+               -Dotherlibdirs=/usr/share/perl5 \
                -Dman1ext='1' \
                -Dman3ext='3pm' \
                -Dinc_version_list="$inclist" \

It is not a good idea to patch the original .ebuilds so I would suggest setting up a local overlay. I have one set up in /usr/local/portage called local.
Since I use layman to access remote overlays (like kde-testing) I have emerged layman and configured it as per instructions in the Gentoo documentation page for overlays and then added my own overlay under /usr/local/portage/local.
To accomplish this I added ...

Code: Select all

# Local overlay
PORTDIR_OVERLAY="${PORTDIR_OVERLAY} /usr/local/portage/local"

... to the end of my /etc/make.conf and created a few directories and files.
This is how my local overlay looks ...

Code: Select all

root@machine ~># tree /usr/local/portage/local/
/usr/local/portage/local/
|-- media-gfx
|   `-- gimp
|       |-- Manifest
|       |-- files
|       |   `-- gimp-2.6.6-to-2.7.0.diff
|       `-- gimp-2.7.0.ebuild
`-- profiles
    `-- repo_name

4 directories, 4 files

As you can see I have created a local ebuild for gimp-2.7.0 which was not available in portage, but that is not important for you so you should concentrate on the profiles/ directory and the repo_name file. Both the file and the directory needs to exist and the file is just a simple text file containing the name of the overlay (in this case 'local') on it's first and only line.
To set up your local overlay do ...

Code: Select all

root@machine ~># mkdir -p /usr/local/portage/local/profiles
root@machine ~># echo "local" > /usr/local/portage/local/profiles/repo_name
root@machine ~># mkdir -p /usr/local/portage/local/dev-lang/perl/files
root@machine ~># cp ~/patchfile /usr/local/portage/local/dev-lang/perl/files/perl-5.8.8-r5-localfix.patch
root@machine ~># cp /usr/portage/dev-lang/perl/perl-5.8.8-r5.ebuild /usr/local/portage/local/dev-lang/perl/
root@machine ~># cp /usr/portage/dev-lang/perl/files/* /usr/local/portage/local/dev-lang/perl/files/.
root@machine ~># cd /usr/local/portage/local/dev-lang/perl
root@machine /usr/local/portage/local/dev-lang/perl/># patch -p0 < ./files/perl-5.8.8-r5-localfix.patch
root@machine /usr/local/portage/local/dev-lang/perl/># ebuild perl-5.8.8-r5.ebuild digest

If you now do the follwing, you will see that your local ebuild will override the portage one (look at the "...[0=>1]" part of the below emerge info) ...

Code: Select all

root@machine ~># emerge -pv perl

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R   ] dev-lang/perl-5.8.8-r5  USE="berkdb gdbm ithreads -build -debug -doc -perlsuid" 0 kB [0=>1]

Total: 1 package (1 reinstall), Size of downloads: 0 kB
Portage tree and overlays:
 [0] /usr/portage
 [1] /usr/local/portage/local

I have tested to emerge the changed .ebuild and the configuration phase adds /usr/share/perl5 to the directories scanned for modules.
The information from my perl build now shows this ...

Code: Select all

root@machine ~># perl -V
... 8< Snipp! Snipp! Removed spam! >8 ...

  Built under linux
  Compiled at Sep 23 2009 13:23:52
  @INC:
    /etc/perl
    /usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi
    /usr/lib64/perl5/vendor_perl/5.8.8
    /usr/lib64/perl5/vendor_perl
    /usr/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi
    /usr/lib64/perl5/site_perl/5.8.8
    /usr/lib64/perl5/site_perl
    /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi
    /usr/lib64/perl5/5.8.8
    /usr/local/lib/site_perl
    /usr/share/perl5
    .

The above method off course requires you to patch each and every perl release that you want to upgrade to since perl is a part of the base system. You best bet is probably to mask all perl releases above 5.8.8-r5 (or which ever version you end up using) to prevent a 'emerge -u world' from updating to an unpatched version of perl.

I hope this solves your problem.

// Fredrik

[Cyberwizzard]

Hi Fredrik,

Thanks for your reply, I got another problem with Perl which I can solve with this as its an embedded system which won't get updates that often and I can use that fix there.

But I am using this stuff for a guide on the wiki and I don't fancy telling people to patch their ebuild and set up a local overlay for just one program

I currently used /usr/lib64/perl5/site_perl as an alternative location to install the program in. Is this suitable for 3rd party programs? I mean it works by now but it feel wrong to use distro directories for 3rd party applications...