Difference between revisions of "Arch packaging standards (Español)"
m (No mostraba "|| return 1") |
(→Directorios: Borro la referencia del directorio /usr/sbin, el mismo no se utiliza desde la actualización https://www.archlinux.org/news/binaries-move-to-usrbin-requiring-update-intervention/) |
||
(5 intermediate revisions by 4 users not shown) | |||
Line 5: | Line 5: | ||
[[fr:Standard paquetage]] | [[fr:Standard paquetage]] | ||
[[it:Arch Packaging Standards]] | [[it:Arch Packaging Standards]] | ||
+ | [[ja:Arch Packaging Standards]] | ||
[[pt:Arch Packaging Standards]] | [[pt:Arch Packaging Standards]] | ||
[[ru:Arch Packaging Standards]] | [[ru:Arch Packaging Standards]] | ||
Line 38: | Line 39: | ||
source=($pkgname-$pkgver.tar.gz) | source=($pkgname-$pkgver.tar.gz) | ||
noextract=() | noextract=() | ||
− | md5sums=() # | + | md5sums=() #generar con 'makepkg -g' |
build() { | build() { | ||
Line 71: | Line 72: | ||
{{bc|"_tuvariable"}} | {{bc|"_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 {{Ic|source}, 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 {{Ic|source}}, por ejemplo: |
− | {{bc|http://downloads.sourceforge.net/directxwine/$patchname.$patchver.diff.bz2}} | + | {{bc|source=(<nowiki>http://downloads.sourceforge.net/directxwine/$patchname.$patchver.diff.bz2</nowiki>)}} |
Esto evita el buen funcionamiento de AUR. | Esto evita el buen funcionamiento de AUR. | ||
Line 102: | Line 103: | ||
* Es una practica común el '''preservar el orden''' de los campos en el {{Ic|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'''. | * Es una practica común el '''preservar el orden''' de los campos en el {{Ic|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 == | == Nombramiento de paquetes == | ||
Line 124: | Line 124: | ||
|- | |- | ||
|{{Ic|/usr/bin}}||Binarios de la aplicación. | |{{Ic|/usr/bin}}||Binarios de la aplicación. | ||
− | |||
− | |||
|- | |- | ||
|{{Ic|/usr/lib}}||Librerias | |{{Ic|/usr/lib}}||Librerias | ||
Line 153: | Line 151: | ||
**/tmp | **/tmp | ||
**/var/tmp | **/var/tmp | ||
− | |||
== Tareas de Makepkg == | == Tareas de Makepkg == | ||
Line 261: | Line 258: | ||
</li> | </li> | ||
<li> | <li> | ||
− | Verifica '''las dependencias''' del paquete (p.ej. utiliza ldd en ejecutables dinámicos, comprueba las herramientas requeridas por los scripts, etc.) El equipo de TUs recomienda '''fervientemente''' el uso de la utilidad {{Ic|namcap}}, escrita por | + | Verifica '''las dependencias''' del paquete (p.ej. utiliza ldd en ejecutables dinámicos, comprueba las herramientas requeridas por los scripts, etc.) El equipo de TUs recomienda '''fervientemente''' el uso de la utilidad {{Ic|namcap}}, escrita por [https://www.archlinux.org/fellows/#jason Jason Chu], para analizar el saneamiento de los paquetes. {{Ic|namcap}} te avisará sobre permisos erróneos, dependencias que falten, dependencias innecesarias, y otros errores comunes. Puedes instalar el paquete {{Ic|namcap}} con pacman. Recuerda que {{Ic|namcap}} puede ser usado para comprobar los archivos pkg.tar.gz y PKGBUILDs |
</li> | </li> | ||
<li> | <li> | ||
Line 281: | Line 278: | ||
El paquete tar '''no debe''' contener el paquete tar binario creado por makepkg, ni debe contener la lista de archivos | El paquete tar '''no debe''' contener el paquete tar binario creado por makepkg, ni debe contener la lista de archivos | ||
</li> | </li> | ||
− | |||
== Guías Adicionales == | == Guías Adicionales == |
Revision as of 19:07, 16 March 2014
zh-CN:Arch Packaging Standards zh-TW:Arch Packaging Standards 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.
Contents
- 1 Prototipo de PKGBUILD
- 2 Reglas de etiquetado
- 3 Nombramiento de paquetes
- 4 Directorios
- 5 Tareas de Makepkg
- 6 Arquitecturas
- 7 Licencias
- 8 Enviar paquetes a AUR
- 9 Guías Adicionales
- 9.1 Paquetes VCS (SVN, GIT, HG, etc)
- 9.2 Paquetes de plugins de Eclipse
- 9.3 Paquetes de GNOME
- 9.4 Paquetes Go
- 9.5 Paquetes Haskell
- 9.6 Paquetes Java
- 9.7 Paquetes KDE
- 9.8 Paquetes de módulos del kernel
- 9.9 Paquetes Lisp
- 9.10 Paquetes OCaml
- 9.11 Paquetes Perl
- 9.12 Paquetes Python
- 9.13 Paquetes Ruby Gem
- 9.14 Paquetes Wine
- 9.15 Paquetes MinGW
Prototipo de PKGBUILD
# Maintainer: Tu Nombre <tuemail@mail.com> pkgname=NOMBREDELPAQUETE pkgver=VERSIONDELPAQUETE pkgrel=1 pkgdesc="" arch=() url="" license=('GPL') groups=() depends=() makedepends=() optdepends=() provides=() conflicts=() replaces=() backup=() options=() install= changelog= source=($pkgname-$pkgver.tar.gz) noextract=() md5sums=() #generar con 'makepkg -g' build() { cd "$srcdir/$pkgname-$pkgver" ./configure --prefix=/usr make } package() { cd "$srcdir/$pkgname-$pkgver" make DESTDIR="$pkgdir/" install }
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 {{Ic|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:
source=(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 entornoPACKAGER
antes de compilar el paquete conmakepkg
, 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/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:
- Verifica que las dependencias esten instaladas
- Descarga las fuentes del fichero desde el servidor
- Comprueba la integridad de las fuentes
- Desempaqueta las fuentes
- Parcha todo lo necesario
- Crea el software e instala en un directorio root falso
-
Elimina
/usr/doc
,/usr/info
,/usr/share/doc
, y/usr/share/info
desde el paquete - Obtiene simbolos desde los binarios
- Obtiene debugging symbols desde las librerias
- Genera el package meta file que es incluido en cada paquete
- Comprime el directorio root falso
- 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: {{Ic|/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: {{Ic|license=('GPL')}
- Si la licencia apropiada no se incluye en el paquete oficial de licencias, se pueden hacer vairas cosas
-
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"
- 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.
- 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 {{Ic|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.
Enviar paquetes a AUR
Asegurate de esto antes de subir un paquete a AUR:
- Los PKGBUILDs enviados NO DEBEN instalar aplicaciones que ya se encuentren en alguno de los repositorios oficiales bajo ninguna circunstancia. La única excepción a esta estricta regla pueden ser únicamente paquetes con características extra y/o parches en comparación con los oficiales. En tal caso la variable pkgname deberá ser diferente para expresar esa diferencia. Por ejemplo: Un PKGBUILD de GNU screen enviado que contiene el parche para la barra lateral, puede ser llamado screen-sidebar, etc. Adicionalmente la variable provides=('screen') deberá ser utilizada para evitar conflictos con el paquete oficial.
-
Para asegurar la seguridad de los paquetes enviados a AUR, por favor, asegúrate e que has rellenado correctamente el campo
md5sum
. Losmd5sum
pueden ser generados usando el comandomakepkg -g
. -
Por favor añade un comentario al principio del PKGBUILD con el siguiente formato. Recuerda disfrazar tu email para protejerlo del spam:
# Maintainer: Your Name <address at domain dot com>
Si asumes el rol de mantener un PKGBUILD existente, añade tu nombre al principio como se ha descrito y cambia el título del/los Mantenedor/es previo/s a Contribuidor
# Maintainer: Your Name <address at domain dot com> # Contributor: Previous Name <address at domain dot com>
-
Verifica las dependencias del paquete (p.ej. utiliza ldd en ejecutables dinámicos, comprueba las herramientas requeridas por los scripts, etc.) El equipo de TUs recomienda fervientemente el uso de la utilidad
namcap
, escrita por Jason Chu, para analizar el saneamiento de los paquetes.namcap
te avisará sobre permisos erróneos, dependencias que falten, dependencias innecesarias, y otros errores comunes. Puedes instalar el paquetenamcap
con pacman. Recuerda quenamcap
puede ser usado para comprobar los archivos pkg.tar.gz y PKGBUILDs - Las dependencias son el error de empaquetamiento más común. Namcap puede ayudar a detectarlos pero no siempre acierta. Verifica las dependencias mirando la documentación de las fuentes y la página web del programa.
-
No uses
replaces
en un PKGBUILD a no ser que el paquete vaya a ser renombrado, por ejemplo, cuando Ethereal se convirtió en Wireshark. Si el paquete es una versión alternativa de un paquete ya existente, usaconflicts
(yprovides
si el paquete es requerido por otros). La principal deferencia es: tras sincronizar (-Sy) pacman inmediatamente quere sustituir un 'ofensivo' paquete instalado cuando encuentra un paquete que lo incluya enreplaces
en cualquiera de sus repositorios;conflicts
por otro lado solo es evaluado cuando realmente instalas el paquete, que normalmente es el comportamiento deseado porque es menos invasivo. -
Todos los archivos subidos a AUR deben estar contenidos en un archivo tar comprimido que contenga un directorio con el
PKGBUILD
y archivos de instalación adicionales (parches, install, etc.) en el.foo/PKGBUILD foo/foo.install foo/foo_bar.diff foo/foo.rc.conf
El nombre del archivo debe contener el nombre del paquete, por ej. foo.tar.gz.
Cualquiera puede hacer un paquete tar que contenga los archivos requeridos utilizando
makepkg --source
. Esto creará un paquete tar llamado$pkgname-$pkgver-$pkgrel.src.tar.gz
, que puede ser subido a AUR.El paquete tar no debe contener el paquete tar binario creado por makepkg, ni debe contener la lista de archivos
Guías Adicionales
Asegúrate de leer antes esta guía - hay puntos importantes listados en esta página que no se van a repetir en las siguientes páginas de guías. Las guías específicas se han creado como un añadido a los estándars listados en esta página.
Paquetes VCS (SVN, GIT, HG, etc)
Por favor mira la Guía Arch de PKGBUILDs VCS
Paquetes de plugins de Eclipse
Por favor mira la Guía de empaquetamiento de plugins de Eclipse
Paquetes de GNOME
Por favor mira la Guía de empaquetamiento GNOME
Paquetes Go
Por favor mira la Guía para paquetes Go
Paquetes Haskell
Por favor mira la Guía de empaquetamiento Haskell
Paquetes Java
Por favor mira la Guía de empaquetamiento Java
Paquetes KDE
Por favor mira la Guía de empaquetamiento KDE
Paquetes de módulos del kernel
Por favor mira la Guía de empaquetamiento de Módulos del Kernel
Paquetes Lisp
Por favor mira la Guía de empaquetamiento Llisp
Paquetes OCaml
Por favor mira la Guía de empaquetamiento OCaml
Paquetes Perl
Por favor mira la Guía de empaquetamiento Perl
Paquetes Python
Por favor mira la Guía de empaquetamiento Python
Paquetes Ruby Gem
Por favor mira la Guía de empaquetamiento Ruby
Paquetes Wine
Por favor mira la Guía de empaquetamiento Wine
Paquetes MinGW
Por favor mira la Guía de empaquetamiento MinGW