COMO ACTUALIZAR UBUNTU... (parte 2)

HACIENDO UN REPASO:

En la anterior entrega, expuse como y cuando es permitido hacer una actualizacion, igualmente el uso de las secciones y mis recomendaciones de como utilizarlas, todo esto para tener actualizado nuestra versión de UBUNTU, de igual forma la orientación de cada repositorio, y su aplicación.

En esta nueva entrega, presentare a ustedes la forma en que esta configurado el área de repositorios y algunas recomendaciones para crear o añadir nuevos, sin afectar la estructura original del archivo principal. Entremos entonces en materia.

CONFIGURACION:

UBUNTU utiliza un concepto llamado REPOSITORIO, el funcionamiento de este, básicamente se puede comparar a la compra de productos en un super-mercado. Normalmente usando una carretilla, vamos depositando en ella todos los productos que creemos nos serán útiles, los repositorios funcionan exactamente de la misma forma, y claro en este concepto existen variedades de ellos, por ejemplo:

• los de casa: que son todos aquellos que están integrados por omisión en la propia distribución y que se integran al momento de instalarla.

• los de terceros: que corresponden a aquellos que no son soportados o distribuidos directamente por la casa, y por consiguiente no vienen incluidos dentro de la instalación.

• los propios o personalizados:, que son los que desarrollamos o personalizamos basados en un código fuente.

Para integrar aplicaciones propias o de terceros, UBUNTU utiliza un archivo llamado sources.list, el cual esta integrado en el directorio etc (etcétera) dentro del directorio apt, “/etc/apt/sources.list”, este archivo puede ser fácilmente modificado utilizando cualquiera de los editores que integra la distribución por ejemplo gedit, vi, etc. El archivo internamente utiliza conceptos como:

• ALMOHADILLA #: para denotar un comentario, todo lo que se encuentra después de este símbolo no tiene ningún efecto para la aplicación que lo lee.

• DEB: indica al interprete que debe descargar el código binario del software

• DEB-SRC: indica al interprete debe descargar el código fuente del software

• seguido de la palabra deb o deb-src deberá ser integrada la dirección ftp, del servidor que contiene la aplicación o software.

• UN ARGUMENTO PRINCIPAL: descrito por una palabra que indica generalmente el nombre de la distribución o versión de esta, por ejemplo hardy, intrepid, etc, y que corresponde al directorio que contiene dicha relación

• UN SIGUIENTE ARGUMENTO: el cual indica un sub-directorio en donde se encuentra la arquitectura de la distribución, normalmente son utilizadas palabras como main, multiverse, restricted, por nombrar algunas, y que indica el alcance y/o situación del software, es importante prestar atención a las recomendaciones del proveedor del repositorio, pues una mala selección de estos parámetros, puede que no de los resultados esperados, dentro de estos sub-directorios se encuentran las diferentes arquitecturas que corresponden a la versión o distribución de nuestro sistema operativo..

Descubierto esto, ahora podemos entender como esta configurado nuestro archivo sources.list, muchos amigos y colegas, lanzan una serie de modificaciones a este archivo, las cuales después de un buen tiempo, se convierten en un grave problema, pues algunos no se toman el tiempo para crear una copia de seguridad antes de modificarla, y oops se cumple la ley de Murphy, mi recomendación es que este archivo no debe ser tocado por ningún motivo o circunstancia. Pero no temáis, todo esta bajo control, y previsto desde el inicio, por los chicos de Canonical, “no contaban con mi astucia”, la solución es un directorio que reside al mismo nivel en que se encuentra el sources.list y que lleva el mismo nombre, adicionando a este la terminación .d, su nombre es sources.list.d, originalmente este directorio se encuentra totalmente vacío luego de una instalación limpia, y tiene la intensión de evitar la manipulación del archivo original llamado sources.list, pues bajo cualquier concepto siempre será mejor crear un archivo individual, conteniendo toda la información del repositorio y sus argumentos, siendo esta opción mas útil y mas limpia y si me lo permiten mas elegante.

Basado en el concepto anterior, lo recomendable es definitivamente "NO MODIFICAR EL ARCHIVO SOURCES.LIST" original de la distribución, de esa manera no tendremos ninguna sorpresa inesperada al momento de eliminar o re-estructurar nuestros repositorios.

Además es importante tener en cuenta que hay que evitar las duplicaciones de las entradas o de los repositorios, lo que en algunas situaciones puede ser provocada por situaciones como :

• Desconocimiento
• Cambio de ubicación del repositorio por parte del desarrollador
• Duplicación de la versión a causa que otros repositorios incluyen algunas versiones.

generalmente los repositorios mas conocidos o que generalmente están integrados con la distribución de UBUNTU son los que se encuentran en http://ppa.launchpad.net/
allí se pueden encontrar tanto los códigos binarios, como los fuentes, además del histórico de la trascendencia de cada proyecto y sus recomendaciones. Algo que también es importante tomar en cuenta, es que, en este sitio, podemos encontrar las correspondientes llaves de actualización proveidas por el desarrollador, para hacer que el proyecto sea valido como si se tratara de una llave de control, la cual incluye tambien una caducidad y una validz.

Como en la anterior entrega los espero en la parte 3 y ultima, donde voy a incluir esta vez la interacción de nuevos repositorios y su ejecución, hasta entonces me despido de ustedes. Ubuntizando desde Guatemala, saludos para todos.