Re: Funny Little Permissions Issue on Ubuntu

[BJ_Covert_Action]

I am using the bash shell so it should be sourcing /etc/profile so far as I know. No, I do not see /root/perl in @INC whether I run as root or as my own account (even after fiddling with PERLLIB).

I am the only user on my system (nobody else accesses my computer), but I install modules as root typically because if I don't enter the CPAN shell as root, the installs fail due to permission restrictions (for some reason my unzipped packages that are downloaded with get end up locked to my user account about half the time.

I have been using the system perl that came with ubuntu because I figured that it was adequate and easy enough to interface (oddly enough I am finding it easier to interface with my strawberry distribution at work on Windows). I would be interested in installing and configuring my own perl distribution in another folder, except then I would be worried about perl version conflicts and what not (I don't know what kind of complications come with having two different perl builds on one machine, if someone could point me to some info on this it might be my best option).

Installing modules via synaptic is not a terrible idea either, I didn't realize modules were apt-getable because they are named with the lib prefix. Does anyone know if synaptic provides access to all CPAN modules, or just certain ones?

I think I might try reconfiguring CPAN in the manner przemo mentioned above when I get home. If that works I will probably keep working in the local directory (which is where I would like to work, but CPAN somehow got configured to install in /root/perl instead. przemo, I do have a question, when you say, "set the following options in the CPAN, is that code I should be adding/tweaking in CPAN.pm, or is there some other configuration file/setting I need to mess with? I wasn't aware of the 'o config init' command (which they just happen to leave out of the help option inside the shell), so I will see where that takes me after work today and keep you all posted.

Thank you all for the suggestions so far.

[almut]

...except then I would be worried about perl version conflicts and what not

When you adhere to a few basic rules, there are no conflicts to be expected.

Essentially, those rules are:

• Always take care to call the perl binary belonging to the version you want to use. I.e. put #!/usr/local/bin/perl in your shebang line if you want to use your own (non-system) Perl and that's the location where you've installed it to.  Similarly, if you want to get that same version when you type perl on the command line (without path), make sure it's found first along your PATH.  (If you want to use another version, you can always type the absolute path, e.g. /usr/bin/perl to get the system Perl.)

• Don't mess with PERL5LIB on a global level (like in /etc/profile, or some such).  If you really need to fiddle with it, do it locally, i.e. in a specific shell environment, via a wrapper, or by prefixing a command line like so: PERL5LIB=/whatever/dir your-command-here

Every perl binary by default 'knows' where its modules are located (when once correctly set up), so it will find existing modules in, or install new modules to exactly those locations.

Personally, I have at least 2 to 3 Perl versions on all my machines, and I've never had any conflicts due to this. Quite the contrary, certainly less potential conflicts than when messing with the Perl that comes with the system...  The only downside is that you sometimes have to install the same modules several times.

As to using only the pre-built deb packages provided by the distro together with the system Perl, I'd say that's in principle fine, as long as you don't always want the latest and greatest. Virtually all commonly used modules are available, but not always in the most recent version...  OTOH, that's the easiest way, because nothing needs to be built, which is particularly nice with modules that aren't trivial to build, as for example when they depend on various C libs which itself depend on other libs that must be the correct versions, etc.

[przemo]

No, I do not see /root/perl in @INC whether I run as root or as my own account (even after fiddling with PERLLIB).

Do you mean that the following two commands give the same results in respect to @INC? They shouldn't.

$ PERL5LIB= perl -V
$ PERL5LIB=/home/me/perl/lib/perl5 perl -V

when you say, "set the following options in the CPAN", is that code I should be adding/tweaking in CPAN.pm, or is there some other configuration file/setting I need to mess with?

Those were the commands to put at CPAN's shell prompt. I forgot to mention that you should issue o conf commit after that, but cpan should inform you about that.

Alternatively, you can modify settings directly in ~/.cpan/CPAN/MyConfig.pm. It's safe as long as you just play with it as a casual user. This is a big plus in this approach: when experimenting with local installation dir, if you break something, just remove destination folder (~/perl in my example) and ~/.cpan and you have clean environment. You loose all your settings, but hey, this is how experimenting works. :)

Good luck!

[BJ_Covert_Action]

Well I managed to get the issue ironed out by adding some lines into the MyConfig.pm. I gleaned the syntax from reading what was already there and using the variables you mentioned setting inside the CPAN shell. I would post more details but I am not on the same machine right now for reference.

I think I might try working with a second perl distribution when I get around to it as well, it would be good to learn how to do that.

Thanks for the help so far, I will try to post details of what I changed later in case any other users want to look at this thread for help/reference.

Cheers.

P.S. Regarding the @INC output, I will address that when I get home, I haven't run both of those commands to know.