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

From ArchWiki
Jump to navigation Jump to search
m (Updated related articles and names to spanish)
(articulo traducido)
Line 11: Line 11:
 
[[zh-hans:Arch packaging standards]]
 
[[zh-hans:Arch packaging standards]]
 
[[zh-hant:Arch packaging standards]]
 
[[zh-hant:Arch packaging standards]]
 +
{{TranslationStatus (Español)|Arch packaging standards|2018-10-10|507402}}
 
{{Related articles start (Español)}}
 
{{Related articles start (Español)}}
{{Related2|Creating packages (Español)|Crear paquetes}}
+
{{Related|Creating packages (Español)}}
{{Related2|PKGBUILD (Español)|PKGBUILD}}
+
{{Related|PKGBUILD (Español)}}
{{Related2|makepkg (Español)|makepkg}}
+
{{Related|makepkg (Español)}}
 
{{Related|Arch Build System (Español)}}
 
{{Related|Arch Build System (Español)}}
 
{{Related|Arch User Repository (Español)}}
 
{{Related|Arch User Repository (Español)}}
 
{{Related articles end}}
 
{{Related articles end}}
'''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].
+
Al crear paquetes para Arch Linux deberá '''adherirse a las pautas para los paquetes''' de abajo, especialmente si desea '''contribuir''' con un nuevo paquete a Arch Linux. También debería 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 ==
  
 
{{bc|1=
 
{{bc|1=
# Maintainer: Tu Nombre <tuemail@mail.com>
+
# Maintainer: su nombre <su-email@mail.com>
pkgname=NOMBREDELPAQUETE
+
pkgname=NOMBRE_DEL_PAQUETE
pkgver=VERSIONDELPAQUETE
+
pkgver=VERSIÓN_DEL_PAQUETE
 
pkgrel=1
 
pkgrel=1
 
pkgdesc=""
 
pkgdesc=""
Line 62: Line 62:
 
}}
 
}}
  
 +
Puede encontrar otros prototipos en {{ic|/usr/share/pacman}} para los paquetes de pacman y abs.
  
 +
== Reglas de etiquetado de paquetes ==
  
Puedes encontrar otros prototipos en {{Ic|/usr/share/pacman}} de los paquetes de pacman y abs.
+
* Los paquetes '''nunca''' deben ser instalados en {{ic|/usr/local}}
 
+
* '''No introduzca nuevas variables o funciones''' en el script {{ic|PKGBUILD}}, excepto cuando el paquete no puede ser compilado sin ellas, debido a que puede haber posibles '''confictos''' con las variables usadas por el propio makepkg.
== Reglas de etiquetado ==
+
*Si una nueva variable o función es absolutamente requerida, '''añádale a su nombre un guión bajo de prefijo '''({{ic|_}}), por ejemplo {{bc|1=variable-personal=}}
 
+
* '''Evite''' utilizar {{ic|/usr/libexec/}}. Utilice {{ic|/usr/lib/$pkgname/}} en su lugar.
* Los paquetes '''nunca''' deben ser instalados en {{Ic|/usr/local}}
+
* El campo {{ic|packager}} del metaarchivo del paquete puede ser '''personalizado''' por el creador del paquete modificando la opción apropiada en el archivo {{ic|/etc/makepkg.conf}}, o alternativamente sobrescribiendo al crear {{ic|~/.makepkg.conf}}.
 
+
* Todos los mensajes importantes deben ser mostrados con la orden {{ic|echo}} durante la instalación mediante el uso del archivo {{ic|.install}}. Por ejemplo, si un paquete necesita trabajo adicional de configuración, las instrucciones deberían ser incluidas.  
* Siempre que sea posible utiliza <code>|| return 1</code> en funciones importantes para la construcción del paquete. Por ejemplo:
+
*  Las '''dependencias''' son el error de empaquetado más común. Tómese un tiempo para verificarlas cuidadosamente, por ejemplo ejecutando {{ic|ldd}} en ejecutables dinámicos, verificando las herramientas requeridas por los scripts o mirando la documentación del software. La utilidad [[namcap]] puede ayudarle en este sentido. Esta herramienta puede analizar tanto los PKGBUILD como el paquete resultante y le advertirá sobre permisos incorrectos, las dependencias que faltan, las dependencias redundantes y otros errores comunes.
  patch -Np1 -i ../patchfile.patch || return 1
+
* Cualquier '''dependencia opcional''' que no sea 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 matriz '''optdepends''':
  make || return 1
+
:{{bc|<nowiki>
  make DESTDIR=$startdir/pkg install || return 1
+
optdepends=('cups: printing support'
 
 
* <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 {{Ic|makepkg}. Si una nueva variable es absolutamente requerida, '''añade el prefijo "_" a su nombre''', por ejemplo:
 
 
 
{{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:
 
 
 
{{bc|source&#61;(<nowiki>http://downloads.sourceforge.net/directxwine/$patchname.$patchver.diff.bz2</nowiki>)}}
 
 
 
Esto evita el buen funcionamiento de AUR.
 
 
 
* '''Evita''' usar {{Ic|/usr/libexec}}. Usa el directorio {{Ic|/usr/lib/${pkgname}/}} en su lugar.
 
 
 
* El campo {{Ic|packager}} del meta-archivo del paquete puede ser '''personalizado''' por el creador del paquete modificando la opción apropiada en {{Ic|/etc/makepkg.conf}}, creando {{bc|~/.makepkg.conf,}} o alternativamente exportando la variable de entorno {{Ic|PACKAGER}} antes de compilar el paquete con {{Ic|makepkg}}, por ejemplo:
 
  # export PACKAGER="Juan Perez@tu.email"
 
 
 
* Todos los mensajes importantes deben ser mostrados con el comando {{Ic|echo}} durante la instalación mediante el uso del archivo {{Ic|.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''':
 
{{bc|optdepends&#61;('cups: printing support'
 
 
             'sane: scanners support'
 
             'sane: scanners support'
 
             'libgphoto2: digital cameras support'
 
             'libgphoto2: digital cameras support'
Line 99: Line 81:
 
             'giflib: GIF images support'
 
             'giflib: GIF images support'
 
             'libjpeg: JPEG images support'
 
             'libjpeg: JPEG images support'
             'libpng: PNG images support')}}
+
             'libpng: PNG images support')
 +
</nowiki>}}
 +
:Este ejemplo toma del paquete '''wine''' presente en el repositorio {{ic|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 {{ic|.install}}
 +
* Al escribir la '''descripción del paquete''', no incluya el nombre del paquete en un formato autorreferencial. Por ejemplo «Nedit es un editor de texto para X11» debería ser simplificado a «Editor de texto para X11». Intente mantener las descripciones dentro de aproximadamente 80 caracteres o menos.
 +
* Intente mantener el '''ancho de linea''' del PKGBUILD por debajo de los 100 caracteres.
 +
* Cuando sea posible '''elimine las líneas vacías''' de {{ic|PKGBUILD}} ({{ic|provides}}, {{ic|replaces}}, etc.)
 +
* 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 de bash'''.
 +
* '''Entrecomille''' variables  que pueden contener espacios, como {{ic|"$pkgdir"}} y {{ic|"$srcdir"}}.
 +
* Para garantizar la '''integridad''' de los paquetes, asegúrese de que las [[PKGBUILD#Integrity|variables de integridad]] contengan los valores correctos. Estas se pueden actualizar utilizando la herramienta {{ic|updpkgsums}}.
  
Este ejemplo se toma del paquete '''wine''' en el repositorio {{Ic|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
+
== Nominación de paquetes ==
  
* 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.
+
* Los nombres de paquetes deben contener solamente caracteres alfanuméricos, incluido los siguientes {{ic|@}}, {{ic|.}}, {{ic|_}}, {{ic|+}}, {{ic|-}}. No se permite que los nombres comiencen con guiones o puntos. Todas las letras deben estar en minúsculas.
 +
* Los nombres de los paquetes NO deben tener el sufijo del número de versión de lanzamiento principal en sentido ascendente (por ejemplo, no usaremos libfoo2 si el flujo ascendente lo llama libfoo v2.3.4) en caso de que la biblioteca y sus dependencias que se esperan puedan seguir usando la versión de la biblioteca más reciente  con su respectivo lanzamiento en sentido ascendente. Sin embargo, para algunos programas o dependencias, esto no puede ser asumido. En el pasado, esto ha sido especialmente cierto para los conjuntos de herramientas de ''widgets'' como GTK y Qt. El software que depende de dichos conjuntos de herramientas generalmente no puede ser portado si más a una nueva versión principal. Como tal, en los casos en que el software no puede seguir funcionando sin más junto con sus dependencias, los nombres de los paquetes deben incluir el sufijo de la versión principal (por ejemplo, gtk2, gtk3, qt4, qt5). Para los casos en los que la mayoría de las dependencias pueden continuar con la versión más reciente, pero algunas no pueden (por ejemplo, el código privativo que necesita libpng12 o similar), una versión obsoleta de ese paquete podría llamarse libfoo1, mientras que la versión actual sería solo libfoo.
 +
* 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 (por ejemplo, la versión de nmap es 2.54BETA32). Las etiquetas de la versión no deben incluir guiones, solo letras, numeros y puntos.
 +
* Las liberacones de paquetes  son '''especificos para 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 pone en 1'''. Cuando se realizan correcciones y optimizaciones, el paquete es redistribuido '''incremento en 1 su numero de liberación'''. Cuando sale una nueva versión, el recuento de lanzamientos se restablece en 1. Las etiquetas de liberación de paquetes siguen las '''mismas restricciones de denominación que las etiquetas de versión'''.
  
* Intenta mantener el '''ancho de linea''' de tu PKGBUILD debajo de los 100 caracteres.
+
== Directorios ==
  
* Cuando sea posible '''elimina las líneas vacias''' de tu {{Ic|PKGBUILD}} ({{Ic|provides}}, {{Ic|replaces}}, etc.)
+
* Los '''archivos de configuración''' deben localizarse en el directorio {{ic|/etc}}. Si existe mas de un archivo de configuración es costumbre '''utilizar un subdirectorio''' para mantener {{ic|/etc}} lo mas limpio posible. Utilice {{ic|/etc/{pkgname}/}} donde {{ic|<nowiki>{pkgname}</nowiki>}} es el nombre del paquete (o un lugar alternativo, por ejemplo,  apache utiliza {{ic|/etc/httpd/}}).
  
* 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'''.
+
* Los archivos de cada paquete deben seguir estas '''directrices generales de directorios'':
  
== 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 {{Ic|-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 {{Ic|/etc}}. Si existe mas de un archivo de configuración es costumbre '''utilizar un subdirectorio''' para mantener {{Ic|/etc}} lo mas limpio posible. Usa{{Ic|/etc/{pkgname}/}} cuando sea posible, o una alternativa relacionada, por ejemplo, apache utiliza {{Ic|/etc/httpd}}.
 
 
* Los archivos de cada paquete deben seguir las siguientes directivas:
 
 
:{|
 
:{|
 
|-
 
|-
|{{Ic|/etc}}||Archivos de configuración.
+
| {{ic|/etc}}
 +
| Archivos de configuración '''esenciales del sistema'''
 +
|-
 +
| {{ic|/usr/bin}}
 +
| Binarios de aplicaciones
 +
|-
 +
| {{ic|/usr/lib}}
 +
| Bibliotecas
 +
|-
 +
| {{ic|/usr/include}}
 +
| Cabeceras de archivos
 
|-
 
|-
|{{Ic|/usr/bin}}||Binarios de la aplicación.
+
| {{ic|<nowiki>/usr/lib/{pkg}</nowiki>}}
 +
| Módulos, complementos, etc.
 
|-
 
|-
|{{Ic|/usr/lib}}||Librerias
+
| {{ic|<nowiki>/usr/share/doc/{pkg}</nowiki>}}
 +
| Application documentation
 
|-
 
|-
|{{Ic|/usr/include}}||Cabeceras (archivos .h)
+
| {{ic|/usr/share/info}}
 +
| Archivos info del sistema GNU
 
|-
 
|-
|{{Ic|/usr/lib/{pkgname}}}||Módulos, agregados (plugins), etc.
+
| {{ic|/usr/share/man}}
 +
| Páginas de manuales
 
|-
 
|-
|{{Ic|/usr/man}}||Paginas del manual.
+
| {{ic|<nowiki>/usr/share/{pkg}</nowiki>}}
 +
| Datos de aplicaciones
 
|-
 
|-
|{{Ic|/usr/share/{pkgname}}}||Datos de la aplicación (temas, iconos, etc.).
+
| {{ic|<nowiki>/var/lib/{pkg}</nowiki>}}
 +
| Almacén persistente de aplicaciones
 
|-
 
|-
|{{Ic|/etc/{pkgname}}}||Archivos de configuración adicionales de {pkgname}.
+
| {{ic|<nowiki>/etc/{pkg}</nowiki>}}
 +
| Archivos de configuración para {{ic|<nowiki>{pkg}</nowiki>}}
 
|-
 
|-
|{{Ic|/opt}}||Paquetes grandes y autocontenidos como KDE, Mozilla, Qt, etc.
+
| {{ic|<nowiki>/opt/{pkg}</nowiki>}}
 +
| Paquetes grandes y autocontenidos
 
|}
 
|}
  
* Los paquetes '''no''' deben contener los siguientes directorios:
+
* Los paquetes no deben contener ninguno de los siguientes directorios:
**/dev
+
** {{ic|/bin}}
**/home
+
** {{ic|/sbin}}
**/media
+
** {{ic|/dev}}
**/mnt
+
** {{ic|/home}}
**/proc
+
** {{ic|/srv}}
**/root
+
** {{ic|/media}}
**/selinux
+
** {{ic|/mnt}}
**/sys
+
** {{ic|/proc}}
**/tmp
+
** {{ic|/root}}
**/var/tmp
+
** {{ic|/selinux}}
 
+
** {{ic|/sys}}
== Tareas de Makepkg ==
+
** {{ic|/tmp}}
 
+
** {{ic|/var/tmp}}
 
+
** {{ic|/run}}
<p>
 
Cuando usas [https://www.archlinux.org/pacman/makepkg.8.html makepkg] para crear un paquete, hace automaticamente lo siguiente:
 
</p>
 
 
 
<ol>
 
<li>
 
Verifica que las <strong>dependencias</strong> esten instaladas
 
</li>
 
<li>
 
<strong>Descarga las fuentes</strong> del fichero desde el servidor
 
</li>
 
<li>
 
<strong>Comprueba la integridad</strong> de las fuentes
 
</li>
 
<li>
 
<strong>Desempaqueta</strong> las fuentes
 
</li>
 
<li>
 
<strong>Parcha</strong> todo lo necesario
 
</li>
 
<li>
 
 
 
<strong>Crea</strong> el software e instala en un directorio root falso
 
</li>
 
<li>
 
<strong>Elimina</strong> {{Ic|/usr/doc}},
 
{{Ic|/usr/info}}, {{Ic|/usr/share/doc}}, y
 
{{Ic|/usr/share/info}} desde el paquete
 
</li>
 
  
<li>
+
== Deberes de makepkg ==
<strong>Obtiene</strong> simbolos desde los binarios
 
</li>
 
<li>
 
<strong>Obtiene</strong> debugging symbols desde las librerias
 
</li>
 
<li>
 
Genera el <strong>package meta file</strong> que es
 
incluido en cada paquete
 
</li>
 
  
<li>
+
Cuando se utiliza [[makepkg]] para compilar un paquete, este hace lo siguiente automáticamente:
<strong>Comprime</strong> el directorio root falso
 
</li>
 
<li>
 
<strong>Almacena</strong> el paquete en el directorio de destino configurado
 
(<span title="Current Working Directory" style="border-bottom:1px dotted">cwd</span> por
 
defecto)
 
</li>
 
 
 
</ol>
 
  
 +
# Comprueba si el paquete tiene '''dependencias''' y '''makedepends''' instaladas.
 +
# '''Descarga las fuentes''' desde los servidores.
 +
# '''Comprueba la integridad''' de los archivos fuentes.
 +
# '''Desempaca''' los archivos fuentes.
 +
# Realiza cualquier '''parche''' necesario.
 +
# '''Compila''' el software y lo instala en una raíz falsa.
 +
# '''Quita''' los símbolos de los binarios.
 +
# '''Quita''' y depuralos símbolos de las bibliotecas.
 +
# '''Comprime''' las páginas de manual y/o información.
 +
# Genera el '''archivo meta del paquete''' que se incluye con cada paquete.
 +
# '''Comprime''' la raíz falsa en el archivo del paquete.
 +
# '''Almacena''' el archivo del paquete en el directorio de destino configurado  (<span title="Directorio de trabajo actual" style="border-bottom: 1px dotted">cwd</span> por defecto).
  
 
== Arquitecturas ==
 
== Arquitecturas ==
  
La variable {{Ic|arch}} debe contener {{Ic|'i686'}} o {{Ic|'x86_64'}} dependiendo de las arquitecturas en las que se pueda instalar. También puedes usar {{Ic|any}} para paquetes que no dependen de la arquitectura.
+
La variable {{ic|arch}} debe contener {{ic|'x86_64'}} si el paquete compilado es específico de dicha arquitectura. Utilice {{ic|'any'}} para paquetes que no dependen de la arquitectura.
  
 
== Licencias ==
 
== Licencias ==
  
La variable [[Licenses|licence]] está implementandose en los repositorios oficiales, y también '''debes''' usarla en tus paquetes. Úsala de la siguiente manera:
+
Consulte [[PKGBUILD#license]].
 
 
* Un paquete de licencias se ha creado en [core] y almacena licencias comunes en {{Ic|/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')}
 
<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:
 
{{bc|install -D -m644 LICENSE "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"}}
 
</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 {{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 {{Ic|/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:
 
<ol>
 
<li>
 
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.
 
</li>
 
<li>
 
Para asegurar la seguridad de los paquetes enviados a AUR, por favor, '''asegúrate''' e que has rellenado correctamente el campo {{Ic|md5sum}}. Los {{Ic|md5sum}} pueden ser generados usando el comando {{Ic|makepkg -g}}.
 
</li>
 
<li>
 
Por favor '''añade un comentario''' al principio del PKGBUILD con el siguiente formato. Recuerda disfrazar tu email para protejerlo del spam:
 
{{bc|# 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
 
{{bc|# Maintainer: Your Name <address at domain dot com>
 
# Contributor: Previous Name <address at domain dot com>}}
 
</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 [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>
 
'''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.
 
</li>
 
<li>
 
No uses {{Ic|'''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, usa {{Ic|conflicts}} (y {{Ic|provides}} 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 en {{Ic|replaces}} en cualquiera de sus repositorios; {{Ic|conflicts}} por otro lado solo es evaluado cuando realmente instalas el paquete, que normalmente es el comportamiento deseado porque es menos invasivo.
 
</li>
 
<li>
 
Todos los archivos subidos a AUR deben estar contenidos en un archivo '''tar comprimido que contenga un directorio con el''' {{Ic|PKGBUILD}} '''y''' archivos de instalación adicionales '''(parches, install, etc.) en el'''.
 
{{bc|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 {{Ic|makepkg --source}}. Esto creará un paquete tar llamado {{Ic|$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
 
</li>
 
 
 
== 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 [[Arch CVS & SVN PKGBUILD guidelines|Guía Arch de PKGBUILDs VCS ]]
 
 
 
=== Paquetes de plugins de Eclipse ===
 
 
 
Por favor mira la [[Eclipse plugin package guidelines|Guía de empaquetamiento de plugins de Eclipse]]
 
 
 
===Paquetes de GNOME===
 
Por favor mira la [[GNOME package guidelines|Guía de empaquetamiento GNOME]]
 
 
 
===Paquetes Go===
 
Por favor mira la [[Go package guidelines|Guía para paquetes Go]]
 
 
 
===Paquetes Haskell===
 
Por favor mira la [[Haskell package guidelines|Guía de empaquetamiento Haskell]]
 
 
 
===Paquetes Java===
 
Por favor mira la [[Java package guidelines|Guía de empaquetamiento Java]]
 
 
 
===Paquetes KDE===
 
Por favor mira la [[KDE package guidelines|Guía de empaquetamiento KDE]]
 
 
 
===Paquetes de módulos del kernel===
 
Por favor mira la [[Kernel module package guidelines|Guía de empaquetamiento de Módulos del Kernel]]
 
 
 
===Paquetes Lisp===
 
Por favor mira la [[Lisp package guidelines|Guía de empaquetamiento Llisp]]
 
 
 
===Paquetes OCaml===
 
Por favor mira la [[OCaml package guidelines|Guía de empaquetamiento OCaml]]
 
 
 
===Paquetes Perl===
 
Por favor mira la [[Perl package guidelines|Guía de empaquetamiento Perl]]
 
 
 
===Paquetes Python===
 
Por favor mira la [[Python package guidelines|Guía de empaquetamiento Python]]
 
 
 
===Paquetes Ruby Gem===
 
Por favor mira la [[Ruby Gem package guidelines|Guía de empaquetamiento Ruby]]
 
  
===Paquetes Wine===
+
== Guías adicionales ==
Por favor mira la [[Arch wine PKGBUILD guidelines|Guía de empaquetamiento Wine]]
 
  
===Paquetes MinGW===
+
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ándares listados en esta página.
Por favor mira la [[MinGW PKGBUILD guidelines|Guía de empaquetamiento MinGW]]
 
  
 +
{{Package guidelines}}
  
[[User:Jogre barroso|Jorge Barroso]] ([[User talk:Jogre barroso|talk]]) 12:45, 1 March 2013 (UTC)
+
Los paquetes enviados a AUR deben además cumplir con [[Arch User Repository (Español)#Reglas de envío]].

Revision as of 14:00, 11 October 2018

Estado de la traducción
Este artículo es una traducción de Arch packaging standards, revisada por última vez el 2018-10-10. Si advierte que la versión inglesa ha cambiado puede ayudar a actualizar la traducción, bien por usted mismo o bien avisando al equipo de traducción.

Al crear paquetes para Arch Linux deberá adherirse a las pautas para los paquetes de abajo, especialmente si desea contribuir con un nuevo paquete a Arch Linux. También debería leer los manuales de PKGBUILD y makepkg.

Prototipo de PKGBUILD

# Maintainer: su nombre <su-email@mail.com>
pkgname=NOMBRE_DEL_PAQUETE
pkgver=VERSIÓN_DEL_PAQUETE
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
}

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

Reglas de etiquetado de paquetes

  • Los paquetes nunca deben ser instalados en /usr/local
  • No introduzca nuevas variables o funciones en el script PKGBUILD, excepto cuando el paquete no puede ser compilado sin ellas, debido a que puede haber posibles confictos con las variables usadas por el propio makepkg.
  • Si una nueva variable o función es absolutamente requerida, añádale a su nombre un guión bajo de prefijo (_), por ejemplo
    variable-personal=
  • Evite utilizar /usr/libexec/. Utilice /usr/lib/$pkgname/ en su lugar.
  • El campo packager del metaarchivo del paquete puede ser personalizado por el creador del paquete modificando la opción apropiada en el archivo /etc/makepkg.conf, o alternativamente sobrescribiendo al crear ~/.makepkg.conf.
  • Todos los mensajes importantes deben ser mostrados con la orden 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.
  • Las dependencias son el error de empaquetado más común. Tómese un tiempo para verificarlas cuidadosamente, por ejemplo ejecutando ldd en ejecutables dinámicos, verificando las herramientas requeridas por los scripts o mirando la documentación del software. La utilidad namcap puede ayudarle en este sentido. Esta herramienta puede analizar tanto los PKGBUILD como el paquete resultante y le advertirá sobre permisos incorrectos, las dependencias que faltan, las dependencias redundantes y otros errores comunes.
  • Cualquier dependencia opcional que no sea 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 matriz 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 toma del paquete wine presente 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 incluya el nombre del paquete en un formato autorreferencial. Por ejemplo «Nedit es un editor de texto para X11» debería ser simplificado a «Editor de texto para X11». Intente mantener las descripciones dentro de aproximadamente 80 caracteres o menos.
  • Intente mantener el ancho de linea del PKGBUILD por debajo de los 100 caracteres.
  • Cuando sea posible elimine las líneas vacías de 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 de bash.
  • Entrecomille variables que pueden contener espacios, como "$pkgdir" y "$srcdir".
  • Para garantizar la integridad de los paquetes, asegúrese de que las variables de integridad contengan los valores correctos. Estas se pueden actualizar utilizando la herramienta updpkgsums.

Nominación de paquetes

  • Los nombres de paquetes deben contener solamente caracteres alfanuméricos, incluido los siguientes @, ., _, +, -. No se permite que los nombres comiencen con guiones o puntos. Todas las letras deben estar en minúsculas.
  • Los nombres de los paquetes NO deben tener el sufijo del número de versión de lanzamiento principal en sentido ascendente (por ejemplo, no usaremos libfoo2 si el flujo ascendente lo llama libfoo v2.3.4) en caso de que la biblioteca y sus dependencias que se esperan puedan seguir usando la versión de la biblioteca más reciente con su respectivo lanzamiento en sentido ascendente. Sin embargo, para algunos programas o dependencias, esto no puede ser asumido. En el pasado, esto ha sido especialmente cierto para los conjuntos de herramientas de widgets como GTK y Qt. El software que depende de dichos conjuntos de herramientas generalmente no puede ser portado si más a una nueva versión principal. Como tal, en los casos en que el software no puede seguir funcionando sin más junto con sus dependencias, los nombres de los paquetes deben incluir el sufijo de la versión principal (por ejemplo, gtk2, gtk3, qt4, qt5). Para los casos en los que la mayoría de las dependencias pueden continuar con la versión más reciente, pero algunas no pueden (por ejemplo, el código privativo que necesita libpng12 o similar), una versión obsoleta de ese paquete podría llamarse libfoo1, mientras que la versión actual sería solo libfoo.
  • 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 (por ejemplo, la versión de nmap es 2.54BETA32). Las etiquetas de la versión no deben incluir guiones, solo letras, numeros y puntos.
  • Las liberacones de paquetes son especificos para 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 pone en 1. Cuando se realizan correcciones y optimizaciones, el paquete es redistribuido incremento en 1 su numero de liberación. Cuando sale una nueva versión, el recuento de lanzamientos se restablece en 1. Las etiquetas de liberación de paquetes siguen las mismas restricciones de denominación que las etiquetas de versión.

Directorios

  • Los archivos de configuración deben localizarse 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. Utilice /etc/{pkgname}/ donde {pkgname} es el nombre del paquete (o un lugar alternativo, por ejemplo, apache utiliza /etc/httpd/).
  • Los archivos de cada paquete deben seguir estas 'directrices generales de directorios:
/etc Archivos de configuración esenciales del sistema
/usr/bin Binarios de aplicaciones
/usr/lib Bibliotecas
/usr/include Cabeceras de archivos
/usr/lib/{pkg} Módulos, complementos, etc.
/usr/share/doc/{pkg} Application documentation
/usr/share/info Archivos info del sistema GNU
/usr/share/man Páginas de manuales
/usr/share/{pkg} Datos de aplicaciones
/var/lib/{pkg} Almacén persistente de aplicaciones
/etc/{pkg} Archivos de configuración para {pkg}
/opt/{pkg} Paquetes grandes y autocontenidos
  • Los paquetes no deben contener ninguno de los siguientes directorios:
    • /bin
    • /sbin
    • /dev
    • /home
    • /srv
    • /media
    • /mnt
    • /proc
    • /root
    • /selinux
    • /sys
    • /tmp
    • /var/tmp
    • /run

Deberes de makepkg

Cuando se utiliza makepkg para compilar un paquete, este hace lo siguiente automáticamente:

  1. Comprueba si el paquete tiene dependencias y makedepends instaladas.
  2. Descarga las fuentes desde los servidores.
  3. Comprueba la integridad de los archivos fuentes.
  4. Desempaca los archivos fuentes.
  5. Realiza cualquier parche necesario.
  6. Compila el software y lo instala en una raíz falsa.
  7. Quita los símbolos de los binarios.
  8. Quita y depuralos símbolos de las bibliotecas.
  9. Comprime las páginas de manual y/o información.
  10. Genera el archivo meta del paquete que se incluye con cada paquete.
  11. Comprime la raíz falsa en el archivo del paquete.
  12. Almacena el archivo del paquete en el directorio de destino configurado (cwd por defecto).

Arquitecturas

La variable arch debe contener 'x86_64' si el paquete compilado es específico de dicha arquitectura. Utilice 'any' para paquetes que no dependen de la arquitectura.

Licencias

Consulte PKGBUILD#license.

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ándares listados en esta página.

Package creation guidelines

32-bitCLRCrossEclipseElectronFree PascalGNOMEGoHaskellJavaKDEKernelLispMinGWNode.jsNonfreeOCamlPerlPHPPythonRRubyRustVCSWebWine

Los paquetes enviados a AUR deben además cumplir con Arch User Repository (Español)#Reglas de envío.