Repositorio de software

Muchos editores de software y otras organizaciones mantienen servidores en Internet para este fin, ya sea de forma gratuita o por una tarifa de suscripción. Los repositorios pueden ser únicamente para programas particulares, como CPAN para el lenguaje de programación Perl, o para un sistema operativo completo. Los operadores de estos repositorios suelen ofrecer un sistema de gestión de paquetes, herramientas destinadas a buscar, instalar y manipular los paquetes de software desde los repositorios. Por ejemplo, muchas distribuciones Linux utilizan Advanced Packaging Tool(APT), encontrado comúnmente en distribuciones basadas en Debian, o yum, encontrado en distribuciones basadas en Red Hat. También hay varios sistemas independientes de gestión de paquetes, como pacman, utilizados en Arch Linux y Equo, encontrados en Sabayon Linux.

Como los repositorios de software están diseñadas para incluir paquetes de útiles, los repositorios importantes están diseñados para estar libre de malware. Si un equipo está configurado para utilizar una firma digital de un repositorio de algún vendedor de confianza, combinado con un sistema de permisos adecuado, reduce significativamente la amenaza de malware en estos sistemas. Como efecto secundario, muchos sistemas que tienen estas capacidades no requieren software antivirus ni software anti-malware.

La mayoría de las principales distribuciones de Linux tienen muchos repositorios en todo el mundo que reflejan el repositorio principal.

Un sistema de gestión de paquetes es diferente de un proceso de desarrollo paquetes.

Un uso típico de un sistema de gestión de paquetes es facilitar la integración de código de posibles fuentes diferentes a una unidad operativa coherente e independiente. Por lo tanto, un sistema de gestión de paquetes podría ser utilizado para producir una distribución de Linux, posiblemente, una distribución adaptada a una aplicación restringida específica.

Un proceso de desarrollo de paquetes, por el contrario, se utiliza para gestionar el co-desarrollo de código y documentación de una colección de funciones o rutinas con un tema común, produciendo de esta manera un conjunto de funciones de software que normalmente no será completa y utilizable por sí mismos. Un buen proceso de desarrollo de paquetes ayudará a los usuarios, conforme a una buena documentación y prácticas de codificación, con la integración de cierto nivel de pruebas unitarias. La tabla más abajo proporciona ejemplos de procesos de desarrollo de paquetes.

La siguiente tabla muestra un par de lenguajes con los repositorios de software contribuido. La columna "Autochecks" describe los controles de rutina realizados.

Muy pocas personas tienen la posibilidad de probar su software en múltiples sistemas operativos con diferentes versiones del código del núcleo y con otros paquetes contribuido que pueden utilizar. Para R, la Red Archivo R Integral (CRAN), realiza pruebas de forma rutinaria. Para ver cuán valioso es esto, supongamos que Sally aporta un paquete A. Solo Sally ejecuta la versión actual del software en una versión de Microsoft Windows y solo se ha probado en ese entorno. A intervalos más o menos regulares, CRAN pone a prueba la contribución de Sally en una docena de combinaciones de sistemas operativos y versiones del software núcleo del lenguaje R. Si uno de ellos genera un error, se pone ese mensaje de error. Con suerte, ese mensaje de error puede ser suficiente para que le permita solucionar el error, incluso si ella no puede replicarlo con el hardware y software que tiene. A continuación, supongamos que John contribuye al repositorio un paquete B que utiliza un paquete A. El paquete B pasa todas las pruebas y se pone a disposición de los usuarios. Más tarde, Sally presenta una versión mejorada de A, que por desgracia, rompe B. Los autochecks hacen posible proporcionar información a John para que pueda solucionar el problema.

Este ejemplo expone a la vez una fortaleza y una debilidad en el sistema de paquetes contribuidos R: CRAN provee este tipo de pruebas automatizadas de paquetes contribuidos, pero los paquetes contribuido a CRAN no necesitan especificar las versiones de otros paquetes contribuidos que utilizan. Existen procedimientos para solicitar versiones específicas de paquetes, pero los contribuyentes no podrían utilizar esos procedimientos.

Más allá de esto, un repositorio como CRAN ejecuta comprobaciones regulares de paquetes contribuidos, en realidad ofrece un extenso conjunto de pruebas para las versiones de desarrollo del núcleo del lenguaje. Si Sally (en el ejemplo anterior) obtiene un mensaje de error que no entiende o cree inapropiado, sobre todo a partir de una versión de desarrollo del lenguaje, ella puede (y a menudo lo hace con R) pedir ayuda al equipo de desarrollo principal para el lenguaje. De esta manera, el repositorio puede contribuir a mejorar la calidad del software núcleo del lenguaje.

(Partes de esta tabla fueron copiadas de.[3])

Software para gestionar repositorios (gestores de repositorios) incluyen:

• Apache Archiva @– "software de gestión de repositorio para la construcción del repositorio de artefactos"[4]
• MyGet @– "servicio de entrega continua de alojamiento, 1000 de los repositorios de paquetes NuGet, Bower y NGP"[5]
• JFrog Artifactory @– "gestión de los binarios a lo largo del ciclo desarrollo"[6]
• Sonatype Nexus @– "utilizado por más de 20.000 organizaciones"[7]
• Paquete Drone @– "un repositorio gestor de paquetes de OSGi"[8]