Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #228695 > unrolled thread

Most maintainable way to install perl modules on Debian sysetms

Back to article view | Back to linux.debian.user

Contents

  Most maintainable way to install perl modules on Debian sysetms Michael Grant <mgrant@grant.org> - 2020-11-15 22:10 +0100
    Re: Most maintainable way to install perl modules on Debian sysetms Dan Ritter <dsr@randomstring.org> - 2020-11-16 00:10 +0100
      Re: Most maintainable way to install perl modules on Debian sysetms Michael Grant <mgrant@grant.org> - 2020-11-16 01:10 +0100
        Re: Most maintainable way to install perl modules on Debian sysetms Dan Ritter <dsr@randomstring.org> - 2020-11-16 01:20 +0100
          Re: Most maintainable way to install perl modules on Debian sysetms Michael Grant <mgrant@grant.org> - 2020-11-16 02:20 +0100
            Re: Most maintainable way to install perl modules on Debian sysetms Andy Smith <andy@strugglers.net> - 2020-11-16 02:40 +0100
    Re: Most maintainable way to install perl modules on Debian sysetms Joel Roth <joelz@pobox.com> - 2020-11-16 07:00 +0100
    Re: Most maintainable way to install perl modules on Debian sysetms Mike Castle <dalgoda+debian@gmail.com> - 2020-11-17 03:00 +0100

#228695 — Most maintainable way to install perl modules on Debian sysetms

[Multipart message — attachments visible in raw view] — view raw

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?

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).

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?

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

[toc] | [next] | [standalone]

#228699

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?

cpan2deb takes a CPAN module and builds it as a Debian package.
Use a common suffix like -mgrant and you can spot these in
package listings.

When you upgrade, build new versions of all the -mgrant
packages.

-dsr-

[toc] | [prev] | [next] | [standalone]

#228700

[Multipart message — attachments visible in raw view] — view raw

> cpan2deb takes a CPAN module and builds it as a Debian package.
> Use a common suffix like -mgrant and you can spot these in
> package listings.
> 
> When you upgrade, build new versions of all the -mgrant
> packages.

Thanks.  So in one way this makes it easier to remove the module which
cpan doesn't do, but I'd still have to track the module manually and
run this again and again, remembering or scripting something to do all
of this automatically.

Has anyone built something which when you ran apt upgrade, it would
look at each of these packages that were made by cpan2deb, then look
in cpan to see if the module was updated, then create a new deb and
upgrade the package?

That would really automate the whole process like apt upgrade.

[toc] | [prev] | [next] | [standalone]

#228701

Michael Grant wrote: 
> > cpan2deb takes a CPAN module and builds it as a Debian package.
> > Use a common suffix like -mgrant and you can spot these in
> > package listings.
> > 
> > When you upgrade, build new versions of all the -mgrant
> > packages.
> 
> Thanks.  So in one way this makes it easier to remove the module which
> cpan doesn't do, but I'd still have to track the module manually and
> run this again and again, remembering or scripting something to do all
> of this automatically.
> 
> Has anyone built something which when you ran apt upgrade, it would
> look at each of these packages that were made by cpan2deb, then look
> in cpan to see if the module was updated, then create a new deb and
> upgrade the package?
> 
> That would really automate the whole process like apt upgrade.

Well, that would do the job thoughtlessly. It might backfire
spectacularly.

If one set up a service in that way, it would eventually get a
terrible reputation.

If, on the other hand, one spent the time to maintain those
packages properly... you could be a Debian Maintainer, and get
them into the primary repos.

The third course, that doesn't commit you to doing that work and 
doesn't expose you to that risk, is more or less as I've already
outlined. 

-dsr-

[toc] | [prev] | [next] | [standalone]

#228702

[Multipart message — attachments visible in raw view] — view raw

> Well, that would do the job thoughtlessly. It might backfire
> spectacularly.
> 
> If one set up a service in that way, it would eventually get a
> terrible reputation.
> 
> If, on the other hand, one spent the time to maintain those
> packages properly... you could be a Debian Maintainer, and get
> them into the primary repos.
> 
> The third course, that doesn't commit you to doing that work and 
> doesn't expose you to that risk, is more or less as I've already
> outlined. 

apt has an excellent reputation, I'm not sure I see why mechanizing
such a process as apt does should be necessarily be bad.  I'm not
talking about blind nightly updates.

If this is truely the best way at the moment to keep perl modules
maintainable, I will try it.

Thanks.

[toc] | [prev] | [next] | [standalone]

#228704

Hello,

On Sun, Nov 15, 2020 at 08:14:05PM -0500, Michael Grant wrote:
> > Well, that would do the job thoughtlessly. It might backfire
> > spectacularly.

[…]

> apt has an excellent reputation, I'm not sure I see why mechanizing
> such a process as apt does should be necessarily be bad.  I'm not
> talking about blind nightly updates.

The issue is that somewhere behind the scenes is a human being, the
Debian package maintainer, who is backporting security fixes (but
not new features!) from newer releases of the module into a Debian
package for a given Debian release.

That's not a mechanical process.

So when proposing to adopt a mechanical process, it's not comparable
to what an actually maintained Debian package is like; it's just a
CPAN module in a convenient format.

Most of the time the upstream author is mindful of backward
compatibility issues and isn't going to release something onto CPAN
that breaks things, but sometimes it's unavoidable and sometimes the
author isn't mindful of this. There is a big variance in quality of
CPAN modules.

So probably the best thing you can do is cpan2deb and stick with
those versions that you have tested, unless an update comes along
with security fixes or features you need.

You can install the package "cpanoutdated" which will tell you about
newer versions on CPAN compared to on your system, though it will
report quite a lot of packaged stuff as being outdated, which is
only to be expected.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

[toc] | [prev] | [next] | [standalone]

#228705

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

[toc] | [prev] | [next] | [standalone]

#228712

[Multipart message — attachments visible in raw view] — view raw

I would not be surprised if the version number indicated the module in not
Pure Perl, but rather includes some C source code.  Which would then need
to be compiled specifically for the version of Perl installed.

mrc

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web