Re: Most maintainable way to install perl modules on Debian sysetms
Hi Michael,
On Sun, Nov 15, 2020 at 08:50:57PM +0000, Michael Grant wrote:
> I try to keep my systems as up to date as possible. I use apt update regularly. When I can install a perl module from apt, I usually do so because then apt update picks up new versions of it. When I install something which has a dependency on a perl module in apt, that module gets installed. Things just work and I am unstressed and happy.
>
> However, what should I do if I need a perl module that someone hasn’t kindly created a package for? I know I can install it from cpan. But once I do that, then I have to keep that module up to date via cpan. Perhaps I’m not alone and someone has a way to cross maintain these things that I’m unaware of?
>
> So I yesterday, I decided to install a perl module from cpan. I ran cpan for the first time in a long time, it asked me some question which I took the default (maybe I shouldn’t have!), then I installed Mail::DMARC. It downloaded the source, grinded away for several minutes and when it was finished, it successfully installed the module. Miraculous!
>
> But it installed it in /usr/share/perl/5.30/Mail/DMARC.
>
> I thought that’s odd, why would it install it in a folder that has a perl version? Why not somewhere a bit more general like /usr/share/perl5?
The directory location may not suit you, but for the short
term you should be able to get the modules you want
installed using root and the cpan client.
Another way is to use a module called local::lib,
that let's you have a tree of perl modules in
an unprivileged directory (by default
$HOME/perl5).
It requires setting some environment variables.
Then you need a cpan client that will work with
local::lib. That is cpanm.
So apt-get install liblocal-lib-perl libapp-cpanminus-perl
Setup environment according to `man local::lib`
Then install any module you need with
cpanm Some::Module
cpanm will respect the environment variable and install
it with all dependencies. You will need to have a
compiler present for building modules with C extensions.
> What happens when Perl gets updated and /usr/share/perl/5.30/ is no longer in perl’s search path for its modules? I’m worried that using this DMARC perl module, updating perl could just break mail someday! Shouldn’t the default for cpan be something other than this version based directory on Debian? Should I worry about this? (this may be more a CPAN question than a Debian question to be honest).
This approach, using an unprivileged directory tree that is
merged with debian perl libraries, will work
with an upgraded system perl if the modules
are pure perl. Modules with compiled C code
(using perl's XS interface language) will *not* be
compatible with an upgraded binary.
> So my question is, is there a recommended, maintainable way to install perl modules on Debian that are not installed by apt-get such that things get updated properly?
If the locally installed modules are pure perl, they should
be compatible with a newer perl. You will have to determine
if and when you upgrade these modules.
It's possible the same module could be installed in your
local::lib as in the system libraries. In that case,
libraries will be searched in order specfied by the
$PERL5LIB environment variable.
FWIW I used to use local::lib, long since prefer to compile my
own perl interpreters and libraries. Perlbrew and plenv
are tools for managing multiple perl versions.
have fun,
> I suppose this could even be a general question when you consider other things like python, php, nodejs and others, all of which have their own module systems. Feels like there’s a need for a sort of meta-module system that works with apt, but I’m not sure which is why I am asking here.
>
> Suggestions and advice welcome!
>
> Michael Grant
--
Joel Roth
Reply to: