Difference between revisions of "Arch packaging standards (Español)"

From ArchWiki
Jump to: navigation, search
m (Portuguese added)
(Aumento y mejora de la traducción de estándares para paquetes)
Line 14: Line 14:
 
==Estándares para paquetes==
 
==Estándares para paquetes==
  
Al crear paquetes para Arch Linux deberás <strong>seguir las directivas</strong> delineadas en este articulo, especialmente si deseas <strong>contribuir</strong> con tu paquete a la Distribución.
+
'''Los PKGBUILDs no deben instalar aplicaciones que ya se encuentren en los repositorios oficiales bajo ninguna circunstancia. La única excepción a esta regla son paquetes que contengan añadidos extra habilitados y/o parches en comparación con los oficiales. En tal caso, la variable pkgname deberá ser diferente.'''
 +
 
 +
Al crear paquetes para Arch Linux deberás <strong>seguir las directivas</strong> delineadas en este articulo, especialmente si deseas <strong>contribuir</strong> con tu paquete a la Distribución. También deberías leer los manuales de [https://www.archlinux.org/pacman/PKGBUILD.5.html PKGBUILD] y [https://www.archlinux.org/pacman/makepkg.8.html makepkg].
 +
 
 +
 
 +
== Prototipo de PKGBUILD ==
  
===Prototipo de PKGBUILD===
 
 
<pre>
 
<pre>
 
# Contributor: Tu Nombre <tuemail@domain.com>
 
# Contributor: Tu Nombre <tuemail@domain.com>
Line 47: Line 51:
 
</pre>
 
</pre>
  
===Reglas de Etiqueta===
+
Puedes encontrar otros prototipos en <code>/usr/share/pacman</code> de los paquetes de pacman y abs.
 +
 
 +
== Reglas de etiquetado ==
 +
 
 
* Los paquetes '''nunca''' deben ser instalados en <code>/usr/local</code>
 
* Los paquetes '''nunca''' deben ser instalados en <code>/usr/local</code>
  
* Siempre que sea posible utiliza '''<code>" || return 1"</code>''' en funciones importantes para la construcción del paquete. Por ejemplo:
+
* Siempre que sea posible utiliza '''<code> || return 1</code>''' en funciones importantes para la construcción del paquete. Por ejemplo:
 
   patch -Np1 -i ../patchfile.patch || return 1
 
   patch -Np1 -i ../patchfile.patch || return 1
 
   make || return 1
 
   make || return 1
 
   make DESTDIR=$startdir/pkg install || return 1
 
   make DESTDIR=$startdir/pkg install || return 1
  
* <strong>No introduzcas nuevas variables</strong> en tu script PKGBUILD, excepto cuando el paquete no puede ser construido sin ellas, debido a que pueden haber posibles confictos con las variables usadas por el propio <code>makepkg</code>. Si una nueva variable es absolutamente requerida, '''añade el prefijo "_" a su nombre''', por ejemplo "_tuvariable".<br>El sistema AUR no puede detectar el uso de variables no estándar, por ende no puede usarlas en substituciones, por ejemplo:<pre>http://downloads.sourceforge.net/directxwine/$patchname.$patchver.diff.bz2</pre>Esto derrota el objetivo detrás de muchas funciones del AUR.
+
* <strong>No introduzcas nuevas variables</strong> en tu script PKGBUILD, excepto cuando el paquete no puede ser construido sin ellas, debido a que pueden haber posibles confictos con las variables usadas por el propio <code>makepkg</code>. Si una nueva variable es absolutamente requerida, '''añade el prefijo "_" a su nombre''', por ejemplo:
  
* Evita usar <code>/usr/libexec</code> para lo que sea. Usa el directorio <code>/usr/lib/${pkgname}/</code> en su lugar.
+
<pre>"_tuvariable"</pre>
  
* El campo <code>packager</code> del meta-archivo del paquete puede ser '''ajustado''' por el creador del paquete modificando la opción apropiada en <code>/etc/makepkg.conf</code> o alternativamente exportando la variable de entorno <code>PACKAGER</code> antes de compilar el paquete con <code>makepkg</code>, por ejemplo:
+
El sistema AUR no puede detectar el uso de variables no estándar, por ende no puede usarlas en sustituciones. Esto puede ser visto frecuentemente en la variable <code>source</code>, por ejemplo:
 +
 
 +
<pre>http://downloads.sourceforge.net/directxwine/$patchname.$patchver.diff.bz2</pre>
 +
 
 +
Esto evita el buen funcionamiento de AUR.
 +
 
 +
* '''Evita''' usar <code>/usr/libexec</code>. Usa el directorio <code>/usr/lib/${pkgname}/</code> en su lugar.
 +
 
 +
* El campo <code>packager</code> del meta-archivo del paquete puede ser '''personalizado''' por el creador del paquete modificando la opción apropiada en <code>/etc/makepkg.conf</code>, creando <pre>~/.makepkg.conf,</pre> o alternativamente exportando la variable de entorno <code>PACKAGER</code> antes de compilar el paquete con <code>makepkg</code>, por ejemplo:
 
   # export PACKAGER="Juan Perez@tu.email"
 
   # export PACKAGER="Juan Perez@tu.email"
  
 
* Todos los mensajes importantes deben ser mostrados con el comando <code>echo</code> durante la instalación mediante el uso del archivo <code>.install</code>. Por ejemplo, si un paquete necesita trabajo adicional de configuración, las instrucciones deberían ser incluidas.  
 
* Todos los mensajes importantes deben ser mostrados con el comando <code>echo</code> durante la instalación mediante el uso del archivo <code>.install</code>. Por ejemplo, si un paquete necesita trabajo adicional de configuración, las instrucciones deberían ser incluidas.  
  
* Cualquier '''dependencia opcional''' que no es necesaria para ejecutar el paquete o su funcionamiento general no debe ser incluida, pero un mensaje de aviso debe enviarse dentro del archivo <code>.install</code>, por ejemplo "Para activar el soporte de SMB, descarga el paquete Samba".
+
* Cualquier '''dependencia opcional''' que no es necesaria para ejecutar el paquete o para su funcionamiento general no debe ser incluida, en su lugar, la información deberá añadirse en la variable '''optdepends''':
 +
<pre>
 +
optdepends=('cups: printing support'
 +
            'sane: scanners support'
 +
            'libgphoto2: digital cameras support'
 +
            'alsa-lib: sound support'
 +
            'giflib: GIF images support'
 +
            'libjpeg: JPEG images support'
 +
            'libpng: PNG images support')
 +
</pre>
 +
 
 +
Este ejemplo se toma del paquete '''wine''' en el repositorio <code>extra</code>. La información en optdepends se muestra automáticamente en la instalación/actualización, de manera que no se debe añadir este tipo de información en el archivo .install
  
 
* Al escribir la '''descripción del paquete''', no incluyas el nombre del paquete en un formato auto-referencial. Por ejemplo "Nedit es un editor de texto para X11" debería ser simplificado a "Editor de texto para X11". Intenta mantener las descripciones en aproximadamente 80 caracteres o menos.
 
* Al escribir la '''descripción del paquete''', no incluyas el nombre del paquete en un formato auto-referencial. Por ejemplo "Nedit es un editor de texto para X11" debería ser simplificado a "Editor de texto para X11". Intenta mantener las descripciones en aproximadamente 80 caracteres o menos.
Line 70: Line 96:
 
* Intenta mantener el '''ancho de linea''' de tu PKGBUILD debajo de los 100 caracteres.
 
* Intenta mantener el '''ancho de linea''' de tu PKGBUILD debajo de los 100 caracteres.
  
* Cuando sea posible '''remueve las lineas vacias''' de tu PKGBUILD.
+
* Cuando sea posible '''elimina las líneas vacias''' de tu <code>PKGBUILD</code> (<code>provides</code>, <code>replaces</code>, etc.)
 +
 
 +
* Es una practica común el '''preservar el orden''' de los campos en el <code>PKGBUILD</code> como se muestra más abajo. Aunque no es obligatorio debido a que el único requerimiento para esto es mantener la '''corrección de la sintaxis bash'''.
 +
 
  
* Es una practica común el '''preservar el orden''' de los campos en el PKGBUILD. Aunque no es obligatorio debido a que el único requerimiento para esto es mantener la corrección de la '''sintaxis bash'''.
+
== Nombramiento de paquetes ==
  
===Nombres de Paquetes===
 
 
* Los nombres de paquetes deben consistir '''solamente de caracteres alfanuméricos'''; todas las letras deberán ser minúsculas.
 
* Los nombres de paquetes deben consistir '''solamente de caracteres alfanuméricos'''; todas las letras deberán ser minúsculas.
  
* Las versiones de los paquetes deben '''ser las mismas que las usadas por el autor''' original del software. Las versiones pueden incluir letras si es necesario (ejemplo, la versión de nmap es 2.54BETA32). Los nombres de versión '''no deben incluir guiones!''' solo letras, numeros y puntos.
+
* Las versiones de los paquetes '''deben ser las mismas que las usadas por el autor''' original del software. Las versiones pueden incluir letras si es necesario (ejemplo, la versión de nmap es 2.54BETA32). Los nombres de versión ''¡'no deben incluir guiones!''' solo letras, numeros y puntos.
  
* Los números de liberación del paquete (ejemplo, el <code>-1</code> en nmap-2.54BETA32'''-1''') son '''especificos a Arch Linux'''. Estos permiten a los usuarios diferenciar entre un paquete viejo y uno nuevo. Cuando una nueva versión ''del paquete'' es liberada el contador '''se inicia en 1'''. Cuando correcciones y optimizaciones son realizadas, el paquete es redistribuido con un incremento de 1 en su numero de liberación. Cuando una nueva versión de ''la aplicación'' es distribuida el contador se reinicia a 1. Los números de liberación siguen las mismas directivas que los números de versión delineados en el ítem anterior.
+
* Los números de liberación del paquete (ejemplo, el <code>-1</code> en nmap-2.54BETA32'''-1''') son '''especificos a Arch Linux'''. Estos permiten a los usuarios diferenciar entre un paquete viejo y uno nuevo. Cuando una nueva versión ''del paquete'' es liberada el contador '''se inicia en 1'''. Cuando correcciones y optimizaciones son realizadas, el paquete es redistribuido con un incremento de 1 en su numero de liberación. Cuando una nueva versión de ''la aplicación'' es distribuida el contador se reinicia a 1. Los números de liberación siguen las mismas directivas que los números de versión.
  
  
===Directorios===
+
 
 +
== Directorios ==
 +
 
 
* Archivos de configuración deben almacenarse en el directorio <code>/etc</code>. Si existe mas de un archivo de configuración es costumbre '''utilizar un subdirectorio''' para mantener <code>/etc</code> lo mas limpio posible. Usa <code>/etc/{pkgname}/</code> cuando sea posible, o una alternativa relacionada, por ejemplo, apache utiliza <code>/etc/httpd</code>.
 
* Archivos de configuración deben almacenarse en el directorio <code>/etc</code>. Si existe mas de un archivo de configuración es costumbre '''utilizar un subdirectorio''' para mantener <code>/etc</code> lo mas limpio posible. Usa <code>/etc/{pkgname}/</code> cuando sea posible, o una alternativa relacionada, por ejemplo, apache utiliza <code>/etc/httpd</code>.
  
Line 121: Line 151:
 
**/var/tmp
 
**/var/tmp
  
===makepkg===
+
 
 +
== Tareas de Makepkg ==
 +
 
  
 
<p>
 
<p>
Cuando usas makepkg para crear un paquete, hace automaticamente lo siguiente:
+
Cuando usas [https://www.archlinux.org/pacman/makepkg.8.html makepkg] para crear un paquete, hace automaticamente lo siguiente:
 
</p>
 
</p>
  
Line 134: Line 166:
 
<strong>Descarga las fuentes</strong> del fichero desde el servidor
 
<strong>Descarga las fuentes</strong> del fichero desde el servidor
 
</li>
 
</li>
 
+
<li>
 +
<strong>Comprueba la integridad</strong> de las fuentes
 +
</li>
 
<li>
 
<li>
 
<strong>Desempaqueta</strong> las fuentes
 
<strong>Desempaqueta</strong> las fuentes
Line 172: Line 206:
  
 
</ol>
 
</ol>
 +
 +
 +
== Arquitecturas ==
 +
 +
La variable <code>arch</code> debe contener <code>'i686'</code> o <code>'x86_64'</code> dependiendo de las arquitecturas en las que se pueda instalar. También puedes usar <code>any</code> para paquetes que no dependen de la arquitectura.
 +
 +
== Licencias ==
 +
 +
La variable [https://wiki.archlinux.org/index.php/Licenses licence] está implementandose en los repositorios oficiales, y también '''debes''' usarla en tus paquetes. Úsala de la siguiente manera:
 +
 +
* Un paquete de licencias se ha creado en [core] y almacena licencias comunes en <code>/usr/share/licenses/common</code>, por ejemplo: <code>/usr/share/licenses/common/GPL</code>. Si un paquete está licenciado bajo una de esas licencias, la variable licenses se nombrará con el nombre del directorio. En el ejemplo anterior: <code>license=('GPL')</code>
 +
<p>
 +
* Si la licencia apropiada no se incluye en el paquete oficial de licencias, se pueden hacer vairas cosas
 +
</p>
 +
<ol>
 +
<li>
 +
El archivo de la licencia debe ser incluido en /usr/share/licenses/$pkgname/, por ejemplo:  /usr/share/licenses/dibfoo/LICENSE. Una buena forma de hacerlo es usando:
 +
<pre>install -D -m644 LICENSE "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"</pre>
 +
</li>
 +
<li>
 +
Si las fuentes NO contienen los detalles de la licencia, y la licencia solo se muestra por ejemplo en un sitio web, copia la licencia en un archivo e incluyelo. Recuerda también  llamarla de forma apropiada.
 +
</li>
 +
<li>
 +
Pon 'custom' en la variable de las licencias. Opcionalmente, puedes sustituir 'custom' por 'custom:"Nombre de la licencia"'.
 +
</li>
 +
</ol>
 +
*Una vez que las licencias se utilizan dos o más veces en un repositorio oficial, incluyendo [community], se convierte en común.
 +
*Las licencias MIT, BSD, zlib/libpng y Python son casos especiales y no se pueden incluir en el paquete de licencias 'comunes'. Por el bien de la variable <code>license</code>, se sigue tratando como una licencia común: (license=('BSD'), license=('MIT'), license=('ZLIB') or license=('Python')) pero por el bien del sistema, es una licencia personal (custom), porque cada una tiene su propia línea de copyright. Cada paquete con licencia MIT, BSD, zlib/libpng o Python debe tener su licencia individualmente almacenada en <code>/usr/share/licenses/$pkgname/</code>.
 +
* La (L)GPL tiene varias versiones y permutaciones de esas versiones. Para el software (L)GPL, la convención es:
 +
** (L)GPL - (L)GPLv2 o cualquier versión posterior.
 +
** (L)GPL2 - (L)GPLv2 solo.
 +
** (L)GPL3 - (L)GPLv3 o cualquier versión posterior.
 +
 +
--[[User:Jogre barroso|Jorge Barroso]] ([[User talk:Jogre barroso|talk]]) 00:55, 1 March 2013 (UTC)

Revision as of 00:55, 1 March 2013

Tango-preferences-desktop-locale.pngThis article or section needs to be translated.Tango-preferences-desktop-locale.png

Notes: please use the first argument of the template to provide more detailed indications. (Discuss in Talk:Arch packaging standards (Español)#)

Estándares para paquetes

Los PKGBUILDs no deben instalar aplicaciones que ya se encuentren en los repositorios oficiales bajo ninguna circunstancia. La única excepción a esta regla son paquetes que contengan añadidos extra habilitados y/o parches en comparación con los oficiales. En tal caso, la variable pkgname deberá ser diferente.

Al crear paquetes para Arch Linux deberás seguir las directivas delineadas en este articulo, especialmente si deseas contribuir con tu paquete a la Distribución. También deberías leer los manuales de PKGBUILD y makepkg.


Prototipo de PKGBUILD

# Contributor: Tu Nombre <tuemail@domain.com>
pkgname=NOMBREDELPAQUETE
pkgver=VERSIONDELPAQUETE
pkgrel=1
pkgdesc=""
arch=()
url=""
license=('GPL')
depends=()
makedepends=()
provides=()
conflicts=()
replaces=()
backup=()
groups=()
options=()
install=
source=($pkgname-$pkgver.tar.gz)
noextract=()
md5sums=(generate with makepkg -g)

build() {
  cd $startdir/src/$pkgname-$pkgver
  ./configure --prefix=/usr
  make || return 1
  make DESTDIR=$startdir/pkg install || return 1
}

Puedes encontrar otros prototipos en /usr/share/pacman de los paquetes de pacman y abs.

Reglas de etiquetado

  • Los paquetes nunca deben ser instalados en /usr/local
  • Siempre que sea posible utiliza || return 1 en funciones importantes para la construcción del paquete. Por ejemplo:
 patch -Np1 -i ../patchfile.patch || return 1
 make || return 1
 make DESTDIR=$startdir/pkg install || return 1
  • No introduzcas nuevas variables en tu script PKGBUILD, excepto cuando el paquete no puede ser construido sin ellas, debido a que pueden haber posibles confictos con las variables usadas por el propio makepkg. Si una nueva variable es absolutamente requerida, añade el prefijo "_" a su nombre, por ejemplo:
"_tuvariable"

El sistema AUR no puede detectar el uso de variables no estándar, por ende no puede usarlas en sustituciones. Esto puede ser visto frecuentemente en la variable source, por ejemplo:

http://downloads.sourceforge.net/directxwine/$patchname.$patchver.diff.bz2

Esto evita el buen funcionamiento de AUR.

  • Evita usar /usr/libexec. Usa el directorio /usr/lib/${pkgname}/ en su lugar.
  • El campo packager del meta-archivo del paquete puede ser personalizado por el creador del paquete modificando la opción apropiada en /etc/makepkg.conf, creando
    ~/.makepkg.conf,
    o alternativamente exportando la variable de entorno PACKAGER antes de compilar el paquete con makepkg, por ejemplo:
 # export PACKAGER="Juan Perez@tu.email"
  • Todos los mensajes importantes deben ser mostrados con el comando echo durante la instalación mediante el uso del archivo .install. Por ejemplo, si un paquete necesita trabajo adicional de configuración, las instrucciones deberían ser incluidas.
  • Cualquier dependencia opcional que no es necesaria para ejecutar el paquete o para su funcionamiento general no debe ser incluida, en su lugar, la información deberá añadirse en la variable optdepends:
optdepends=('cups: printing support'
            'sane: scanners support'
            'libgphoto2: digital cameras support'
            'alsa-lib: sound support'
            'giflib: GIF images support'
            'libjpeg: JPEG images support'
            'libpng: PNG images support')

Este ejemplo se toma del paquete wine en el repositorio extra. La información en optdepends se muestra automáticamente en la instalación/actualización, de manera que no se debe añadir este tipo de información en el archivo .install

  • Al escribir la descripción del paquete, no incluyas el nombre del paquete en un formato auto-referencial. Por ejemplo "Nedit es un editor de texto para X11" debería ser simplificado a "Editor de texto para X11". Intenta mantener las descripciones en aproximadamente 80 caracteres o menos.
  • Intenta mantener el ancho de linea de tu PKGBUILD debajo de los 100 caracteres.
  • Cuando sea posible elimina las líneas vacias de tu PKGBUILD (provides, replaces, etc.)
  • Es una practica común el preservar el orden de los campos en el PKGBUILD como se muestra más abajo. Aunque no es obligatorio debido a que el único requerimiento para esto es mantener la corrección de la sintaxis bash.


Nombramiento de paquetes

  • Los nombres de paquetes deben consistir solamente de caracteres alfanuméricos; todas las letras deberán ser minúsculas.
  • Las versiones de los paquetes deben ser las mismas que las usadas por el autor' original del software. Las versiones pueden incluir letras si es necesario (ejemplo, la versión de nmap es 2.54BETA32). Los nombres de versión ¡'no deben incluir guiones! solo letras, numeros y puntos.
  • Los números de liberación del paquete (ejemplo, el -1 en nmap-2.54BETA32-1) son especificos a Arch Linux. Estos permiten a los usuarios diferenciar entre un paquete viejo y uno nuevo. Cuando una nueva versión del paquete es liberada el contador se inicia en 1. Cuando correcciones y optimizaciones son realizadas, el paquete es redistribuido con un incremento de 1 en su numero de liberación. Cuando una nueva versión de la aplicación es distribuida el contador se reinicia a 1. Los números de liberación siguen las mismas directivas que los números de versión.


Directorios

  • Archivos de configuración deben almacenarse en el directorio /etc. Si existe mas de un archivo de configuración es costumbre utilizar un subdirectorio para mantener /etc lo mas limpio posible. Usa /etc/{pkgname}/ cuando sea posible, o una alternativa relacionada, por ejemplo, apache utiliza /etc/httpd.
  • Los archivos de cada paquete deben seguir las siguientes directivas:
/etc Archivos de configuración.
/usr/bin Binarios de la aplicación.
/usr/sbin Binarios del sistema.
/usr/lib Librerias
/usr/include Cabeceras (archivos .h)
/usr/lib/{pkgname} Módulos, agregados (plugins), etc.
/usr/man Paginas del manual.
/usr/share/{pkgname} Datos de la aplicación (temas, iconos, etc.).
/etc/{pkgname} Archivos de configuración adicionales de {pkgname}.
/opt Paquetes grandes y autocontenidos como KDE, Mozilla, Qt, etc.
  • Los paquetes no deben contener los siguientes directorios:
    • /dev
    • /home
    • /media
    • /mnt
    • /proc
    • /root
    • /selinux
    • /sys
    • /tmp
    • /var/tmp


Tareas de Makepkg

Cuando usas makepkg para crear un paquete, hace automaticamente lo siguiente:

  1. Verifica que las dependencias esten instaladas
  2. Descarga las fuentes del fichero desde el servidor
  3. Comprueba la integridad de las fuentes
  4. Desempaqueta las fuentes
  5. Parcha todo lo necesario
  6. Crea el software e instala en un directorio root falso
  7. Elimina /usr/doc, /usr/info, /usr/share/doc, y /usr/share/info desde el paquete
  8. Obtiene simbolos desde los binarios
  9. Obtiene debugging symbols desde las librerias
  10. Genera el package meta file que es incluido en cada paquete
  11. Comprime el directorio root falso
  12. Almacena el paquete en el directorio de destino configurado (cwd por defecto)


Arquitecturas

La variable arch debe contener 'i686' o 'x86_64' dependiendo de las arquitecturas en las que se pueda instalar. También puedes usar any para paquetes que no dependen de la arquitectura.

Licencias

La variable licence está implementandose en los repositorios oficiales, y también debes usarla en tus paquetes. Úsala de la siguiente manera:

  • Un paquete de licencias se ha creado en [core] y almacena licencias comunes en /usr/share/licenses/common, por ejemplo: /usr/share/licenses/common/GPL. Si un paquete está licenciado bajo una de esas licencias, la variable licenses se nombrará con el nombre del directorio. En el ejemplo anterior: license=('GPL')

  • Si la licencia apropiada no se incluye en el paquete oficial de licencias, se pueden hacer vairas cosas

  1. El archivo de la licencia debe ser incluido en /usr/share/licenses/$pkgname/, por ejemplo: /usr/share/licenses/dibfoo/LICENSE. Una buena forma de hacerlo es usando:
    install -D -m644 LICENSE "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"
  2. Si las fuentes NO contienen los detalles de la licencia, y la licencia solo se muestra por ejemplo en un sitio web, copia la licencia en un archivo e incluyelo. Recuerda también llamarla de forma apropiada.
  3. Pon 'custom' en la variable de las licencias. Opcionalmente, puedes sustituir 'custom' por 'custom:"Nombre de la licencia"'.
  • Una vez que las licencias se utilizan dos o más veces en un repositorio oficial, incluyendo [community], se convierte en común.
  • Las licencias MIT, BSD, zlib/libpng y Python son casos especiales y no se pueden incluir en el paquete de licencias 'comunes'. Por el bien de la variable license, se sigue tratando como una licencia común: (license=('BSD'), license=('MIT'), license=('ZLIB') or license=('Python')) pero por el bien del sistema, es una licencia personal (custom), porque cada una tiene su propia línea de copyright. Cada paquete con licencia MIT, BSD, zlib/libpng o Python debe tener su licencia individualmente almacenada en /usr/share/licenses/$pkgname/.
  • La (L)GPL tiene varias versiones y permutaciones de esas versiones. Para el software (L)GPL, la convención es:
    • (L)GPL - (L)GPLv2 o cualquier versión posterior.
    • (L)GPL2 - (L)GPLv2 solo.
    • (L)GPL3 - (L)GPLv3 o cualquier versión posterior.

--Jorge Barroso (talk) 00:55, 1 March 2013 (UTC)