it-swarm.dev

¿Cuándo usar paquetes en aptitude versus CPAN / Gems / PyPI?

¿Cuál es la regla general para cuándo instalar un paquete desde los repositorios oficiales .deb, en comparación con cuándo instalar con el administrador de paquetes del idioma? Los que están en los repositorios ascendentes suelen estar al menos un poco desactualizados, pero tampoco quiero que mis paquetes choquen con los "oficiales", y parece que esa aptitud me obligará a instalar el oficial unos en muchos casos de todos modos.

5
Benjamin Pollack

Esta es una pregunta difícil de responder en general.

Los paquetes oficiales .deb le brindan estabilidad y soporte completo por parte de la comunidad Ubuntu. Si no necesita la última versión, es mejor que tenga esta solución. También tiene el soporte del administrador de paquetes para actualizaciones, eliminación, etc.

Si necesita soporte de upstream, o necesita las últimas características, es mejor que lo obtenga de los sistemas de distribución como CPAN, gem, pear, etc.

6
txwikinger

En mi experiencia (ciertamente no demasiado vasta), los administradores de paquetes específicos del idioma no hacen un trabajo tan bueno como .deb en el seguimiento de dependencias que son totalmente fuera el límite del idioma (Estoy pensando especialmente en las dependencias de las bibliotecas codificadas en C que un paquete envuelve para usar en Python, Perl, Ruby, etc.).

Si (por ejemplo) un Pypi Python paquete 'barfoo' requiere alguna biblioteca libfoobar para construir la extensión _bf.so Python que utiliza el paquete, y necesita libfoobar para estar al menos en la versión 5.2, depende de usted rastrear qué .deb suministra las versiones adecuadas de libfoobar (y es posible que no encuentre una, si el paquete Pypi realiza un seguimiento cercano al más reciente y mejor de upstream), y de alguna manera lo rastrea en caso de que desinstale barfoo más tarde (por lo que el proveedor libfoobar queda "huérfano" y podría/debería eliminarse) .

No creo que el problema de integrar Pypi/CPAN/etc. con otros sistemas de distribución de paquetes pueda considerarse todavía "resuelto". Para dolores de cabeza de administración mínimos, si puede sobrevivir con un .deb oficial (no necesita el último y mejor feechurz & c), creo que sería aconsejable; en el otro extremo, por supuesto, para un paquete que hacer desea ser súper actualizado (por ejemplo, usted es uno de los autores/mantenedores principales del paquete ;-), existe la opción de mantener un nuevo repositorio en cualquier sistema de control de versiones que use el paquete (svn, hg, git, Bazaar, ...) y mantenerlo construido desde las fuentes. Pypi/CPAN/& c están "en el medio". Seguramente algunas veces este camino intermedio también será aconsejable.

Y, una opción que podría considerarse es crear su propio paquete .deb (basado en Pypi/CPAN/& c one, o incluso en fuentes ascendentes) y mantener su repositorio de dichos paquetes (para aquellos paquetes para los cuales encuentra repositorios oficiales de .deb demasiado pobres o al revés). No es mucho más problema que instalar de otra manera (seguimiento manual de dependencias fuera del idioma) y ayudaría con la identificación de "paquetes huérfanos" y similares (además, si publica su paquete, también puede ayudar a otras personas ;-).

5
Alex Martelli

Realmente he estado en contra de usar Aptitude para administrar paquetes desde otro Administrador de paquetes. CPAN, Gems, Pecl, Pear, etc. son administradores de paquetes para sus respectivos idiomas. Son lo que debes usar de manera predeterminada, en mi opinión, porque para eso están diseñados. Sin mencionar la mayoría de todos los que manejan actualizaciones y actualizaciones ahora (actualización de gemas, actualización de gemas, etc.). Sería como usar yum para instalar Apache en su máquina Ubuntu.

Dicho esto, hay algunas ocasiones en que la versión Aptitude reina suprema. Uno de ellos es cuando falla la instalación de un módulo desde un administrador de paquetes de idiomas (esto se debe típicamente a problemas de configuración variables).

Prioridad en mi opinión Language Package Manager> Aptitude.

1
Marco Ceppi