No puedo encontrar la respuesta a esto en ninguna parte: ¿un módulo instalado a través de APT entra en conflicto con uno instalado a través de CPAN?
Junto con esa pregunta están estas: ¿Dónde viven los módulos CPAN instalados? ¿Son accesibles globalmente o solo para el usuario instalador? ¿Cómo sabes cuál? ¿Cómo sabes qué está instalado y cuál tiene prioridad?
¿Debería incluso usarse CPAN cuando los módulos se instalan a través de APT?
Respuestas:
En Debian y Ubuntu CPAN ( /usr/bin/cpanutilidad) instala módulos en /usr/local/lib/forma predeterminada. Y los paquetes debian mantienen sus archivos /usr/share/perl5/y /usr/lib/perl5/. Por lo tanto, los archivos instalados a través de /usr/bin/cpanno sobrescribirán los archivos instalados a través de apt.
No hay nada de malo en usar el sistema perl, y la mezcla de código apt y cpan generalmente funcionará.
También puede optar por empaquetar manualmente cualquier distribución cpan que no esté disponible en sus repositorios apt. Es fácil con la ayuda de la herramienta dh-make-perl:
dh-make-perl --cpan Some::Module && cd Some-Module* && sudo debi/usr/local/sharepara módulos de perl puro y /usr/local/libpara cosas de xs.
Al instalar desde CPAN directamente, recomendaría usar local :: lib en un directorio privado para usted. Vea la técnica de boostrapping https://metacpan.org/module/local::lib
De esa forma, el módulo instalado CPAN solo será utilizado por su usuario y tendrá una separación muy limpia de los módulos instalados usando APT.
También facilitará la eliminación de los módulos instalados por CPAN si encuentra algún problema o cuando actualiza Ubuntu.
Así es como lo uso en Ubuntu.
Puedes usar ambos pero entrarán en conflicto. Están escritos en el mismo lugar, por lo que si instala algo de apt y luego instala una versión posterior de cpan, podría arreglar las cosas.
No hago mucho Perl, pero en Python ciertamente tengo el dilema del que estás hablando: apt-vs-PyPI. Yo personalmente opto por apt siempre que puedo. Significa que debería recibir actualizaciones sin tener que recordar mantener cada paquete individual de Python. No solo eso, sino que significa que todos mis sistemas deberían ejecutarse en la misma versión de esos paquetes.
No siempre funciona. A veces no tienes suficientes cosas nuevas en los repositorios o algo que necesitas simplemente no está empaquetado. De ninguna manera es perfecto, pero creo que es más perfecto. Solo ten en cuenta lo que estás haciendo y deberías estar bien.
Editar : casi lo olvido, hay una mejor manera de dividir las cosas para que el sistema pueda tener su propio entorno y lo que sea que esté desarrollando puede vivir en su propio entorno (que administra completamente con CPAN), como Python virtualenv...
/programming/1423879/how-can-i-install-specialized-environments-for-different-perl-applications
Siteo sitedirectorio - o que al menos se podría forzarlo.
cpanmódulos instalados terminan en / usr / local / share / perl (o la ubicación especificada por PERL Config.pm), mientras que los paquetes APT terminan en / usr / share / perl5 según la política de Debian. Por lo tanto, no entran en conflicto y es seguro mezclar y combinar instalaciones CPAN y APT, como dicen las otras respuestas. (Python no es una buena analogía aquí: el empaquetado de PERL y el manejo del módulo es muy diferente y, en mi humilde opinión, superior al de Python)
cpanterminan los módulos instalados está determinada por PERLConfig.pm. En mi Ubuntu 11.04, lo es/usr/local/share/perl/5.10.1.