Difference between revisions of "Perl package guidelines (Italiano)"

From ArchWiki
Jump to: navigation, search
m (add tag translateme)
Line 6: Line 6:
 
{{Nota|Questo articolo è in fase di traduzione. Seguite per ora le istruzioni della versione inglese.}}
 
{{Nota|Questo articolo è in fase di traduzione. Seguite per ora le istruzioni della versione inglese.}}
  
==Package Naming==
+
==Nomenclatura pacchetti==
For modules the package name should begin with '''perl-''' and the rest of the name should be constructed from the module name by converting it to lowercase and then replacing colons with hyphens. For example the package name corresponding to HTML::Parser will be '''perl-html-parser'''. Perl applications should have the same name as that of the application but in lowercase.
+
  
==File Placement==
+
Per quanto riguarda i moduli, il nome del pacchetto dovrebbe iniziare con '''perl-''' e il resto del nome dovrebbe essere ricavato dal nome del modulo scritto in minuscolo, sostituendo i due punti con dei trattini. Per esempio, il nome pacchetto corrispondente al modulo HTML::Parser sarà '''perl-html-parser'''. Le applicazioni in Perl, dovrebbero mantenere il loro nome, avendo però cura di scriverlo in minuscolo.
Perl modules should install module files in {{Filename|/usr/lib/perl5/vendor_perl/}} (this is done by setting the {{Codeline|INSTALLDIRS}} variable as shown below). No files should be stored in {{Filename|/usr/lib/perl5/site_perl/}} as that directory is reserved for use by the system administrator to install Perl packages outside the package management system. The files {{Filename|perllocal.pod}} and {{Filename|.packlist}} also should not be present; this is taken care of by the example [[PKGBUILD]] given below.
+
 
 +
==Posizione dei files==
 +
 
 +
I moduli Perl dovrebbero installare i propri files in {{Filename|/usr/lib/perl5/vendor_perl/}} (questo comportamento si può ottenere impostando la variabile {{Codeline|INSTALLDIRS}}, come mostrato sotto). Nessun file dovrebbe essere inserito in {{Filename|/usr/lib/perl5/site_perl/}}, poichè quella directory è riservata ai pacchetti Perl non installati tramite il package manager. I files {{Filename|perllocal.pod}} e {{Filename|.packlist}} dovrebbero essere presenti. Le operazioni sopra elencate vengono eseguite nel PKGBUILD d'esempio mostrato sotto.
 +
 
 +
==Esempio==
 +
Un PKGBUILD d'esempio può essere trovato in {{Filename|/usr/share/pacman/PKGBUILD-perl.proto}}, file fornito dal pacchetto {{Package Official|abs}}. Viene anche riportato sotto (senza i commenti):
  
==Example==
 
An example PKGBUILD can be found at {{Filename|/usr/share/pacman/PKGBUILD-perl.proto}} which is present in the {{Package Official|abs}} package. It is also reproduced below (without the comments):
 
 
<pre>
 
<pre>
# Contributor: Your Name <youremail@domain.com>
+
# Contributor: Your Name <youremail@domain.com>
pkgname=perl-foo-bar
+
pkgname=perl-foo-bar
pkgver=VERSION
+
pkgver=VERSION
pkgrel=1
+
pkgrel=1
pkgdesc=""
+
pkgdesc=""
arch=()
+
arch=()
url=""
+
url=""
license=('GPL' 'PerlArtistic')
+
license=('GPL' 'PerlArtistic')
depends=('perl>=5.10.0')
+
depends=('perl>=5.10.0')
makedepends=()
+
makedepends=()
provides=()
+
provides=()
conflicts=()
+
conflicts=()
replaces=()
+
replaces=()
backup=()
+
backup=()
options=(!emptydirs)
+
options=(!emptydirs)
install=
+
install=
source=(http://search.cpan.org/CPAN/authors/id/***/***-$pkgver.tar.gz)
+
source=(http://search.cpan.org/CPAN/authors/id/***/***-$pkgver.tar.gz)
md5sums=()
+
md5sums=()
  
build() {
+
build() {
 
   cd "$srcdir/***-$pkgver"
 
   cd "$srcdir/***-$pkgver"
  
Line 50: Line 53:
 
   find "$pkgdir" -name perllocal.pod -delete
 
   find "$pkgdir" -name perllocal.pod -delete
 
   find "$pkgdir" -name .packlist -delete
 
   find "$pkgdir" -name .packlist -delete
}
+
}
  
# vim:set ts=2 sw=2 et:
+
# vim:set ts=2 sw=2 et:
 
</pre>
 
</pre>
  
In most cases, you should put '''any''' in the {{Codeline|arch}} array since most Perl packages are architecture independent.
+
Nella maggior parte dei casi, è consigliato inserire '''any''' nell'array {{Codeline|arch}}, poichè molti pacchetti Perl sono indipendenti dall'architettura del sistema.
  
==Automation==
+
==Automatizzazione==
As Perl is centered around the [http://www.cpan.org CPAN], there are a few scripts to make the most of this, and save you writing PKGBUILDs by hand.
+
Poichè Perl si basa su [http://www.cpan.org/ CPAN], esistono alcuni script che eseguono quanto scritto sopra automaticamente, risparmiandovi dallo scrivere i PKGBUILD a mano.
  
The more perlish method is to use a {{Codeline|CPANPLUS::Dist}} plugin for installing CPAN modules as dynamically generated pacman packages, available at http://aur.archlinux.org/packages.php?ID=24971
+
Il metodo più consono allo stile Perl, è quello di usare il plugin {{Codeline|CPANPLUS::Dist}}, che consente di generare automaticamente pacchetti per pacman. Il plugin è installabile da qui: {{Package AUR|perl-cpanplus-dist-arch}}
  
There is also a script called {{Codeline|pacpan}}, which can recursively generate PKGBUILDs for a module: http://www.archlinux.org/packages/community/any/pacpan/
+
Esiste inoltre uno script, chiamato {{Package Official|pacpan}}, che è in grado di generare ricosivamente dei PKGBUILD per un dato modulo.
  
It is worth mentioning that [[Bauerbill | Bauerbill]] has similar support for generating PKGBUILDs to {{Codeline|pacpan}}. As well as adding the ability to upgrade all installed CPAN modules directly from CPAN via a pacman interface. Make sure to read the Bauerbill man file for usage instructions.
+
Vale la pena segnalare che [[Bauerbill|Bauerbill]] supporta la generazione di PKGBUILD in modo simile a quanto fatto da {{Codeline|pacpan}}, così come è in grado di aggiornare tutti i moduli CPAN direttamente da CPAN stesso attraverso un'interfaccia a pacman. Assicurarsi di leggere la pagina di manuale di Bauerbill per le istruzioni d'uso.
  
==Advanced Topics==
 
If the packager has become comfortable enough with creating perl packages, the below sections may offer some new ideas to consider.  This information might also help troubleshooting packaging problems.
 
  
===Glossary===
+
==Argomenti avanzati==
 +
Una volta che si è acquisita dimestichezza con la creazione di pacchetti perl, è possibile leggere la sezione sottostante, che potrebbe offrire parecchi spunti interessanti. Le informazioni sotto riportate potrebbero inoltre essere utili per risolvere i problemi di pacchettizzazione.
  
You should be familiar with the following terms.
+
===Glossario===
 +
Si dovrebbe aver già acquisito familiarità con i seguenti termini:
  
====Module====
+
====Modulo====
Modules are declared with the {{Codeline|package}} keyword in perl. Modules are contained inside a {{Filename|.pm}} ("dot-pee-em") file. Though it's possible more than one module ({{Codeline|package}}) is in the file.  Modules have namespaces separated with {{Codeline|::}} (double colons), like: {{Codeline|Archlinux::Module}}. When loading a module, the {{Codeline|::}}s are replaced with directory separators.  For example: {{Filename|Archlinux/Module.pm}} will be loaded for the module {{Codeline|Archlinux::Module}}.
+
In Perl, moduli sono dichiarati con la parola chiave {{Codeline|package}}. Essi sono contenuti all'interno di un file con estensione {{Filename|.pm}}, che può a sua volta ospitare diversi moduli al suo interno. I namespace dei moduli sono separati da {{Codeline|::}}, (due doppi punti), ad esempio: {{Codeline|Archlinux::Modulo}}. Quando si carica un modulo, i due doppi punti sono sostituiti con uno slash. Per esempio, il modulo {{Codeline|Archlinux::Modulo} caricherà il file {{Filename|Archlinux/Modulo}}.
  
 
====Core Module====
 
====Core Module====
Core modules are included with an installation of perl.  Some core modules are ''only'' available bundled with perl. Other modules can still be downloaded and installed separately from CPAN.
+
I Core Modules sono quelli inclusi in un'installazione di Perl, ed alcuni di essi sono disponibili ''solamente'' con Perl stesso. Altri moduli possono invece essere scaricati tramite CPAN.
  
====Distributions====
+
====Dist Packages====
(aka dist, package)  This is the equivalent of an Archlinux package in CPAN-lingo. Distributions are {{Filename|.tar.gz}} archives full of files.  These archives contain primarily .pm module files, tests for the included modules, documentation for the modules, and whatever else is deemed necessary.
+
Sono l'equivalente Perl di un pacchetto di Archlinux. I dist packages sono archivi {{Filename|.tar.gz}} pieni di files con estensione .pm, tests, documentazione, e tutto il necessario per i moduli ivi contenuti.
  
Usually a distribution contains a primary module with the same name.  Sometimes this is not true, like with the Template-Toolkit distribution. The latest package, {{Filename|Template-Toolkit-2.22.tar.gz}}, for the {{Codeline|Template-Toolkit}} dist, contains no {{Codeline|Template::Toolkit}} module!
+
===Installazione di Perl locale===
 +
Il fatto che i programmatori perl potrebbero voler installare diverse versioni di perl potrebbe rappresentare un problema, benchè ciò sia utile per verificare la retrocompatibilità dei programmi. Compilare una propria versione di perl potrebbe garantire inoltre benefici prestazionali. Inoltre, poichè spesso il perl di sistema non è all'ultima versione disponibile, l'utente potrebbe decidere di voler provare una versione più recente.
  
Sometimes because distributions are named after a main module, their names are used interchangeably and they get muddled together. However it is sometimes useful to consider them a separate entity (like in Template-Toolkit's case).
+
Se l'utente ha l'eseguibile perl nel proprio {{Codeline|$PATH}}, esso verrà eseguito quando si scrive il comando "perl" nella shell. Inoltre, questo verrà eseguito anche all'interno del {{Filename|PKGBUILD}}, cosa che potrebbe causare problemi di difficile individuazione.
  
===User-Installed perl===
+
Il problema principale risiede nei moduli XS, che fungono da bridge tra Perl e C, usando le API proprie del Perl. Poichè queste ultime possono cambiare in modo significativo tra due versioni di Perl, se l'utente compila dei moduli XS con la propria versione dell'interprete, questi saranno incompatibili con il Perl di sistema, il quale darà luogo ad un errore di linkin quando si proverà a caricarli.
A subtle problem is that advanced perl programmers may like to have multiple versions of perl installed. This is useful for testing backwards-compatibility in created programs. There are also speed benefits to compiling your own custom perl interpreter (i.e. without threads). Another reason for a custom ''perl'' is simply because the official perl ArchLinux package sometimes lags behind perl releases. The user may be trying out the latest perl... who knows?
+
  
If the user has the custom perl executable in their {{Codeline|$PATH}}, the custom perl will be run when the user types the ''perl'' command on the shell. In fact the custom perl will run inside the {{Filename|PKGBUILD}} as well! This can lead to insidious problems that are difficult to understand.
+
Una soluzione potrebbe essere quella di specificare il path assoluto dell'interprete di sistema ({{Filename|/usr/bin/perl}}) quando si richiama il comando perl nel {{Filename|PKGBUILD}}.
 
+
The problem lies in compiled XS modules. These modules bridge perl and C. As such they must use perl's internal C API to accomplish this bridge. Perl's C API changes slightly with different versions of perl. If the user has a different version of perl than the system perl ({{Filename|/usr/bin/perl}}) then any XS module compiled with the user's perl will be incompatible with the system-wide perl. When trying to use the compiled XS module with the system perl, the module will fail to load with a link error.
+
 
+
A simple solution is to always use the absolute path of the system-wide perl interpreter ({{Filename|/usr/bin/perl}}) when running perl in the {{Filename|PKGBUILD}}.
+
 
+
===Installation Modules===
+
One of perl's greatest advantages is the sheer number of modules[/dists] available on CPAN.  Not too surprisingly, there are also several different modules used for installing... well... modules!  TMTOWTDI!  I am not aware of a standard name for these types of modules, so I just called them "Installation Modules".
+
 
+
All these modules are concerned with is building the package and installing wherever the user wants.  This seems straightforward, but considering the number of different systems perl runs on, this can get complex.  These modules all place a perl code file inside the dist tarball.  Running this perl script will initiate the build/installation process.  I have called this the "Build script" in the below list.
+
 
+
====ExtUtils::MakeMaker====
+
 
+
;Build script: {{Filename|Makefile.PL}}
+
;CPAN link: http://search.cpan.org/dist/ExtUtils-MakeMaker
+
 
+
The original, oldest module for installing modules is {{Codeline|ExtUtils::MakeMaker}}.  The major downside to this module is that it requires the {{Filename|make}} program to build and install everything.  This may not seem like a big deal to linux users but is a real hassle for Windows people!  In the name of progress the perl community is trying to encourage people to use the newer modules instead.
+
 
+
====Module::Build====
+
 
+
;Build script: {{Filename|Build.PL}}
+
;CPAN link: http://search.cpan.org/dist/Module-Build
+
 
+
The main advantage of Module::Build is that it is pure-perl.  This means it does not require a {{Filename|make}} program to be installed for you to build/install modules.  Its adoption was rocky because if {{Codeline|Module::Build}} was not already installed, you could not run the bundled {{Filename|Build.PL}} script!  This is not a problem with recent versions of perl because {{Codeline|Module::Build}} is a core module.
+
 
+
====Module::Install====
+
 
+
;Build script: {{Filename|Makefile.PL}}
+
;CPAN link: http://search.cpan.org/dist/Module-Install
+
 
+
Another modern build/installation module, {{Codeline|Module::Install}} still requires the {{Filename|make}} program be installed to function.  It was designed as a drop-in replacement for {{Codeline|ExtUtils::MakeMaker}}, to address some of {{Codeline|MakeMaker}}'s shortcomings. 
+
 
+
One very interesting feature is that {{Codeline|Module::Install}} bundles a ''complete'' ''copy'' of itself into the distribution file.  Because of this, unlike {{Codeline|MakeMaker}} or {{Codeline|M::B}}, you do not need {{Codeline|Module::Install}} to be installed on your system.
+
 
+
Another very unique feature is auto-install.  ''This appears to be not recommended, but seems used quite often.''  When the module author enables auto-install for his distribution, {{Codeline|Module::Install}} will search for and install any pre-requisite modules that are not installed when {{Filename|Makefile.PL}} is executed.  This feature is skipped when {{Codeline|Module::Install}} detects it is being run by {{Codeline|CPAN}} or {{Codeline|CPANPLUS}}.  However, this feature is not skipped when run inside... oh I don't know... a '''PKGBUILD'''!  I hope you can see how a rogue perl program downloading and installing modules willy-nilly ''inside a PKGBUILD'' can be a problem.  See the [[#PERL_AUTOINSTALL]] environment variable to see how to fix this.
+
 
+
===Environment Variables===
+
A number of environment variables can affect the way the modules are built or installed.  Some have a very dramatic effect and can cause problems if misunderstood.  An advanced user could be using these environment variables.  Some of these will break an unsuspecting {{Filename|PKGBUILD}}; or cause unexpected behavior.
+
 
+
====PERL_MM_USE_DEFAULT====
+
When this variable is set to a true value, the installation module will pretend the default answer was given to any question it would normally ask.  This does not ''always'' work, but all of the installation modules honour it.  ''That doesn't mean the module author will!''
+
 
+
====PERL_AUTOINSTALL====
+
You can pass additional command-line arguments to {{Codeline|Module::Install}}'s {{Filename|Makefile.PL}} with this variable.  In order to turn off auto-install (''highly recommended''), assign {{Codeline|--skipdeps}} to this.
+
 
+
<pre>export PERL_AUTOINSTALL='--skipdeps'</pre>
+
 
+
====PERL_MM_OPT====
+
You can pass additional command-line arguments to {{Filename|Makefile.PL}} and/or {{Filename|Build.PL}} with this variable.  For example, you can install modules into your home-dir by using:
+
 
+
<pre>export PERL_MM_OPT=INSTALLBASE=~/perl5</pre>
+
 
+
====PERL_MB_OPT====
+
This is the same thing as PERL_MM_OPT except it is only for {{Codeline|Module::Build}}.  For example, you could install modules into your home-dir by using:
+
 
+
<pre>export PERL_MB_OPT=--install_base=~/perl5</pre>
+
 
+
====MODULEBUILDRC====
+
{{Codeline|Module::Build}} allows you to override its command-line-arguments with an rcfile.  This defaults to {{Filename|~/.modulebuildrc}}.  You can override which file it uses by setting the path to the rcfile in {{Codeline|MODULEBUILDRC}}.  The paranoid might set {{Codeline|MODULEBUILDRC}} to {{Filename|/dev/null}}... just in case.
+
 
+
===Hardened Example===
+
Using all of our new accumulated knowledge, we can create a more hardened PKGBUILD that will resist any environment variables' attempts to sabotage it:
+
 
+
<pre>
+
# Contributor: Your Name <youremail@domain.com>
+
pkgname=perl-foo-bar
+
pkgver=VERSION
+
pkgrel=1
+
pkgdesc='This is the awesome Foo::Bar module!'
+
arch=('any')
+
url='http://search.cpan.org/dist/Foo-Bar'
+
license=('GPL' 'PerlArtistic')
+
depends=('perl>=5.10.0')
+
makedepends=()
+
provides=()
+
conflicts=()
+
replaces=()
+
backup=()
+
options=(!emptydirs)
+
install=
+
source=("http://search.cpan.org/CPAN/authors/id/***/***-$pkgver.tar.gz")
+
md5sums=()
+
 
+
build() {
+
  cd "$srcdir/***-$pkgver"
+
 
+
  # Setting these env variables overwrites any command-line-options we don't want...
+
  export PERL_MM_USE_DEFAULT=1 PERL_AUTOINSTALL=--skipdeps \
+
    PERL_MM_OPT="INSTALLDIRS=vendor DESTDIR='$pkgdir'" \
+
    PERL_MB_OPT="--installdirs vendor --destdir '$pkgdir'" \
+
    MODULEBUILDRC=/dev/null
+
 
+
  # If using Makefile.PL
+
  { /usr/bin/perl Makefile.PL &&
+
    make &&
+
    make test &&
+
    make install; } || return 1
+
 
+
  # If using Build.PL
+
  { /usr/bin/perl Build.PL &&
+
    ./Build &&
+
    ./Build test &&
+
    ./Build install; } || return 1
+
 
+
  # remove perllocal.pod and .packlist
+
  find "$pkgdir" -name .packlist -o -name perllocal.pod -delete
+
</pre>
+

Revision as of 14:38, 23 March 2011


This template has only maintenance purposes. For linking to local translations please use interlanguage links, see Help:i18n#Interlanguage links.


Local languages: Català – Dansk – English – Español – Esperanto – Hrvatski – Indonesia – Italiano – Lietuviškai – Magyar – Nederlands – Norsk Bokmål – Polski – Português – Slovenský – Česky – Ελληνικά – Български – Русский – Српски – Українська – עברית – العربية – ไทย – 日本語 – 正體中文 – 简体中文 – 한국어


External languages (all articles in these languages should be moved to the external wiki): Deutsch – Français – Română – Suomi – Svenska – Tiếng Việt – Türkçe – فارسی

Tango-preferences-desktop-locale.pngThis article or section needs to be translated.Tango-preferences-desktop-locale.png

Notes: please use the first argument of the template to provide more detailed indications. (Discuss in Talk:Perl package guidelines (Italiano)#)
Nota: Questo articolo è in fase di traduzione. Seguite per ora le istruzioni della versione inglese.

Nomenclatura pacchetti

Per quanto riguarda i moduli, il nome del pacchetto dovrebbe iniziare con perl- e il resto del nome dovrebbe essere ricavato dal nome del modulo scritto in minuscolo, sostituendo i due punti con dei trattini. Per esempio, il nome pacchetto corrispondente al modulo HTML::Parser sarà perl-html-parser. Le applicazioni in Perl, dovrebbero mantenere il loro nome, avendo però cura di scriverlo in minuscolo.

Posizione dei files

I moduli Perl dovrebbero installare i propri files in Template:Filename (questo comportamento si può ottenere impostando la variabile Template:Codeline, come mostrato sotto). Nessun file dovrebbe essere inserito in Template:Filename, poichè quella directory è riservata ai pacchetti Perl non installati tramite il package manager. I files Template:Filename e Template:Filename dovrebbero essere presenti. Le operazioni sopra elencate vengono eseguite nel PKGBUILD d'esempio mostrato sotto.

Esempio

Un PKGBUILD d'esempio può essere trovato in Template:Filename, file fornito dal pacchetto Template:Package Official. Viene anche riportato sotto (senza i commenti):

 # Contributor: Your Name <youremail@domain.com>
 pkgname=perl-foo-bar
 pkgver=VERSION
 pkgrel=1
 pkgdesc=""
 arch=()
 url=""
 license=('GPL' 'PerlArtistic')
 depends=('perl>=5.10.0')
 makedepends=()
 provides=()
 conflicts=()
 replaces=()
 backup=()
 options=(!emptydirs)
 install=
 source=(http://search.cpan.org/CPAN/authors/id/***/***-$pkgver.tar.gz)
 md5sums=()

 build() {
  cd "$srcdir/***-$pkgver"

  # install module in vendor directories.
  PERL_MM_USE_DEFAULT=1 perl Makefile.PL INSTALLDIRS=vendor || return 1
  make || return 1
  make install DESTDIR="$pkgdir/" || return 1

  ## for packages with Build.PL, do this instead:
  # perl Build.PL installdirs=vendor destdir="$pkgdir/"
  # perl Build
  # perl Build install

  # remove perllocal.pod and .packlist
  find "$pkgdir" -name perllocal.pod -delete
  find "$pkgdir" -name .packlist -delete
 }

 # vim:set ts=2 sw=2 et:

Nella maggior parte dei casi, è consigliato inserire any nell'array Template:Codeline, poichè molti pacchetti Perl sono indipendenti dall'architettura del sistema.

Automatizzazione

Poichè Perl si basa su CPAN, esistono alcuni script che eseguono quanto scritto sopra automaticamente, risparmiandovi dallo scrivere i PKGBUILD a mano.

Il metodo più consono allo stile Perl, è quello di usare il plugin Template:Codeline, che consente di generare automaticamente pacchetti per pacman. Il plugin è installabile da qui: Template:Package AUR

Esiste inoltre uno script, chiamato Template:Package Official, che è in grado di generare ricosivamente dei PKGBUILD per un dato modulo.

Vale la pena segnalare che Bauerbill supporta la generazione di PKGBUILD in modo simile a quanto fatto da Template:Codeline, così come è in grado di aggiornare tutti i moduli CPAN direttamente da CPAN stesso attraverso un'interfaccia a pacman. Assicurarsi di leggere la pagina di manuale di Bauerbill per le istruzioni d'uso.


Argomenti avanzati

Una volta che si è acquisita dimestichezza con la creazione di pacchetti perl, è possibile leggere la sezione sottostante, che potrebbe offrire parecchi spunti interessanti. Le informazioni sotto riportate potrebbero inoltre essere utili per risolvere i problemi di pacchettizzazione.

Glossario

Si dovrebbe aver già acquisito familiarità con i seguenti termini:

Modulo

In Perl, moduli sono dichiarati con la parola chiave Template:Codeline. Essi sono contenuti all'interno di un file con estensione Template:Filename, che può a sua volta ospitare diversi moduli al suo interno. I namespace dei moduli sono separati da Template:Codeline, (due doppi punti), ad esempio: Template:Codeline. Quando si carica un modulo, i due doppi punti sono sostituiti con uno slash. Per esempio, il modulo {{Codeline|Archlinux::Modulo} caricherà il file Template:Filename.

Core Module

I Core Modules sono quelli inclusi in un'installazione di Perl, ed alcuni di essi sono disponibili solamente con Perl stesso. Altri moduli possono invece essere scaricati tramite CPAN.

Dist Packages

Sono l'equivalente Perl di un pacchetto di Archlinux. I dist packages sono archivi Template:Filename pieni di files con estensione .pm, tests, documentazione, e tutto il necessario per i moduli ivi contenuti.

Installazione di Perl locale

Il fatto che i programmatori perl potrebbero voler installare diverse versioni di perl potrebbe rappresentare un problema, benchè ciò sia utile per verificare la retrocompatibilità dei programmi. Compilare una propria versione di perl potrebbe garantire inoltre benefici prestazionali. Inoltre, poichè spesso il perl di sistema non è all'ultima versione disponibile, l'utente potrebbe decidere di voler provare una versione più recente.

Se l'utente ha l'eseguibile perl nel proprio Template:Codeline, esso verrà eseguito quando si scrive il comando "perl" nella shell. Inoltre, questo verrà eseguito anche all'interno del Template:Filename, cosa che potrebbe causare problemi di difficile individuazione.

Il problema principale risiede nei moduli XS, che fungono da bridge tra Perl e C, usando le API proprie del Perl. Poichè queste ultime possono cambiare in modo significativo tra due versioni di Perl, se l'utente compila dei moduli XS con la propria versione dell'interprete, questi saranno incompatibili con il Perl di sistema, il quale darà luogo ad un errore di linkin quando si proverà a caricarli.

Una soluzione potrebbe essere quella di specificare il path assoluto dell'interprete di sistema (Template:Filename) quando si richiama il comando perl nel Template:Filename.