Repositorio de software

Este artículo puede contener información no verificada o indiscriminada en listas incrustadas . Por favor, ayude a limpiar las listas eliminando elementos o incorporándolos al texto del artículo. ( Marzo de 2019 )

Un repositorio de software , o repo para abreviar, es un lugar de almacenamiento para paquetes de software . A menudo, también se almacena una tabla de contenidos, junto con metadatos. Un repositorio de software suele estar gestionado por el control de código fuente o de versiones , o por administradores de repositorios. Los administradores de paquetes permiten instalar y actualizar automáticamente repositorios, a veces llamados "paquetes".

Muchos editores de software y otras organizaciones mantienen servidores en Internet para este propósito, 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 dichos repositorios suelen proporcionar un sistema de gestión de paquetes , herramientas destinadas a buscar, instalar y manipular de otro modo los paquetes de software de los repositorios. Por ejemplo, muchas distribuciones de Linux utilizan Advanced Packaging Tool (APT), que se encuentra comúnmente en distribuciones basadas en Debian , o Yellowdog Updater, Modified ( yum ) que se encuentra en distribuciones basadas en Red Hat . También hay varios sistemas de gestión de paquetes independientes, como pacman, utilizado en Arch Linux y equo, que se encuentra en Sabayon Linux .

Así como los repositorios de software están diseñados para incluir paquetes útiles, los repositorios principales están diseñados para estar libres de malware . Si una computadora está configurada para usar un repositorio firmado digitalmente de un proveedor confiable y está acoplada con un sistema de permisos apropiado , esto reduce significativamente la amenaza de malware para estos sistemas. Como efecto secundario, muchos sistemas que tienen estas capacidades no necesitan software anti-malware como software antivirus . ^[1]

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

En el lado del cliente, un administrador de paquetes ayuda a instalar y actualizar los repositorios.

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

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

Por el contrario, un proceso de desarrollo de paquetes se utiliza para gestionar el desarrollo conjunto de código y documentación de una colección de funciones o rutinas con un tema común, produciendo así un paquete de funciones de software que normalmente no estarán completas ni serán utilizables por sí mismas. Un buen proceso de desarrollo de paquetes ayudará a los usuarios a cumplir con buenas prácticas de documentación y codificación, integrando algún nivel de pruebas unitarias .

La siguiente tabla enumera algunos lenguajes con repositorios de software contribuido. La columna "Comprobaciones automáticas" describe las comprobaciones rutinarias realizadas.

Muy pocas personas tienen la capacidad de probar su software en varios sistemas operativos con diferentes versiones del código central y con otros paquetes que puedan utilizar. Para el lenguaje de programación R , la Red Integral de Archivos R (CRAN) ejecuta pruebas de forma rutinaria.

Para entender lo valioso que es esto, imaginemos una situación con dos desarrolladores, Sally y John. Sally contribuye con un paquete A. Sally sólo ejecuta la versión actual del software bajo una versión de Microsoft Windows, y sólo lo ha probado en ese entorno. A intervalos más o menos regulares, CRAN prueba la contribución de Sally bajo una docena de combinaciones de sistemas operativos y versiones del software del lenguaje R principal. Si uno de ellos genera un error, ella recibe ese mensaje de error. Con suerte, los detalles de ese mensaje de error pueden proporcionar suficiente información para permitir una solución para el error, incluso si no puede replicarlo con su hardware y software actuales. A continuación, supongamos que John contribuye al repositorio con 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 envía una versión mejorada de A, que desafortunadamente, rompe B. Las comprobaciones automáticas permiten proporcionar información a John para que pueda solucionar el problema.

Este ejemplo expone tanto una fortaleza como una debilidad en el sistema de paquetes contribuidos de R: CRAN admite este tipo de prueba automatizada de paquetes contribuidos, pero los paquetes contribuidos a CRAN no necesitan especificar las versiones de otros paquetes contribuidos que utilizan. Existen procedimientos para solicitar versiones específicas de paquetes, pero los contribuidores podrían no utilizar esos procedimientos.

Además de esto, un repositorio como CRAN que realiza comprobaciones periódicas de los paquetes aportados proporciona en realidad un conjunto de pruebas extenso, aunque ad hoc, para las versiones de desarrollo del lenguaje principal. Si Sally (en el ejemplo anterior) recibe un mensaje de error que no entiende o que cree que es inapropiado, especialmente de una versión de desarrollo del lenguaje, puede (y a menudo lo hace con R) pedir ayuda al equipo de desarrollo principal del lenguaje. De esta manera, el repositorio puede contribuir a mejorar la calidad del software del lenguaje principal.

(Partes de esta tabla fueron copiadas de una "Lista de los principales repositorios por lenguaje de programación" en Stack Overflow ^[20] )

Muchos otros lenguajes de programación, entre ellos C , C++ y Fortran , no poseen un repositorio de software central con alcance universal. Entre los repositorios notables con alcance limitado se incluyen:

• Netlib , principalmente rutinas matemáticas para Fortran y C, históricamente uno de los primeros repositorios de software abierto;
• Boost , una colección estrictamente seleccionada de bibliotecas de alta calidad para C++; algunos códigos desarrollados en Boost luego pasaron a formar parte de la biblioteca estándar de C++.

Los administradores de paquetes ayudan a administrar los repositorios y su distribución. Si se actualiza un repositorio, un administrador de paquetes normalmente permitirá al usuario actualizar ese repositorio a través del administrador de paquetes. También ayudan a administrar cosas como las dependencias entre otros repositorios de software. Algunos ejemplos de administradores de paquetes incluyen:

En un entorno empresarial, un repositorio de software se utiliza generalmente para almacenar artefactos o para reflejar repositorios externos que pueden ser inaccesibles debido a restricciones de seguridad. Dichos repositorios pueden proporcionar funcionalidad adicional, como control de acceso, control de versiones, controles de seguridad para el software cargado, funcionalidad de clúster, etc. y, por lo general, admiten una variedad de formatos en un solo paquete, de modo de satisfacer todas las necesidades de una empresa y, por lo tanto, apuntar a proporcionar un único punto de verdad. Algunos ejemplos populares son JFrog Artifactory ^{[29] [30],} Sonatype Nexus Repository ^[31] y Cloudsmith ^[32] , un producto basado en la nube.

En el lado del servidor, un repositorio de software normalmente es administrado por el control de código fuente o los administradores de repositorios. Algunos de los administradores de repositorios permiten agregar otras ubicaciones de repositorios en una URL y proporcionar un proxy de almacenamiento en caché. Al realizar compilaciones continuas, se generan muchos artefactos y, a menudo, se almacenan de forma centralizada, por lo que es importante eliminar automáticamente los que no se publican.

Como parte del ciclo de vida del desarrollo, el código fuente se incorpora continuamente a artefactos binarios mediante la integración continua . Esto puede interactuar con un administrador de repositorio binario de forma muy similar a como lo haría un desarrollador al obtener artefactos de los repositorios y enviar las compilaciones allí. La estrecha integración con los servidores de integración continua permite el almacenamiento de metadatos importantes, como:

• ¿Qué usuario activó la compilación (ya sea manualmente o comprometiéndose con el control de revisión)?
• ¿Qué módulos se construyeron?
• ¿Qué fuentes se utilizaron (ID de confirmación, revisión, rama)?
• Dependencias utilizadas
• Variables de entorno
• Paquetes instalados

Los artefactos y los paquetes tienen significados diferentes. Los artefactos son simplemente una salida o una colección de archivos (p. ej., JAR, WAR, DLLS, RPM, etc.) y uno de esos archivos puede contener metadatos (p. ej., un archivo POM). Mientras que los paquetes son un único archivo de almacenamiento en un formato bien definido (p. ej., NuGet ) que contiene archivos apropiados para el tipo de paquete (p. ej., DLL, PDB). ^[33] Muchos artefactos son el resultado de las compilaciones, pero otros tipos también son cruciales. Los paquetes son esencialmente una de dos cosas: una biblioteca o una aplicación. ^[34]

En comparación con los archivos fuente, los artefactos binarios suelen ser órdenes de magnitud más grandes, rara vez se eliminan o sobrescriben (excepto en casos excepcionales como instantáneas o compilaciones nocturnas) y suelen estar acompañados de muchos metadatos como identificación, nombre del paquete, versión, licencia y más.

Los metadatos describen un artefacto binario, se almacenan y especifican por separado del artefacto en sí y pueden tener varios usos adicionales. La siguiente tabla muestra algunos tipos de metadatos comunes y sus usos: