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

From ArchWiki
Jump to: navigation, search
(New page: Category:Sobre Arch Category:Administración de Paquetes Category:Desarrollo de Paquetes Category:Directivas {{i18n_links_start}} {{i18n_entry|English|Arch_Packaging_Stan...)
 
Line 49: Line 49:
 
}
 
}
 
</pre>
 
</pre>
 +
 +
===Reglas de Etiqueta===
 +
* 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:
 +
  patch -Np1 -i ../patchfile.patch || return 1
 +
  make || 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 in 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.
 +
 +
* Evita usar <code>/usr/libexec</code> para lo que sea. Usa el directorio <code>/usr/lib/${pkgname}/</code> en su lugar.
 +
 +
* 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:
 +
  # 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.
 +
 +
* 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".
 +
 +
* 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 *remueve las lineas vacias* de tu PKGBUILD.
 +
 +
* 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*.

Revision as of 16:23, 30 October 2007

Template:I18n links start Template:I18n entry Template:I18n entry Template:I18n entry Template:I18n entry Template:I18n links end

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

Al crear paquetes para Arch Linux deberás seguir las directivas delineadas en este articulo, especialmente si deseas contribuir tu paquete a la Distribución.

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
}

Reglas de Etiqueta

  • 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 in 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 substituciones, por ejemplo:
    http://downloads.sourceforge.net/directxwine/$patchname.$patchver.diff.bz2
    Esto derrota el objetivo detrás de muchas funciones del AUR.
  • Evita usar /usr/libexec para lo que sea. Usa el directorio /usr/lib/${pkgname}/ en su lugar.
  • El campo packager del meta-archivo del paquete puede ser *ajustado* por el creador del paquete modificando la opción apropiada en /etc/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 </code>echo</code> 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 su funcionamiento general no debe ser incluida, pero un mensaje de aviso debe enviarse dentro del archivo .install, por ejemplo "Para activar el soporte de SMB, descarga el paquete Samba".
  • 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 *remueve las lineas vacias* de tu PKGBUILD.
  • 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*.