Si repasamos la lista de paquetes más populares del repositorio comunitario AUR, encontraremos entre los primeros a un buen número de helpers.
Son programas que ayudan a los usuarios de Arch Linux y sus derivadas (Antergos, Manjaro, ArchLabs…), a instalar sus paquetes y –sobre todo– a mantenerlos actualizados.
Son los cower, pacaur (mi favorito por su manera de ejecución y la posibilidad de leer los pkgbuilds previamente), yaourt (a fuerza de costumbre el más popular, pero como veis en esta comparativa quizás no el mejor), aura, etc.
Es posible que un momento dado, uno de esos helpers se rompa. Justo cuando más precises instalar un programa. Por suerte hacerlo de forma manual es muy fácil.
Tomemos como ejemplo el paquete «neofetch»:
- Lo primero que hacemos es descargar la imagen correspondiente (snapshot), desde su página de AUR ( click en el apartado «download snapshot»).
O si lo preferimos tiramos de terminal:
wget -c https://aur.archlinux.org/cgit/aur.git/snapshot/neofetch.tar.gz
- Descomprimimos el archivo descargado. De nuevo de forma gráfica o desde la consola:
tar xzf neofetch.tar.gz
- A continuación desde la terminal, nos situamos en la carpeta que acabamos de crear (la cual vemos que contiene el archivo de instalación PKGBUILD, al que es conveniente siempre echarle un vistazo).
cd neofetch
- Y para finalizar hacemos un poco de magia con makepkg, que es un script–incluido en pacman–, que automatiza la construcción de los paquetes.
Le vamos a pasar unos cuantos parámetros: «i» instala el paquete, «s» instala dependencias en caso de ser necesario y «c» limpia los archivos y directorios sobrantes, si la compilación ha sido exitosa
makepkg -csi neofetch
Como veis no tiene ningún misterio, la instalación manual de un paquete desde AUR y podría pensarse que los helpers no son demasiado necesarios.
Sería así sino fuera por el tema de las actualizaciones, puesto que simplifican el estar al tanto de ellas y llevarlas a cabo. En especial si tenemos muchos paquetes provenientes de AUR.
Como siempre para saber más del tema, nada como la magnífica wiki de Arch Linux.
Vía | Reddit
Gracias tannhausser por compartir, lo añadiré a la Zim Wiki (programa que conocí acá en tu página). Saludos.
PD: Acabo de ver que Sparky Linux acab de añadir un nuevo escritorio que desconocía, te adjunto el link a la noticia por si te interesa.
https://sparkylinux.org/manokwari-desktop/
Gracias por el link!
Tomo nota!
A mi me surge una duda: yo también utilizo Antergos, pero hasta ahora usaba yaourt, pero como cambiar a pacaur es tan sencillo pues a partir de ahora uso ese. La duda que me surge es: cuando utilizo la herramienta de actualización gráfica, que también la tengo para que busque actualizaciones en AUR, ¿qué utiliza? ¿yaourt, pacaur ahora que lo tengo instalado u otro interno suyo?
Por defecto creo que usa yaourt, sin embargo, alguien ha parcheado pamac(la herramienta de Antergos) para funcionar con pacaur:
https://aur-dev.archlinux.org/packages/pamac-pacaur/
Eso es algo que ha cambiado en los últimos meses, ahora pamac ya no precisa de ningún helper como yaourt para construir los paquetes provenientes de AUR.
https://forum.manjaro.org/t/pamac-introducing-our-own-aur-support/17924
Desconozco como lleva ahora mismo el proceso de actualizaciones respecto a yaourt. Desde que me pasé a KDE (finales 2016 creo) no tengo instalado pamac, en su lugar puse octopi por aquello de las librerías Qt y porque se integra bien con pacaur.
En general siempre tiro de linea de comandos, lo de octopi lo utilizo más para hacer búsquedas generales, obtener información de programas disponibles, etc..
De todas maneras es interesante ese parche que comentas y una de las razones de porque antes utilizaba yaourt en mis tutoriales era que venía integrado en pamac, y por aquello de que no conviene mezclar dos helpers diferentes.
Muchas gracias por la respuesta. Acabo de mirar el repo de Github de pamac pero entre que no tengo idea de vala y que son las horas que son no he conseguido ver cómo instala los paquetes AUR. Si a alguien tiene curiosidad aquí tiene el código: https://github.com/manjaro/pamac
Yo también tengo la misma pregunta que Diego, utilizo Pamac (la interfaz gráfica) y también tengo instalado yaourt. Si lo cambio por pacaur ¿pamac utilizará pacaur en lugar de yaourt para compilar e instalar los paquetes de aur?
Hola. Muchas gracias.
Por si te interesa, me gustaría saber cómo se arman los archivos estos de la comunidad. Los pkgbuild para poder quizás armar alguno.
Un saludo
En la wiki de Arch Linux hay información al respecto. Pero me apunto lo que dices, alrededor de eso seguro que se puede escribir algo 🙂
Saludos!
He hecho la prueba, he desinstalado yaourt e instalado pacaur. Desde pamac he instalado un paquete de AUR y funciona. Entiendo que estoy utilizando pacaur ahora. Utilizo la distribución Arch-anywhere (ahora Anarchy) con escritorio Plasma.
Rectifico, tal y como dice tannhausser, para Pamac no es necesario ningún helper con AUR. He quitado pacaur y también funciona.
Buen artículo pero hay que tomarlo con pinzas y esto va a levantar ampollas: La posibilidad de darle autonomía a cualquiera para agregar paquetes a un repositorio sin ser desarrollador o creador de aplicaciones es un peligro latente y justo ahora es un problema que salió de control.
Este es el grave problema del repositorio AUR de ArchLinux. Es común encontrar dos y tres versiones de un mismo paquete y la única forma que tiene un usuario común y silvestre para proceder a instalar es guiarse por la cantidad de votos y esto no es seguridad de nada. Muchos empaquetadores son anónimos y sin relación alguna con la aplicación oficial, son voluntarios que saben manejar la terminal y precompilan los PKGBUILD para que el usuario haga el resto con su respectivo Pacman a través de Yaourt. Si el paquete presenta problemas proceden al siguiente en votación. Muchos paquetes oficiales son «tuneados» al parecer caprichoso de su empaquetador y eso me deja una profunda desconfianza así se pueda verificar el código fuente.
El más delicado problema que presenta Arch y sus derivadas es la innecesaria capa de intermediarios empaquetadores entre el paquete oficial (su desarrollador) y el usuario final. Entiendo que no les queda de otra dado que los repositorios oficiales son muy limitados.
Esto en mi humilde opinión es una irresponsabilidad. Es como si en la PlayStore o AppStore para el caso de los smartphones se encontraran dos y tres aplicaciones para un mismo Banco, una oficial y las demás de gente X ofreciendo entrar a hacer las mismas operaciones que la aplicación oficial. De seguro el Staff de abogados de ese banco demandaría a los clones por estafa intencional a sus tarjetahabientes y pedirían a los titulares de esos repositorios la dada de baja inmediata. En GNU/Linux esto no es tan así por tres motivos: uno, las aplicaciones son de genérica productividad en escritorio sin mayor importancia, dos, quien se atreva a publicar debe atenerse a las licencias de Software Libre y tres, no hay quien tenga pantalones y carácter para poner reglas claras y estrictas a estas parrandas tropicales que son los repositorios comunitarios AUR.
Son muchos los usuarios experimentados encontrados en las wikis internacionales de Arch, Manjaro o Antergos quejarse de esto mismo y tratan de no tirar ese repositorio AUR y más bien hacer el trabajo de compilar e instalar sus propios paquetes desde la fuente. Esto desde luego para cristiano de a pie es poco probable así unos digan que es pan caliente en panadería por la mañana. En lo personal sólo instalo paquetes oficiales de repositorios oficiales. Huyo de repositorios que parecen plazas de mercado. Comprendo que este comentario hiere susceptibilidades pero alguien tenía que escribir sobre esto.
En resumidas cuentas, mucha «libertad» es dañino para la comunidad…
No sé donde está el problema. No será por no advertir que los repositorios de AUR no son oficiales, o sea, que la gente que lo utiliza ya sabe perfectamente lo que instala o a que se arriesga. Hay gente que compila, y gente que prefiere,(o no sabe) hacerlo, y otros lo hacen por ellos, los dos tienen derecho y opciones.
Por cierto, estoy esperando fervientemente que alguna vez, en vez de quejarse tanto, esos usuarios experimentados que vagan por los foros, se pongan manos a la obra y creen un repositorio oficial para que nadie necesite de AUR, o que sea una buena alternativa a este repo comunitario. O si ya hay alguno de ese estilo, (que lo ignoro) , ponerse a disposición para ayudar en lo que se pueda.
Pero como siempre ¡no!, Es más fácil quejarse amargamente por los foros, y decir que vaya «despiporre», que ponerse a trabajar de gratis, (no lo olvidemos) , en beneficio de la comunidad.
Yo estoy de acuerdo. Añado que yo cuando estaba en mint era incluso peor el tener que añadir un PPA para instalar un programa que no estaba en los repos. Nunca me ha gustado mucho la idea de instalarlos compilando o descargandose el binario como harías en Windows. Me parece un error porque o bien el programa se queda desactualizado o es el propio programa el que tiene que comprobar las actualizaciones. No hay nada más odioso que arrancar un programa y que te diga que instales una actualización. O peor aún, que tenga un servicio por detrás funcionando continuamente comprobando las actualizaciones.
Desconozco cuál es el criterio que necesita un paquete para que sea admitido en los repositorios oficiales, que sería lo ideal, pero a falta de eso me quedo con AUR.
hola una pregunta, en aur ¿no se descarga el código fuente oficial de la aplicación y luego se compila e instala? si es así no veo problema pero igual estoy equivocado.
Es como dices y lo hace en un entorno que no es root (fakeroot).
Si no te fías siempre puedes mirar el script de instalación y comprobar la procedencia del código fuente, los comandos de batch incluidos, etc. Especialmente si hablamos de programas poco conocidos.
Además existe una herramienta llamada Namcap que puede ayudar en el tema
era lo que tenía entendido, entonces yo no veo problemas de seguridad en usar Aur, lo digo por el comentario anterior del usuario Shalem Dior Juz donde critica a Aur y comenta de la cantidad de empaquetadores que hay de por medio.
Lo de siempre en Linux, uno te dice una cosa, otro te dice otra y casi siempre lo que te dicen no funciona, entonces comienzas un largo peregrinar por Google para ver si encuentras a UNO que te diga la que te sirve, por ejemplo para instalar 4KDownloader en Arch, una cosa que en Windows haces con dos clicks….Linux
Me ha sorprendido que hubiera un comentario al respecto de un artículo publicado hace 4 años en este blog que lamentablemente está descontinuado por su autor.
Sí, es cierto que a menudo en GNU/Linux hay que indagar para buscar solución a los problemas. Esto está motivado por la gran diversidad que hay y por tanto la casuística es muy variada pero en mi opinión merece la pena porque se acaba solucionando. Esto no es motivo para echar por tierra el sistema operativo y su comunidad. Por tanto, unas bases comunes y luego una personalización tan amplia como se quiera sería, creo una buena apuesta.