Cómo mejorar la presentación de nuestros bloques de código

El día de ayer en la entrada Ctrl + Alt + Supr en ubuntu el amigo (gracias al canal ubuntu-es en el servidor Freenode) Red me preguntaba lo siguiente:

quisiera saber que plugin de WP usas para que salga en un recuadro los comandos de la terminal?

Ahora bien, como en principio la pregunta no tiene que ver con la temática de la entrada, además, mi respuesta puede que sea algo extensa, prefiero responderle a través de esta entrada.

En realidad para la presentación de los bloques de código no hago uso de ningún agregado, solo uso correctamente (sin animos de parecer ostentoso) las etiquetas que nos ofrece el lenguaje de marcado XHTML (lenguaje extensible de marcado de hipertexto), dándole semántica a la estructura de la entrada, la presentación de dicho bloque de código lo realizo a través del uso de CSS (hojas de estilo en cascada).

En primer lugar vamos a ver como debe ser la estructura de los bloques de código.

<code><pre><code>#include <iostream>

int main()
{
std::cout << "Hola Mundo!!!" << std::endl;
return 0;
}
</code></pre></code>

Vea el ejemplo #1.

El bloque de código anterior muestra un programa muy sencillo en C++.

Estructura XHTML

Es hora de definir algunos conceptos muy interesantes.

El elemento <pre>

En primer lugar debemos recordar que el elemento <pre> es un elemento en bloque, los agentes de usuario visuales entenderán que el texto contenido dentro de este elemento vendrá con un formato previo.

Lo anterior implica ciertas ventajas, por ejemplo, pueden dejarse espacios en blanco, los cuales serán interpretados tal cual como se manifiestan de manera explícita. Adicionalmente, se pueden representar fuentes de ancho fijo dentro de estos bloques.

El elemento <code>

El elemento es un elemento en línea, la semántica detrás de este elemento es indicar segmentos de código.

Mejorando la presentación del bloque de código

Una vez que comprendamos la estructura que deben seguir nuestros bloques de código, debemos hacer uso de las hojas de estilos en cascada para la presentación de dichos bloques. Esto será necesario realizarlo una sola vez.

Mi gusto particular es centrar los bloques de código, esto no tiene porque ser entonces una regla estándar, a continuación describiré como realizar esto vía CSS, solamente debemos seguir las siguientes reglas.

<code>pre{
  text-align: center;
  width: 30em;
  margin: 1em auto;
  white-space: pre; /* CSS 2 */
}
pre code{
  display: block;
  text-align: left;
}</code>

Vea el ejemplo #2.

Al selector pre le he asignado una anchura de 30em, este valor es relativo a la fuente, pero también podría especificarse en px, es importante resaltar que haciendo uso de la unidad em se permite generar un bloque líquido.

La declaración que está realizando todo el trabajo de centrar el bloque es margin: 1em **auto**;, en ella se indica que tanto el margen superior como inferior sea de 1em, de igual manera se especifica que tanto el margen izquierdo como el derecho sean auto, por lo tanto, sus valores serán iguales, esto nos asegura que la caja quede centrada.

Ahora bien, para brindar mayor accesibilidad a nuestro bloque de código, será necesario hacer uso de la propiedad text-align: center; en el selector pre, la razón por la cual se usa la declaración anterior es para brindar una buena presentación en aquellos usuarios de IE5 bajo sistemas Windows. Sin esta regla, la mayoría de los agentes de usuario visuales podrán mostrar el bloque de código centrado, pero no aquellos usuarios de IE5/Win.

La declaración white-space: pre; se utiliza para especificar como serán tratados los espacios en blanco dentro del elemento. Cuando se indica el valor pre los agentes de usuario visuales impedirán el cierre de las secuencias de espacios en blanco.

Finalmente, en el selector pre code, debemos reescribir la declaración de alineación del texto (text-align). En ella estamos alineando el texto de nuevo a la izquierda, si no lo hacemos, el texto se mostrará centrado debido a la declaracion de alineación de texto en el selector pre.

El uso de la declaración display: block; modifica la manera en que se muestra el elemento code, como se mencionó previamente, el elemento code es un elemento en línea, al hacer uso de esta instrucción, nos permitirá mostrar al elemento code como un elemento en bloque.

Ahora bien, todavía existe una interrogante que debemos contestar, dicha interrogante es: ¿Qué sucede si el contenido del bloque de código es demasiado extenso horizontalmente?, simplemente el texto se desbordará por encima del bloque, esto es un problema, pero existen dos maneras de solucionarlo.

¿Cómo solucionar un posible desborde del contenido sobre el bloque de código?

La primera solución que podriamos pensar es hacer uso de la declaración overflow: auto;, la propiedad overflow especifica si el contenido de un elemento en bloque puede ser recortado o nó cuando éste desborda a dicho elemento. El valor auto nos permite proporcionar un mecanismo de desplazamiento en el caso de aquellas cajas que presenten un desborde.

La solución anterior también implica otra inquietud, en este caso particular, la usabilidad, según el gurú de la usabilidad, Jakob Nielsen, los usuarios detestan el tener que hacer uso de las barras de desplazamiento horizontales, el parecer el desplazamiento vertical parece estar bien, puesto que es más común.

Por los motivos descritos en el párrafo anterior, el hacer uso de la barra de desplazamiento horizontal no es la mejor solución. Veamos la solucion definitiva.

La única posibilidad que tenemos para evitar hacer uso de la barra de desplazamiento horizontal es que al ocurrir un desborde, el contenido que desborda pase a la siguiente línea.

Ahora bien, lo que se mostrará a continuación puede resultarle confuso, no se preocupe, trataré de explicarlo, pero recuerde, no soy ningún experto, solo un entusiasta :)

<code>pre{
  /* Reglas especificas para algunos navegadores y CSS 3 */
  white-space: -moz-pre-wrap; /* Mozilla, soportado desde 1999 */
  white-space: -hp-pre-wrap; /* Impresoras HP */
  white-space: -o-pre-wrap; /* Opera 7 */
  white-space: -pre-wrap; /* Opera 4-6 */
  white-space: pre-wrap; /* CSS 2.1 */
  white-space: pre-line; /* CSS 3 (y 2.1 tambien, actualmente) */
  word-wrap: break-word; /* IE 5.5+ */</code>

Vea el archivo maestro.

La versión original del código mostrado previamente pertenece a Ian Hickson quien distribuye su trabajo bajo licencia GPL.

Bajo CSS2, no existe una manera explícita de indicar que los espacios y nuevas líneas deban preservarse, pero en el caso en el cual el texto alcance el extremo del bloque que le contiene, se le puede envolver. Lo más cercano que nos podemos encontrar es white-space: pre, sino no es posible envolverlo. Antes de que CSS2.1 sea la recomendación candidata, los agentes de usuario no podrán implementarla, por eso se han implementado ciertas extensiones propietarias, en el código mostrado previamente se muestran todas estas posibilidades, los agentes de usuario tomarán aquellas declaraciones que soporten.

La declaración word-wrap: break-word es una extensión propietaria de IE, la cual no es parte de ningún estándar.

Para dejar las cosas en claro, pre-wrap actúa como pre pero cubrirá cuando sea necesario, mientras que pre-line actúa como normal pero preserva nuevas líneas. Según la opinión de Lim Chee Aun, la propiedad pre-wrap será realmente útil en aquellos casos en los cuales deban mostrarse largas líneas de código que posiblemente desborden en otros elementos o simplemente se muestren fuera de pantalla.

Ahora bien, ¿qué hay del soporte de los agentes de usuario visuales?, bien, la mayoría de los navegadores modernos soportan correctamente la propiedad pre, normal y nowrap. Firefox soporta la propiedad -moz-pre-wrap pero no soporta pre-wrap y pre-line todavía. Opera 8 soporta pre-wrap incluyendo sus extensiones previas, -pre-wrap y -o-pre-wrap, pero no pre-line.

Referencias:

6 min read

Ctrl + Alt + Supr en Ubuntu

Si usted alguna vez llegó a preguntarse como lograr abrir el Monitor del Sistema al presionar las teclas Ctrl + Alt + Supr, comportamiento similar bajo sistemas Windows, en el Blog de Bairsairk responden dicha inquietud.

Simplemente debe utilizar los siguientes comandos bajo el Terminal.

$ gconftool-2 -t str --set /apps/metacity/global_keybindings/run_command_9 "<Control><alt>Delete"
$ gconftool-2 -t str --set /apps/metacity/keybinding_commands/command_9 "gnome-system-monitor"

Simplemente copie y pegue :)

~1 min read

deskbar-applet, realiza tus búsquedas desde el escritorio

deskbar-applet en funcionamiento deskbar-applet es una de esas aplicaciones que parecen no tener mucho sentido en un principio, pero desde el mismo momento en que comienzas a utilizarla se te facilitan muchas actividades cotidianas.

deskbar-applet provee una versátil interfaz de búsqueda, incluso, puede abrir aplicaciones, ficheros, búsquedas locales (se integra complemente con beagle si lo tienes instalado) o directamente en internet; aquellos términos que desee buscar, simplemente tendrá que escribirlos dentro de la casilla correspondiente en el panel. En caso de escribir una dirección de correo electrónico en la barra de búsqueda se le brindará la opción de escribir un correo al destinario que desee.

Si desea probarlo es muy sencilla su instalación. En primer lugar debe tener activa la sección universe en su lista de repositorios.

deb http://us.archive.ubuntu.com/ubuntu breezy universe
deb-src http://us.archive.ubuntu.com/ubuntu breezy universe

Una vez que haya editado el fichero /etc/apt/sources.list debe actualizar la nueva lista de paquetes.

$ sudo aptitude update

Seguidamente puede proceder a instalar el paquete deskbar-applet, para ello simplemente haga.

$ sudo aptitude install deskbar-applet

Una vez culminado el proceso de instalación debe activar deskbar-applet (esta aplicación aparece en la sección de Accesorios) para que aparezca en el panel que desee, recuerde que para agregar un elemento al panel simplemente debe hacer click con el botón derecho del mouse y seleccionar la opción Añadir al panel.

Su uso es muy sencillo, posee una combinación de teclas (Alt + F3) que le facilitará enfocar la casilla de entrada, inmediatamente podrá comenzar a escribir.

1 min read

Los Repositorios

Contenido:

  1. Definición
  2. ¿Cómo funcionan los Repositorios?
  3. ¿Cómo establecer Repositorios? 1. Los Repositorios Automáticos 2. Los Repositorios Triviales
  4. ¿Cómo crear ficheros Index?
  5. ¿Cómo crear ficheros Release?
  6. ¿Cómo crear Estanques? 1. Herramientas
  7. ¿Cómo usar los Repositorios?

Los Repositorios (definición)

Un repositorio es un conjunto de paquetes Debian organizados en un directorio en árbol especial, el cual también contiene unos pocos ficheros adicionales con los índices e información de los paquetes. Si un usuario añade un repositorio a su fichero sources.list, él puede ver e instalar facilmente todos los paquetes disponibles en éste al igual que los paquetes contenidos en Debian.

¿Cómo funcionan los repositorios?

Un repositorio consiste en al menos un directorio con algunos paquetes DEB en él, y dos ficheros especiales que son el Packages.gz para los paquetes binarios y el Sources.gz para los paquetes de las fuentes. Una vez que tu repositorio esté listado correctamente en el sources.list, si los paquetes binarios son listados con la palabra clave deb al principio, apt-get buscará en el fichero índice Packages.gz, y si las fuentes son listadas con las palabras claves deb-src al principio, éste buscará en el fichero indice Sources.gz. Ésto se debe a que en el fichero Packages.gz se encuentra toda la información de todos los paquetes, como nombre, version, tamaño, descripción corta y larga, las dependencias y alguna información adicional que no es de nuestro interés. Toda la información es listada y usada por los Administradores de Paquetes del sistema tales como dselect o aptitude. Sin embargo, en el fichero Sources.gz se encuentran listados todos los nombres, versiones y las dependencias de desarrollo (esto es, los paquetes necesitados para compilar) de todos los paquetes, cuya información es usada por apt-get source y herramientas similares.

Una vez que hayas establecido tus repositorios, serás capaz de listar e instalar todos sus paquetes junto a los que vienen en los discos de instalación Debian; una vez que hayas añadido el repositorio deberás ejecutar en la consola:

$ sudo apt-get update

Ésto es con el fin de actualizar la base de datos de nuestro APT y así el podrá “decirnos” cuales paquetes disponemos con nuestro nuevo repositorio. Los paquetes serán actualizados cuando ejecutemos en consola.

$ sudo apt-get upgrade

¿Cómo establecer Repositorios?

Existen dos tipos de repositorios: los complejos, que es donde el usuario sólo tiene que especificar la ruta base de el repositorio, la distribución y los componentes que él quiera (APT automáticamente buscará los paquetes correctos para la arquitectura correspondiente, si están disponibles), y los más simples, donde el usuario debe especificar la ruta exacta (aqui APT no hará magia para encontrar cuales de los paquetes son los indicados). El primero es más difícil de establecer, pero es más fácil de utilizar, y siempre debería ser usado para repositorios complejos y/o plataformas cruzadas; el último, es más fácil de establecer, pero sólo debería ser usado para repositorios pequeños o de una sola arquitectura.

Aunque no es realmente correcto, aquí llamaré al primero Repositorios Automáticos y al último Repositorios Triviales.

Repositorios Automáticos

La estructura del directorio de un repositorio automático con las arquitecturas estándares de Debian y sus componentes se asemeja mucho a ésto:

(tu repositorio root)
|
+-dists
  |
  |-stable
  | |-main
  | | |-binary-alpha
  | | |-binary-arm
  | | |-binary-...
  | | +-source
  | |-contrib
  | | |-binary-alpha
  | | |-binary-arm
  | | |-binary-...
  | | +-source
  | +-non-free
  |   |-binary-alpha
  |   |-binary-arm
  |   |-binary-...
  |   +-source
  |
  |-testing
  | |-main
  | | |-binary-alpha
  | | |-binary-arm
  | | |-binary-...
  | | +-source
  | |-contrib
  | | |-binary-alpha
  | | |-binary-arm
  | | |-binary-...
  | | +-source
  | +-non-free
  |   |-binary-alpha
  |   |-binary-arm
  |   |-binary-...
  |   +-source
  |
  +-unstable
    |-main
    | |-binary-alpha
    | |-binary-arm
    | |-binary-...
    | +-source
    |-contrib
    | |-binary-alpha
    | |-binary-arm
    | |-binary-...
    | +-source
    +-non-free
      |-binary-alpha
      |-binary-arm
      |-binary-...
      +-source

Los paquetes libres van en el directorio main; los que no son libres van en el directorio non-free y los paquetes libres que dependen de los que no son libres van en el directorio contrib.

Existen también otros directorios poco comunes que son el non-US/main que contienen paquetes que son libres pero que no pueden ser exportados desde un servidor en los Estados Unidos y el directorio non-US/non-free que contiene paquetes que tienen alguna condición de licencia onerosa que restringe su uso o redistribución. No pueden ser exportados de los Estados Unidos porque son paquetes de software de cifrado que no están gestionados por el procedimiento de control de exportación que se usa con los paquetes de main o no pueden ser almacenados en servidores en los Estados Unidos por estar sujetos a problemas de patentes.

Actualmente Debian soporta 11 tipos de arquitecturas; en éste ejemplo se han omitido la mayoría de ellas por el bien de la brevedad. Cada directorio binary-* contiene un fichero Packages.gz y un fichero opcional Release; cada directorio fuente contiene un fichero Sources.gz y también contiene un fichero opcional Release.

Nota que los paquetes no tienen que estar en el mismo directorio como los ficheros índices, porque los ficheros índices contienen las rutas a los paquetes individuales; de hecho, podrían estar ubicados en cualquier lugar en el repositorio. Ésto hace posible poder crear estanques.

Somos libres de crear tantas distribuciones como componentes y llamarlos como queramos; las que se usan en el ejemplo son, justamente las usadas en Debian. Podríamos, por ejemplo, crear las distribuciones current y beta (en vez de stable, unstable y testing, y que los componentes sean foo, bar, baz y qux (en lugar de main, contrib y non-free).

Ya que somos libres de llamar los componentes como queramos, siempre es recomendable usar las distribuciones estándar de Debian, porque son los nombres que los usuarios de Debian esperan.

Repositorios Triviales

Los repositorios triviales, consisten en un directorio raíz y tantos sub-directorios como deseemos. Como los usuarios tienen que especificar la ruta a la raíz del repositorio y la ruta relativa entre la raíz y el directorio con los ficheros indices en él, somos libres de hacer lo que queramos (inclusive, colocar todo en la raíz del repositorio; entonces, la ruta relativa simplemente sería /. Se parecen mucho a ésto:

(your repository root)
|
|-binary
+-source

¿Cómo crear ficheros Index?

dpkg-scanpackages es la herramienta con la que podemos generar el fichero Packages y con la herramienta dpkg-scansources creamos los ficheros Sources. Ellos pueden enviar sus salidas a stout; por consiguiente, para generar ficheros comprimidos, podemos usar una cadena de comandos como ésta:

$ dpkg-scanpackages arguments | gzip -9c > Packages.gz

Las dos herramientas trabajan de la misma manera; ambas toman dos argumentos (en realidad son más, pero aquí no hablaremos de eso; puedes leerte las páginas del manual si quieres saber más); el primer argumento es el directorio en cual están los paquetes, y el segundo es el fichero predominante. En general no necesitamos los ficheros predominantes para repositorios simples, pero como éste es un argumento requerido, simplemente lo pasamos a /dev/null. dpkg-scanpackages escanea los paquetes .deb, sin embargo, dpkg-scansources escanea los ficheros .dsc, por lo tanto es necesario colocar los ficheros .orig.gz, .diff.gz y .dsc juntos. Los ficheros .changes no son necesarios. Así que, si tienes un repositorio trivial como el mostrado anteriormente, puedes crear los dos ficheros indice de la siguiente manera:

$ cd my-repository
$ dpkg-scanpackages binary /dev/null | gzip -9c > binary/Packages.gz
$ dpkg-scansources source /dev/null | gzip -9c > source/Sources.gz

Ahora bien, si tienes un repositorio tan complejo como el mostrado en el primer ejemplo, tendrás que escribir algunos scripts para automatizar éste proceso. También puedes usar el argumento pathprefix de las dos herramientas para simplificar un poco la sintaxis.

¿Cómo crear ficheros Release?

Si quieres permitirle a los usuarios de tu repositorio usar el pinning con tu repositorio, entonces deberás incluir un fichero Release en cada directorio que contenga un fichero Index. (Puedes leer más acerca del pinning en el COMO APT). Los ficheros Release son ficheros de texto simple y cortos que tienen una forma muy parecida a la que sigue:

Archive: archivo
Component: componente
Origin: TuCompañia
Label: TuCompañia Debian repositorio
Architecture: arquitectura
  • Archive: El nombre de la distribución de Debian. Los paquetes en éste directorio pertenecen a (o estan diseñados para), por ejemplo, stable, testing o unstable.
  • Component: Aquí van los componentes de los paquetes en el directorio, por ejemplo, main, non-free o contrib.
  • Origin: El nombre de la persona que hizo los paquetes.
  • Label: Algunas etiquetas adecuadas para los paquetes de tu repositorio. Usa tu imaginación.
  • Architecture: La arquitectura de lo paquetes en éste directorio, como i386 por ejemplo, sparc o fuente. Es importante que se establezcan Architecture y Archive de manera correcta, ya que ellos son más usados para hacer pinning. Los otros, sin embargo, son menos importantes en éste aspecto.

¿Cómo crear estanques?

Con los repositorios automáticos, distribuir los paquetes en los diferentes directorios puede tornarse rápidamente en una bestia indomable, además también se gasta mucho espacio y ancho de banda, y hay demasiados paquetes (como los de la documentación, por ejemplo) los cuales son los mismos para todas las arquitecturas.

En éstos casos, una posible solución es un estanque. Un estanque es un directorio adicional dentro del directorio raíz del repositorio, que contiene todos los paquetes (los binarios para todas las arquitecturas, distribuciones y componente y todas las fuentes). Se pueden evitar muchos problemas, a través de una combinación inteligente de ficheros predominantes (tema que no se toca en éste documento) y de scripts. Un buen ejemplo de un reposotorio “estancado” es el propio repositorio de Debian.

Los estanques sólo son útiles para repositorio grandes. Nunca he hecho uno y no creo que lo haga en un futuro cercano y ésa es la razón por la cual no se explica como hacerlo aquí. Si tu crees que esa sección debería ser añadida siéntete libre de escribir una y contáctame luego.

Herramientas

Existen varias herramientas para automatizar y facilitar la creación de ficheros Debian. A continuación son listados los más importantes:

  • apt-ftparchive: Es la línea de comandos de la herramienta usada para generar los ficheros indice que APT utiliza para accesar a la fuente de una distribución.
  • apt-move: Es usado para mover una colección de ficheros paquetes de Debian a un fichero jerárquico como el usado en el fichero oficial Debian. Éste es parte del paquete apt-utils.

¿Cómo usar los repositorios?

Usar un repositorio es muy sencillo, pero ésto depende de el tipo de repositorio que hayas creado, ya sea binario o de fuentes, automático o trivial. Cada repositorio ocupa una línea en el fichero sources.list. Para usar un repositorio binario solo tenemos que usar deb al principio de la línea y para usar un repositorio de fuentes, en vez de deb, sólo tenemos que agregrar deb-src. Cada línea tiene la siguiente sintaxis:

deb|deb-src uri distribución [componente1] [componente2] [...]

El URI es el Identificador Universal de Recursos de la raíz del repositorio, como por ejemplo: ftp://ftp.tusitio.com/debian, http://tusitio.com/debian, o, para ficheros locales, file::///home/joe/mi-repositorio-debian/. Donde la barra inclinada es opcional. Para repositorios automáticos, tienes que especificar la distribución y uno o más componentes; la distribución no debe terminar con una inclinada.

A continuación unos ejemplos de repositorios:

deb ftp://sunsite.cnlab-switch.ch/mirror/debian/ unstable main contrib non-free
deb-src ftp://sunsite.cnlab-switch.ch/mirror/debian/ unstable main contrib non-free
deb file:///home/aisotton/rep-exact binary/
deb-src file:///home/aisotton/rep-exact source/

Donde los dos primeros se corresponden con repositorios de tipo Automático y los dos últimos Triviales.

Lista de paquetes en la distribución estable de Debian. Lista de paquetes en la distribución testing de Debian Lista de paquetes en la distribución inestable de Debian

Artículo original Debian Repository HOWTO por Aaron Isotton

9 min read

El fichero sources.list

La mayoría de los entusiastas de sistemas Linux, tarde o temprano llegan a toparse con ésta interrogante. En una forma bastante general, podríamos definir a éste fichero como la lista de recursos de paquetes que es usada para localizar los ficheros del sistema de distribución de paquetes usado en el sistema. Este fichero de control está ubicado en la carpeta /etc/apt/ de nuestro sistema. El fichero es un simple documento de texto sencillo que puede ser modificado con cualquier editor de textos.

Dentro de éste fichero nos vamos a encontrar una serie de líneas, que no son más que las procedencias de los recursos ubicados en los repositorios que elijamos. Éstas líneas de procedencias tienen una forma general que es: tipo, uri, distribución y complementos.

Entonces, las formas generales de las líneas de procedencias sería así:

deb uri distribución [componente1] [componente2] [...]
deb-src uri distribución [componente1] [componente2] [...]

¿Qué debo saber sobre el sources.list?

Debemos tener en cuenta varios aspectos sobre éste fichero tan importante. Por ejemplo, hay algo que muchos no saben e ignoran, y es que ésta lista de procedencias está diseñada para soportar cualquier número y distintos tipos de procedencias, por supuesto, la demora del proceso de actualización de la base de datos del APT va a ser proporcional al número de procedencias, ya que mientras más procedencias, mayor es la cantidad de paquetes a añadir a la base de datos, y también va a durar un poco más de tiempo, dependiendo de nuestra velocidad de conexión.

El fichero lista una procedencia por línea, con la procedencia de mayor prioridad en la primera línea, como por ejemplo, cuando tenemos los paquetes en discos CD-ROM, entonces ubicamos éste de primero. Como ya mencioné, el formato de cada línea es:

tipo  uri  distribución complementos

Donde:

  • tipo: Determina el formato de los argumentos, que pueden ser de dos tipos: deb y deb-src. El tipo deb hace referencia a un típico archivo de Debian de dos niveles, que son distribución y componente, sin embargo, el tipo deb-src hace referencia al código fuente de la distribución y tiene la misma sintaxis que las de tipo deb. Las líneas de tipo deb-src son necesarias si queremos descargar un índice de los paquetes que tienen el código fuente disponible, entonces de ésta forma obtendremos los códigos originales, más un fichero de control, con extensión .dsc y un fichero adicional diff.gz, que contiene los cambios necesario para debianizar el código.
  • uri: Identificador Universal de Recursos, ésto es, el tipo de recurso de la cual estamos obteniendo nuestros paquetes. Pero ¿Cuáles son los tipos de uri que admite nuestra lista de procedencias? A continuación hago mención de las más populares, por así decirlo: * CD-ROM: El cdrom permite a APT usar la unidad de CD-ROM local. Se puede usar el programa apt-cdrom para añadir entradas de un cdrom al fichero sources.list de manera automática, en modo consola.
    • FTP: Especifica un servidor FTP como archivo. * HTTP: Especifica un servidor HTTP como archivo.
    • FILE: Permite considerar como archivo a cualquier fichero en el sistema de ficheros. Esto es útil para particiones montadas mediante NFS (sistema de ficheros usado para montar particiones de sistemas remotos) y réplicas locales.
  • distribución: Aquí especificamos la distribución en la cual estamos trabajando, bien sea Debian, Ubuntu, Kubuntu, Gnoppix,Knoppix y otras, basadas en sistemas Debian GNU/Linux. distribución también puede contener una variable, $(ARCH), que se expandirá en la arquitectura de Debian usada en el sistema (i386, m68k, powerpc,…). Esto permite que sources.list no sea dependiente de la arquitectura del sistema.
  • componentes: Los componentes son los tipos de repositorios clasificados según las licencias de los paquetes que contienen. Dentro de los componentes tenemos main, contrib y non-free, para usuarios Debian; sin embargo para usuarios Ubuntu, por ejemplo, también existen universe, multiverse restricted. Ahora la decisión de cuales repositorios utilizar, eso va más allá de lo pueda ser explicado acá, ya que eso le concierne a su persona.

Entonces, la forma de una línea de procedencias quedaría algo así:

# deb http://security.ubuntu.com/ubuntu breezy-security main restricted
# deb-src http://security.ubuntu.com/ubuntu breezy-security main restricted

Ahora bien, se preguntarán ¿Por qué el carácter # (almohadilla) al principio de la línea? Bueno, la respuesta es muy simple. Éste caracter se utiliza para indicarle al APT cuando ignorar, por así decirlo, las líneas que contengan dicho caracter al principio, pues lo que hace en realidad es tomarlas como comentarios de lenguaje y simplemente no las interpreta, por lo tanto, si queremos que el APT tome o no en cuenta una línea de procedencias, entonces quitamos o añadimos el caracter, respectivamente.

Nota del autor: Algunas partes de este artículo fueron tomadas del manual de Debian.

3 min read