Why do official perl docker images have two version of perl?

Question

I'm working on a legacy product which uses the Docker perl:5.10-threaded image and ran into an issue trying to debug things when I discovered there are two version of perl - one in /usr/local/bin/perl and one in /usr/bin/perl. In this particular image, they are actually different versions

• /usr/local/bin/perl -> 5.10.1
• /usr/bin/perl -> 5.20.2

The issue it was causing is that each has a different @INC path.

$ /usr/local/bin/perl -V 
    [snip]
    /usr/local/lib/perl5/5.10.1/x86_64-linux-thread-multi
    /usr/local/lib/perl5/5.10.1
    /usr/local/lib/perl5/site_perl/5.10.1/x86_64-linux-thread-multi
    /usr/local/lib/perl5/site_perl/5.10.1

$ /usr/bin/perl -V
    [snip]
    /etc/perl
    /usr/local/lib/x86_64-linux-gnu/perl/5.20.2
    /usr/local/share/perl/5.20.2
    /usr/lib/x86_64-linux-gnu/perl5/5.20
    /usr/share/perl5
    /usr/lib/x86_64-linux-gnu/perl/5.20
    /usr/share/perl/5.20
    /usr/local/lib/site_perl
    .

The latest versions, like perl:5.30-threaded also have two versions and different @INC paths as well.

• /usr/local/bin/perl -> 5.30.0
• /usr/bin/perl -> 5.28.1

It turns out my legacy app uses #!/usr/bin/perl, which was very confusing to me when perl foo.pl didn't work the same as foo.pl (it complained about missing libraries).

To add a bit more color, this legacy app also installs a bunch of perl libraries via apt-get. E.g.,

libcpanel-json-xs-perl libxml-libxml-perl libcgi-pm-perl 
libtie-ixhash-perl
libswitch-perl libmime-lite-perl liblist-moreutils-perl
libdate-calc-perl libnet-sftp-foreign-perl
libxml-libxslt-perl liburi-escape-xs-perl
libdatetime-perl

These seem to install things accessible by /usr/bin/perl, which is perhaps why the app uses it in the shebang lines.

The other thing this app does is install some cpanm items and then copy them over, so they are accessible to /usr/bin/perl

RUN cpanm XML::XML2JSON
RUN cpanm JSON                       

RUN cp /usr/local/lib/perl5/site_perl/5.10.1/XML/XML2JSON.pm /usr/lib/x86_64-linux-gnu/perl5/5.20/XML
RUN cp /usr/local/lib/perl5/site_perl/5.10.1/JSON.pm /usr/lib/x86_64-linux-gnu/perl5/5.20

This seems like a hack to me, but I'm new to perl development, so who knows?

All this leads up to my questions:

• why are there two version of perl in the Docker images?
• are apt-get and cpanm incompatible with each other?
• is there a better way to install these perl libs?

Answer 1

Perl is an essential part of many Linux distributions, and has to come pre-installed. The system perl that is used by the operating system is usually installed as /usr/bin/perl. Modules for it are managed through the package manager (e.g. apt) and not via cpan/cpanm. If you were to install modules for the system perl yourself, this might conflict with modules expected by the operating system. Worse, installing the wrong module version could break parts of the OS. Similarly, replacing the system perl is a bad idea. That's why those Docker images install the different perl alongside.

For your apps, you should avoid the system perl. If you want to install extra modules for use with the system perl, consider using local::lib. In some cases you might install dependencies such as C libraries or external tools via apt, but you wouldn't use apt-provided Perl modules.

Unless you are targeting a specific operating system, do not hardcode the #!/usr/bin/perl shebang. Instead, prefer #!/usr/bin/env perl so that the script will use the perl that is first in the PATH. Alternatively, use wrapper scripts to explicitly invoke the correct perl installation. For example:

#!/bin/sh
exec /usr/local/bin/perl -I/path/to/extra/modules /path/to/my/script "$@"

Note that you cannot share modules between different versions of Perl. During installation of XS modules they are compiled for a specific version, and will fail to load with a different Perl version. For your local perl, just install dependencies via cpanm and ignore modules that were installed for the system perl.