Arch User Repository (Español)

Este artículo o sección necesita ser
traducido
.
Notas:
No updates since 2018, English page has seen multiple changes since. The page in English has been update to reflect the renaming of trusted users to package maintainers. (Discusión en
Talk:Arch User Repository (Español)#
)
Esta traducción de
Arch User Repository
fue revisada el
2018-09-21
. Si existen
cambios
puede
actualizarla
o avisar al
equipo de traducción
.
Artículos relacionados
makepkg
pacman
PKGBUILD
.SRCINFO
Interfaz Aurweb RPC
Directrices para usuarios de confianza de AUR
Repositorios oficiales
Sistema de construcción de Arch
Crear paquetes
AUR helpers
Arch User Repository (AUR) es un repositorio promovido por los usuarios de la comunidad de Arch. Este contiene descripciones de los paquetes (
PKGBUILD
) que le permiten compilar un paquete desde el código fuente con
makepkg
y luego instalarlo a través de
pacman
. AUR fue creado para organizar y compartir paquetes nuevos de la comunidad y ayudar a acelerar la inclusión de los paquetes más populares en el
repositorio extra
. Este documento explica cómo los usuarios pueden acceder y utilizar AUR.
Un buen número de paquetes nuevos que entran en los repositorios oficiales tienen su origen en AUR. En AUR, los usuarios pueden aportar sus propias compilaciones de paquetes (PKGBUILD y los archivos relacionados). La comunidad de AUR tiene la posibilidad de votar a favor o en contra de los paquetes de AUR. Si un paquete llega a ser lo suficientemente popular — siempre que tenga una licencia compatible y la técnica de un buen empaquetado — puede ser introducido en el repositorio
extra
(directamente accesible por
pacman
o
abs
).
Advertencia
Los paquetes contenidos en AUR son producidos por usuarios. Estos
PKGBUILD
no son oficiales y no han sido exhaustivamente revisados. Cualquier uso de los archivos proporcionados lo es bajo el propio riesgo del usuario.
Para empezar
Los usuarios pueden buscar y descargar
PKGBUILDs
desde la
interfaz Web de AUR
. Estos PKGBUILDs se pueden compilar en paquetes instalables usando
makepkg
, y luego ser instalados con
pacman
.
Asegúrese de que el meta-paquete
base-devel
esté
instalado
.
Léase
#FAQ
para obtener respuestas a las preguntas más comunes.
Es posible mejorar el proceso de compilación ajustando
/etc/makepkg.conf
antes de crear paquetes desde AUR. Se puede obtener una mejora significativa en los tiempos de compilación en sistemas con procesadores multicore ajustando la variable
MAKEFLAGS
, usando múltiples núcleos para compresión o especificando un algoritmo de compresión distinto. También se pueden habilitar optimizaciones para hardware específico a través de la variable
CFLAGS
. Véase
makepkg#Recomendaciones
para obtener más información.
Después de haber configurado
autentificación SSH
, también es posible interactuar con AUR a través de SSH: escriba
ssh aur@aur.archlinux.org help
para obtener una lista de las órdenes disponibles.
Historia
En un principio, existía
ftp://ftp.archlinux.org/incoming
, y se contribuía únicamente subiendo el PKGBUILD, los archivos adicionales necesarios y el mismo paquete compilado al servidor. El paquete y los archivos asociados se mantenían allí hasta que un
mantenedor de paquetes
veía el programa y lo adoptara.
Posteriormente, surgieron los Trusted User Repositories (
«repositorios de usuarios de confianza»
). A algunas personas de la comunidad se les permitía alojar sus propios repositorios para que cualquiera los utilizase. AUR se amplió sobre esta base, con el objetivo de hacerlo más flexible y manejable. De hecho, a los responsables de AUR todavía se les conoce como TU (
Trusted Users
, usuarios de confianza).
Entre 2015-06-08 y 2015-08-08, AUR hizo la transición de la versión 3.5.1 a la 4.0.0, introduciendo el uso de repositorios Git para publicar los
PKGBUILD
s. Los paquetes existentes se descartaron, salvo aquellos que sus mantenedores migraron manualmente a la nueva infraestructura.
Repositorios Git para paquetes AUR3
El
AUR Archive
en GitHub tiene un repositorio para cada paquete que estaba en AUR 3 en el momento de la migración. Por otro lado, existe el repositorio
aur3-mirror
que proporciona lo mismo.
Instalar y actualizar paquetes
La instalación de paquetes desde AUR es un proceso relativamente simple. En esencia consiste en:
Obtener los archivos para la compilación, incluyendo el
PKGBUILD
y posiblemente otros archivos necesarios, como unidades para
systemd
y parches (usualmente no el código mismo).
Verificar que el
PKGBUILD
y los archivos acompañantes no son maliciosos o de desconfianza.
Ejecutar
makepkg
en el directorio donde se han colocado los archivos. Esta orden descarga la fuente, compila y empaca el paquete.
Ejecutar
pacman -U
paquete_generado
para instalar el paquete en su sistema.
Nota
AUR no tiene soporte, por lo que es responsabilidad del usuario actualizar paquetes instalados, no de pacman. Si se actualizan paquetes en los repositorios oficiales, deberá reconstruir cualquier paquete de AUR que dependa de esas bibliotecas.
Requisitos previos
Primero, asegúrese de que las herramientas necesarias estén
instaladas
instalando el meta-paquete
base-devel
; este
meta-paquete
incluye a
make
y otras herramientas necesarias para compilar desde código fuente listadas como dependencias.
Nota
Los paquetes disponibles en AUR asumen que tiene instalado el meta-paquete
base-devel
.
A continuación, elija un directorio de compilación apropiado. Un directorio de compilación es simplemente una carpeta en la que se construirá el paquete o «se compilará», y puede ser cualquier carpeta. En el ejemplo que se sigue, la carpeta
~/builds
será el directorio de compilación.
Obtener los archivos de compilación
Localice el paquete en AUR. Esto se realiza utilizando la función de búsqueda en el recuadro de texto de la parte superior de la
página principal de AUR
. Al pulsar sobre el nombre de la aplicación en la lista de búsqueda se muestra la página de información sobre el paquete. Lea la descripción para confirmar que este es el paquete deseado, observe la última fecha de actualización del paquete y lea los comentarios.
Existen diferentes métodos para adquirir los archivos de compilación:
Clonar el repositorio
git
que tiene el nombre «Git Clone URL» en los detalles del paquete. Este es el método sugerido, cuya ventaja es que permite obtener actualizaciones para el paquete a través de
git pull
.
$ git clone https://aur.archlinux.org/
nombre_de_paquete
.git
Descargue una copia, dando click en "Download snapshot" en la categoría "Package Actions" en el lado derecho de su página de AUR, o a través de la terminal:
$ curl -L -O https://aur.archlinux.org/cgit/aur.git/snapshot/
nombre_de_paquete
.tar.gz
Note
El archivo de copia está comprimido, y debe ser descomprimido (preferentemente en un directorio dedicado a compilaciones de paquetes AUR):
tar -xvf
nombre_de_paquete
.tar.gz
Use el espejo de solo lectura
archlinux/aur en GitHub
, donde cada paquete está localizado en su propia rama. Se recomienda que solo clone una sola rama (el repositorio completo es demasiado grande y el rendimiento sería muy bajo). Puede hacer esto a través de los siguientes métodos:
Usando
git clone --single-branch
:
$ git clone --branch
nombre_de_rama
/
nombre_de_paquete
--single-branch
https://github.com/archlinux/aur
Realizando una
clonación parcial
of this repository (
git clone --depth=1
) y
añadiendo ramas
selectivamente:
$ git clone --depth=1 https://github.com/archlinux/aur; cd aur
$ git remote set-branches --add origin
nombre_de_paquete
$ git fetch
$ git checkout
nombre_de_paquete
Adquiera una clave pública PGP si es necesaria
Revise si un archivo de firma en forma de
.sig
o
.asc
forma parte del arreglo de fuentes
source
del
PKGBUILD
. Si así es, adquiera una de las claves públicas listadas en el arreglo
validpgpkeys
del PKGBUILD. Lea
makepkg (Español)#Verificación de firmas
para más información.
Compilar el paquete
Cambie al directorio que contiene el
PKGBUILD
del paquete.
$ cd
nombre_del_paquete
Advertencia
Verifique cuidadosamente el
PKGBUILD
, cualquier archivo
.install
y cualquier otro archivo presente en el repositorio git del paquete, en busca de secuencia de órdenes maliciosas o peligrosas. Si tiene dudas, no compile el paquete, y
pregunte
en los foros o en la lista de correos. Ya se ha encontrado antes código malicioso en paquetes.
[1]
Vea los contenidos de todos los archivos proporcionados. Por ejemplo, para usar el paginador
less
para ver
PKGBUILD
ejecute:
$ less PKGBUILD
Sugerencia
Si está actualizando un paquete, es posible que desee ver los cambios desde el último envío.
Para ver los cambios desde el último envío utilice
git show
.
Para ver los cambios desde el último envío utilizando
vimdiff
, ejecute
git difftool @~..@ vimdiff
. La ventaja de
vimdiff
es que puede ver todo el contenido de cada archivo junto con los indicadores de lo que ha cambiado.
Construya el paquete. Después de confirmar manualmente el contenido de los archivos, ejecute
makepkg
como un usuario normal. Algunas opciones útiles:
-s
/
--syncdeps
resuelve e instala automáticamente cualquier dependencia con
pacman
antes de compilar. Si el paquete depende de otros paquetes de AUR, deberá primero instalarlos manualmente.
-i
/
--install
instala el paquete si fue compilado correctamente. Esto le permite saltar el siguiente paso, que usualmente se realiza manualmente.
-r
/
--rmdeps
elimina las dependencias de compilación después de la compilación, pues ya no son necesarias. Sin embargo, es posible que estas dependencias tengan que reinstalarse la próxima vez que se actualice el paquete.
-c
/
--clean
limpia los archivos de compilación temporales después de la compilación, pues ya no son necesarios. Estos archivos generalmente solo se necesitan al depurar el proceso de compilación.
Tip
Use
git clean -dfX
para borrar los archivos ignorados por git, así borrando todos los archivos compilados si el proyecto los ignora.
Instale el paquete
Ahora puede instalar el paquete con pacman:
# pacman -U
nombre_de_paquete
-
versión
-
arquitectura
.pkg.tar.zst
Nota
Si realizó cambios en
PKGEXT
en
makepkg.conf
, el nombre del paquete podría ser ligeramente diferente.
El ejemplo anterior es solo un breve resumen del proceso de compilación. Se recomienda
encarecidamente
que lea los artículos
makepkg (Español)
y
ABS (Español)
para obtener más información.
Actualización de paquetes
En el directorio que contiene el
PKGBUILD
del paquete, debe actualizar los archivos y cambios con la orden
$ git pull
y seguir de nuevo las instrucciones de compilación e instalación.
Estado de cuentas
Suspensión
Cuando un usuario de confianza edita a un usuario, puede editarse el campo
Suspended
(suspensión), que suspende al usuario objetivo.
Cuando un usario está suspendido, no puede:
Iniciar sesión en
https://aur.archlinux.org
Recibir notificaciones
Interactuar con la interfaz git
Inactividad
Al editar su propia cuenta o la de otra persona como usuario de confianza, puede editarse el campo
Inactive
(kinactividad). Existen dos razones para suspender cuentas:
Mostrar la fecha en la que alguien fue etiquetado como inactivo en la página de su cuenta
Generar un conteo actualizado de usuario de confianza activos basado en su inactividad para consideración de nuevos candidatos
Retroalimentación
Escribir comentarios en paquetes
La
interfaz Web de AUR
facilita hacer comentarios que permite a los usuarios proporcionar sugerencias y retroalimentaci para contribuir a mejorar el
PKGBUILD
.
Sugerencia
Evite pegar parches o
PKGBUILD
s en la sección de comentarios: se vuelven rápidamente obsoletos y acaban ocupando innecesariamente mucho espacio. En su lugar, envíe los archivos al mantenedor, o incluso utilice un
cliente pastebin
.
Python-Markdown
proporciona una sintaxis
Markdown
básica para dar formato a comentarios.
Nota
Esta implementación tiene
diferencias
ocasionales respecto a
reglas de sintaxis
oficiales.
Hashes de
commits
al repositorio
Git
del paquete y referencias a
tickets
Flyspray
se convierten automáticamente a hipervínculos.
Los comentarios largos son colapsados y pueden ser expandidos.
Votar por paquetes
Una de las actividades más fáciles para
todos
los usuarios de Arch es navegar por AUR y
votar
por sus paquetes favoritos utilizando la interfaz web. Todos los paquetes son elegibles para ser adoptados por un usuario de confianza para su inclusión en el
repositorio extra
, y el recuento de votos es uno de los factores considerados en este proceso, ¡por lo que votar es un interés de todos!
Resístrese en el
sitio de AUR
para encontrar la opción
Vote for this package
(votar por este paquete) al explorar los paquetes. Después de registrarse, también es posible votar desde la linea de órdenes con
aurvote-git
AUR
[
enlace roto
: package not found]
o
aur-auto-vote-git
AUR
.
Alternativamente, si ha configurado
auteticación ssh
, puede votar directamente desde la línea de órdenes usando su clave ssh. Con este método no tiene que guardar o escribir su contraseña de AUR.
$ ssh aur@aur.archlinux.org vote
nombre_de_paquete
Marcar paquetes como desactualizados
Primero señale al paquete como
out-of-date
(desactualizado) dando detalles sobre por qué está desactualizado, preferentemente incluyendo hipervínculos al anuncio de lanzamiento o al
tarball
del lanzamiento nuevo .
También puede contactar a los mantenedores del paquete a través de correo electrónico. Si no recibe respuesta después de
dos semanas
, puede enviar una petición para señalar al paquete como
huérfano
. Lea
AUR submission guidelines#Requests
para más información.
Nota
Paquetes VCS (desde sistemas de control de versiones)
no se consideran desactualizados cuando
pkgver
(la versión del paquete) cambia; no los etiquete pues el mantenedor simplemente desetiquetará el paquete y lo ignorará. Mantenedores de AUR no deben hacer
commits
de simples cambios de
pkgver
.
Depurar el proceso de compilación
Verifique que su entorno de compilación esté actualizado
actualizando
antes de comenzar a compilar.
Asegúrese de tener
base-devel
instalado.
Use la opción
-s
al ejecutar
makepkg
para verificar e instalar las dependencias requeridas entes de compilar.
Pruebe con la
configuración predeterminada de makepkg
.
Lea
Makepkg (Español)#Solución de problemas
para encontrar soluciones a problemas comunes.
Si tiene problemas para compilar un paquete, lea su
PKGBUILD
y los comentarios en su página AUR.
Es posible que un
PKGBUILD
tenga problemas para todo mundo. Si no puede solucionarlo usted mismo, hágale saber al mantenedor (por ejemplo,
publicando los errores que encuentre en los comentarios de su página AUR
). También puede pedir ayuda en el
foro de problemas, discusiones y peticiones sobre MAKEPKGs
.
La razón podría no ser trivial después de todo. Los
CFLAGS
,
LDFLAGS
y
MAKEFLAGS
personalizados pueden causar errores. Para evitar problemas causados por la configuración particular de su sistema, construya paquetes en un
chroot limpio
. Si el proceso de compilación sigue fallando en un chroot limpio, es probable que el problema sea el
PKGBUILD
.
Véase
Comprobación de la sanidad del paquete
sobre el uso de
namcap
. Si desea que se revise un
PKGBUILD
, publíquelo en la lista de correo
aur-general
para obtener comentarios de los
TU
y otros miembros de AUR, o en el
foro de Creación y Modificación de Paquetes
. También puedes buscar ayuda en el
canal IRC
#archlinux-aur
en la red
Libera Chat
.
Enviar paquetes
Advertencia
Antes de intentar enviar un paquete, se espera que se familiarice con
Arch package guidelines (Español)
y todos los artículos indicados en «Artículos relacionados».
Verifique cuidadosamente
que lo que está cargando es correcto. Los paquetes que infrinjan las reglas podrán
eliminarse
sin previo aviso.
Si no está seguro de ningún modo sobre el paquete o el proceso de compilación/envío, incluso después de haber leído varias veces esta sección, envíe el PKGBUILD a la
lista de correo de AUR
, el
foro de AUR
en los foros de Arch, o pregunte en nuestro
canal IRC
para su revisión pública antes de agregarlo a AUR.
Reglas de envío
Al enviar un paquete, observe las siguientes reglas:
Los PKGBUILD enviados no deben compilar aplicaciones
ya disponibles en cualquiera
de los
repositorios oficiales
con binarios bajo ninguna circunstancia. Compruebe la
base de datos de paquetes oficiales
para ver el paquete. Si existe alguna versión de la misma,
no
envíe el paquete. Si el paquete oficial está desactualizado, márquelo como tal. Si el paquete oficial está roto o carece de un recurso, entonces presente un
informe de error
.
Excepción
a esta regla estricta solo lo pueden ser aquellos paquetes que tengan
características adicionales
habilitadas y/o
parches
en comparación con las oficiales. En tal caso,
pkgname
debería ser diferente para expresar esa diferencia. Por ejemplo, un paquete para la GNU screen que contiene el parche de la barra lateral se podría llamar
screen-sidebar
. Además, el vector
provides=('screen')
se debe utilizar para evitar conflictos con el paquete oficial.
Verifique en AUR
si el paquete
ya existe
. Si ya tiene un mantenedor, los cambios se pueden enviar en un comentario a la atención del mantenedor. Si no hay mantenedor o el mantenedor no responde, el paquete se puede adoptar y actualizar según sea necesario. No cree paquetes duplicados.
Asegúrese de que el paquete que desea cargar es
útil
. ¿Alguien más quiere usar este paquete? ¿Es muy especializado? Si unas cuantas personas encuentran este paquete útil, es apropiado para la presentación.
AUR y los repositorios oficiales están destinados a paquetes que instalan generalmente software y contenido relacionado con software, incluidos uno o más de los siguientes: ejecutables; archivo(s) de configuración; documentación en línea o fuera de línea para un software específico o para la distribución de Arch Linux en su conjunto; medios destinados a ser utilizados directamente por el software.
No utilice
replaces
en un PKGBUILD de AUR a menos que se cambie el nombre del paquete, por ejemplo cuando
Ethereal
se convirtió en
Wireshark
. Si el paquete es una
versión alternativa de un paquete ya existente
, utilice
conflicts
(y ​​
provides
si ese paquete es requerido por otros). La principal diferencia es que después de la sincronización (-Sy), pacman inmediatamente quiere reemplazar un paquete 'ofensivo' instalado al encontrar un paquete con la coincidencia
replaces
en sus repositorios;
conflicts
, por otro lado, solo se evalúa al instalar el paquete, que generalmente es el comportamiento deseado porque es menos invasivo.
El envío de
binarios
debe
evitarse
si las fuentes están disponibles. AUR no debe contener el tarball binario creado por makepkg, ni debe contener la lista de archivos.
Agregue una
línea de comentario
a la parte superior del archivo
PKGBUILD
que contenga información sobre los
mantenedores
actuales y los
contribuidores
anteriores, respetando el siguiente formato. Recuerde disfrazar su correo electrónico para protegerse contra el correo no deseado. Las líneas adicionales o innecesarias son facultativas.
Si asume la función de mantenedor de un PKGBUILD existente, agregue su nombre a la parte superior de este modo
# Maintainer: su nombre <dirección at dominio dot tld>
Si hubo mantenedores anteriores, colóquelos como contribuyentes. Lo mismo se aplica para el remitente original si este no fue usted. Si existe un conjunto de mantenedores, agregue los nombres de los otros mantenedores actuales también.
# Maintainer: su nombre <dirección at dominio dot tld>
# Maintainer: nombre de otros mantenedores <dirección at dominio dot tld>
# Contributor: nombre de los mantenedores anteriores <dirección at dominio dot tld>
# Contributor: nombre del remitente original <dirección at dominio dot tld>
Verificación
Para tener acceso de modificación en AUR necesita disponer de
emparejamiento de claves SSH
. El contenido de la llave pública debe ser copiado en la página del perfil en la sección
My Account
, y la llave privada correspondiente debe ser configurada para el servidor
aur.archlinux.org
. Por ejemplo:
~/.ssh/config
Host aur.archlinux.org
  IdentityFile ~/.ssh/aur
  User aur
En el escenario ideal se debe
SSH keys#Generating an SSH key pair
y no usar un par existente, así se pueden revocar selectivamente en caso de que algo ocurra:
$ ssh-keygen -f ~/.ssh/aur
Sugerencia
Se pueden agregar múltiples llaves en su perfil separándolas con una nueva línea.
Crear un paquete nuevo
Para crear un repositorio Git vacío para un paquete, simplemente
git clone
el repositorio remoto con el nombre correspondiente. Si el paquete no existe en AUR, aparecerá la siguiente advertencia:
$ git clone ssh://aur@aur.archlinux.org/
package_name
.git
Cloning into '
package_name
'...
warning: You appear to have cloned an empty repository.
Checking connectivity... done.
Nota
Cuando un paquete es borrado de AUR, el repositorio git no es borrado, así que al clonar el repositorio puede que no este vació si alguien quiere crear un paquete con el mismo nombre.
Si hay un repositorio git existente, simplemente se crea un
remote
para el repositorio git de AUR y luego
fetch
en el repositorio:
$ git remote add
nombre_remoto
ssh://aur@aur.archlinux.org/
nombre_paquete
.git
$ git fetch
nombre_remoto
Donde
nombre_remoto
es el nombre del
remote
a crear (
v.g.,
"origen"). Vea
Git (Español)#Usando remotos
para mayor información.
El paquete aparecerá en AUR después del primer
push
. Desde ese momento se pueden agregar archivos con código fuente a la copia local del repositorio git. Vea
#Subir paquetes
.
Advertencia
Sus AUR
commits
tendrán como autor su usuario y correo electrónico configurado en git. Es muy difícil cambiar un
commit
después que ha sido subido (vea
FS#45425
). Si desea enviar paquetes con un autor/email diferente, lo puede hacer con la orden
git config user.name [...]
y
git config user.email [...]
. ¡Revise sus
commits
y documentos antes de subirlos!
Subir paquetes
El procedimiento para subir paquetes a AUR es el mismo que para crear paquetes nuevos o para actualizaciones. Se necesita como mínimo un
PKGBUILD
y un
.SRCINFO
en el directorio de trabajo para subir (
push
) su paquete a AUR.
Nota
se necesita generar el archivo
.SRCINFO
cada vez que se cambie la metainformación del
PKGBUILD
. Por ejemplo, al modificar
pkgver()
en actualizaciones. De otra manera, la web de AUR no va a mostrar las versiones actualizadas .
Para subir, añada el
PKGBUILD
,
.SRCINFO
y cualquier otro archivo necesario (como archivos
.install
o fuentes locales
.patch
) con
git add
, suba a su árbol local con un mensaje descriptivo
git commit
, y finalmente suba sus cambios a AUR con
git push
.
Ejemplo concreto:
$ makepkg --printsrcinfo > .SRCINFO
$ git add PKGBUILD .SRCINFO
$ git commit -m "
useful commit message
"
$ git push
Sugerencia
Si inicialmente se ha olvidado el archivo
.SRCINFO
y lo ha agregado en un
commit
después, AUR va a rechazar sus subidas porque el archivo
.SRCINFO
debe existir en
cada
subida (
push
). Para solucionar este problema puede usar la orden
git rebase
con la opción
--root
o la orden
git filter-branch
con la opción
--tree-filter
.
Para prevenir archivos sin rastrear en las subidas, y para mantener el directorio de trabajo tan limpio como sea posible, excluya todos los archivos no deseados con
.gitignore
y fuerce agregar manualmente cada archivo. Vea
gitignore(5)
.
Mantener los paquetes
Si se mantiene un paquete y desea actualizar el PKGBUILD para el mismo, basta con reenviarlo.
Compruebe si hay feedback y comentarios de otros usuarios y trate de incorporar las mejoras que le sugieren, ¡considere que es un proceso de aprendizaje!
Por favor, no presente un paquete, para luego olvidarse de él. El trabajo del mantenedor es mantener el paquete, buscando las actualizaciones y las mejoras del PKGBUILD.
Si no desea seguir manteniendo el paquete, por alguna razón, etiquete el paquete como
disown
a través de la interfaz web de AUR y/o envíe un mensaje a la lista de correos de AUR. Si todos los mantenedores de un paquete AUR lo rechazan, se convertirá en un paquete
«huérfano»
.
Otras solicitudes
Las solicitudes de orfandad, eliminación o fusión se pueden crear haciendo clic en el enlace «Submit Request» bajo el enlace «Package Actions» en el lado derecho. Esto envía automáticamente un correo electrónico de notificación al actual mantenedor del paquete y a la
aur-requests lista de correo
para su discusión. El
Trusted Users
aceptará o rechazará la solicitud.
Las solicitudes de orfandad se otorgarán después de dos semanas, si el mantenedor actual no reaccionó.
Las solicitudes de fusión son para eliminar la base del paquete y transferir sus votos y comentarios a otra base de paquetes. Se requiere el nombre de base del paquete para fusionar. Tenga en cuenta que esto no tiene nada que ver con 'git merge' o las solicitudes de fusión de GitLab.
Las solicitudes de eliminación requieren la siguiente información:
Una breve nota que explique el motivo de la eliminación. Tenga en cuenta que los comentarios de un paquete no indican suficientemente las razones por las cuales un paquete está listo para su eliminación. Porque tan pronto como una TU toma medidas, el único lugar donde se puede obtener dicha información es la lista de correo.
Detalles del soporte, como cuando un paquete es proporcionado por otro paquete, si uno mismo es el mantenedor, si es renombrado y si el propietario original acepta, etc.
Las solicitudes de eliminación pueden rechazarse, en cuyo caso, si usted es el mantenedor del paquete, es probable que se le aconseje que no lo reconozca, para permitir la adopción por parte de otro empaquetador.
Traducir la interfaz web
Consulte
i18n.txt
en el árbol fuente de AUR para obtener información sobre cómo crear y mantener la traducción de la interfaz web de AUR.
Sintaxis de comentario
La sintaxis de
Python-Markdown
es compatible con los comentarios.
Proporciona la sintaxis básica de
Markdown
para dar formato a los comentarios. Tenga en cuenta que esta implementación tiene algunas
diferencias
ocasionales con respecto a las
reglas de sintaxis
oficiales. Confirme el hash para el repositorio Git del paquete y las referencias a los tickets para Flyspray se convertirán en enlaces automáticamente. Los comentarios largos se contraen y se pueden expandir bajo demanda.
FAQ
¿Que es AUR?
AUR (Arch User Repository) es el lugar donde la comunidad de Arch Linux puede subir los
PKGBUILD
de las aplicaciones, bibliotecas, etc., y compartirlos con el resto de la comunidad. Los demás usuarios pueden votar para que sus favoritos entren en el
repositorio extra
de modo que puedan ser instalados en Arch Linux en formato binario.
¿Qué tipo de paquetes se permiten en AUR?
Los paquetes en AUR no son más que «scripts de compilación», es decir, instrucciones para construir los binarios que pueden ser manejados por pacman. Para la mayor parte de los casos, no hay limitaciones, siempre y cuando se ajusten a
las directrices
de la utilidad antes mencionada y a los términos de licencia del contenido. En otros casos, cuando se menciona que «no se puede vincular» a las descargas, como cuando los contenidos no son redistribuibles, solo se podrá hacer uso del mismo nombre del archivo como la fuente. Esto significa y requiere que los usuarios deben tener ya la fuente en el directorio de compilación antes de iniciar el proceso de construcción del paquete. En caso de duda, pregunte.
¿Cómo puedo votar por los paquetes en AUR?
Inscríbase en el
sitio web de AUR
para tener acceso a la opción "Vote for this package" («Vote por este paquete») mientras explora los paquetes. Después de registrarse, también es posible votar desde la línea de órdenes con
aurvote
AUR
[
enlace roto
: package not found]
,
aurvote-git
AUR
[
enlace roto
: package not found]
o
aur-auto-vote-git
AUR
.
Alternativamente, si ha configurado
autenticación ssh
como se indicó anteriormente, puede votar directamente desde la línea de órdenes usando su clave ssh. Esto significa que no necesitará guardar o escribir su contraseña AUR.
ssh aur@aur.archlinux.org vote <PACKAGE_NAME>
¿Qué es un usuario de confianza / Trusted Users (TU)?
Un
Trusted Users (
«usuarios de confianza»
)
, siglas en inglés TU, es una persona encargada de supervisar el repositorio AUR y el
repositorio extra
. Ellos son los que colocan los paquetes más votados en el repositorio
extra
, marcan los PKGBUILDs como seguros y mantienen AUR.
¿Cuál es la diferencia entre Arch User Repository y el repositorio extra?
Arch User Repository contiene todos los PKGBUILD que los usuarios envían; para instalarlos tiene que construirlos manualmente con
makepkg
. Cuando un PKGBUILD obtiene suficientes votos, pasa al
repositorio extra
(mantenido por los usuarios de confianza), donde los paquetes binarios pueden instalarse directamente con
pacman
.
Un paquete en AUR está desactualizado, ¿qué hago?
Puede marcarlo como obsoleto. Si no se actualiza en un periodo de tiempo razonable, lo mejor es avisar a su mantenedor por email. Si el responsable no responde, puede comunicarlo a la lista de correo general de AUR, para que un TU (Trusted Users —
«usuarios de confianza»
—) declare huérfano al PKGBUILD y pueda adoptarlo si desea mantenerlo él mismo. Cuando se trate de un paquete que lleva desactualizado más de 3 meses y, en general, no se actualiza desde hace mucho tiempo, por favor agregue esto en su solicitud de orfandad.
Mientras tanto, puede intentar actualizar el paquete editando el PKGBUILD localmente. A veces, las actualizaciones no requieren cambios en el proceso de compilación o paquete, en cuyo caso basta con actualizar la matriz
pkgver
o
source
.
Nota
Los
paquetes VCS
no se consideran obsoletos cuando el pkgver cambia, no los marque ya que el mantenedor simplemente desmarca el paquete y lo ignora. Los mantenedores de AUR no deberían cometer errores de pkgver.
Foo, que está en AUR, no me compila con makepkg, ¿qué hago?
Probablemente está pasando por alto alguna cosa.
Ejecute
pacman -Syyu
antes de compilar nada con
makepkg
dado que el problema puede ser que el sistema no está al día.
Asegúrese de que tiene instalados tanto los grupos «base» como «base-devel».
Pruebe usando la opción «
-s
» con
makepkg
para comprobar e instalar todas las dependencias necesarias antes de comenzar el proceso de compilación.
Asegúrese de leer primero el PKGBUILD y los comentarios en la página de AUR del paquete en cuestión.
La razón puede no ser trivial después de todo. La personalización de CFLAGS, LDFLAGS y MAKEFLAGS puede causar fallos. También es posible que el PKGBUILD se rompe para todos. Si no puede resolverlo por su cuenta, simplemente informe al mantenedor, por ejemplo, mediante la publicación de los errores que está recibiendo en los comentarios de la página de AUR.
Para verificar si el PKGBUILD está roto, o si su sistema está mal configurado, considere compilar en un entorno chroot limpio. Construirá su paquete en un entorno limpio de Arch Linux, con solo dependencias (de compilación) instaladas y sin personalización del usuario. Para hacer esto
instale
devtools
y ejecute
extra-x86_64-build
en lugar de
makepkg
. Para paquetes
multilib
, ejecute
multilib-build
. Consulte
DeveloperWiki:Building in a clean chroot
para más información. Si el proceso de compilación aún falla en un entorno chroot limpio, el problema probablemente esté en el PKGBUILD.
ERROR: One or more PGP signatures could not be verified!; ¿qué debería hacer?
Lo más probable es que no tenga las claves públicas requeridas en su depósito de claves personal para verificar los archivos descargados. Si uno o más archivos .sig se descargan al compilar el paquete,
makepkg verificará automáticamente los archivos correspondientes con la clave pública de su firmante
. Si no tiene la clave requerida en su depósito de claves personal,
makepkg
no hará la verificación.
La forma recomendada de tratar este problema es importar la clave pública requerida, ya sea
manualmente
o
desde un servidor de claves
. A menudo, simplemente puede encontrar la huella digital de las claves públicas necesarias en
validpgpkeys
.
¿Cómo hacer un PKGBUILD?
Lo mejor es mirar
Creating packages (Español)
. Recuerde mirar en AUR antes de crear el PKGBUILD para no duplicar los esfuerzos.
Quiero enviar un PKGBUILD ¿podría alguien comprobar antes si tiene errores?
Si quisiera recibir comentarios a tu PKGBUILD, envíelo a la lista de correo de AUR para que los TU (Trusted Users —
«usuarios de confianza»
—) y los otros miembros de AUR puedan orientarle para mejorarlo. Otro lugar donde puede encontrar ayuda es el
canal IRC
, #archlinux en irc.libera.chat. También puede usar
namcap
para depurar errores de su PKGUILD y del paquete resultante.
¿Qué hacer para que un PKGBUILD pase al repositorio extra?
Por lo general, son necesarios, al menos, 10 votos para que algo se mueva al
repositorio extra
. Sin embargo, si un TU (Trusted Users —
«usuarios de confianza»
—) quiere apoyar un paquete, se suele pasar dicho paquete al repositorio.
Llegar al mínimo requerido de votos no es el único requisito, tiene que haber un TU (Trusted Users —
«usuarios de confianza»
—) dispuesto a mantener el paquete. Los TU (Trusted Users —
«usuarios de confianza»
—) no están obligados a mover un paquete al repositorio
extra
, incluso si tiene miles de votos.
Por lo general, cuando un paquete muy popular permanece en AUR es porque:
Arch Linux ya tiene otra versión de un paquete en los repositorios
Su licencia prohíbe la redistribución
Ayuda a recuperar PKGBUILDs enviados por el usuario. Los
AUR helpers
están por definición
sin soporte
.
Véase también
Reglas para paquetes que ingresan en el repositorio extra
.
¿Cómo puedo acelerar los repetidos procesos de compilación?
Consulte
makepkg (Español)#Mejorar tiempos de compilación
.
¿Cuál es la diferencia entre los paquetes foo y foo-git?
Muchos paquetes de AUR se presentan en versiones regulares ("estables") y de desarrollo ("inestables"). Un paquete de desarrollo generalmente tiene un sufijo como
-cvs
,
-svn
,
-git
,
-hg
,
-bzr
o
-darcs
. Si bien los paquetes de desarrollo no están destinados para uso regular, pueden ofrecer nuevas características o correcciones de errores. Debido a que estos paquetes descargan la última fuente disponible cuando ejecuta
makepkg
, no está directamente disponible para estos una versión del paquete para rastrear posibles actualizaciones. Del mismo modo, estos paquetes no pueden realizar una suma de comprobación de autenticidad, sino que debemos fiarnos de los mantenedores del repositorio Git.
Véase también
System maintenance (Español)#Usar paquetes de software probado
.
¿Por qué foo desapareció de AUR?
Es posible que el paquete haya sido adoptado por un TU (Trusted Users —
«usuarios de confianza»
—) y ahora esté en el
repositorio extra
.
Los paquetes pueden eliminarse si no cumplen con las
#Reglas de envío
. Consulte los
aur-requests archivos
para conocer el motivo de la eliminación.
Si el paquete estaba presente en AUR3, podría no haber sido
migrado a AUR4
. Consulte los
#Repositorios Git para paquetes AUR3
donde se conservará.
¿Cómo puedo averiguar si alguno de los paquetes instalados desapareció de AUR?
La forma más sencilla es verificar el estado HTTP de la página AUR del paquete:
$ comm -23 <(pacman -Qqm | sort) <(curl
https://aur.archlinux.org/packages.gz
| gzip -cd | sort)
Si utiliza un
AUR helper
, puede acortar este script reemplazando la orden curl con cualquier orden que consulte AUR para un paquete.
¿Cómo puedo obtener una lista de todos los paquetes de AUR?
https://aur.archlinux.org/packages.gz
Utilice
aurpkglist
de
python3-aur
AUR
Véase también
AUR Web Interface
AUR Mailing List
DeveloperWiki:AUR Cleanup Day