Si usas Arch Linux o alguna de sus derivadas (EndeavourOS, Manjaro, Artix, etc.), tarde o temprano acabas topándote con los repositorios AUR y los famosos asistentes yay y paru. Todo el mundo habla de ellos, se recomiendan en foros, aparecen en casi todas las guías, pero cuando intentas decidir cuál usar, las diferencias no siempre quedan tan claras.
En las siguientes líneas vamos a desgranar con calma qué ofrece cada uno, qué opiniones reales tiene la comunidad, qué mitos hay alrededor de que “yay está muerto” o “paru es mucho más rápido”, y en qué casos compensa cambiar de uno a otro. La idea es que, al terminar, tengas argumentos sólidos para elegir asistente sin comerte demasiado la cabeza.
Qué son yay y paru y por qué todo el mundo los usa
A grandes rasgos, tanto yay como paru son asistentes de AUR que automatizan el trabajo de buscar, compilar e instalar paquetes del AUR, además de gestionar paquetes de los repos oficiales usando pacman por debajo. Es decir, en lugar de ir manualmente a la web de AUR, descargar el PKGBUILD, ejecutar makepkg y luego instalar el paquete, ellos hacen todo eso de una tacada.
En entornos Arch y derivados es muy habitual querer acceder al inmenso catálogo de software disponible en AUR. Ahí encuentras aplicaciones que no están en los repos oficiales, versiones git, parches experimentales o simplemente programas que nadie ha empaquetado oficialmente; por ejemplo, guías para instalar Visual Studio Code en Arch. Para gestionar todo eso con cierta comodidad, la mayoría acaba usando un asistente, y ahí es donde entran en juego yay y paru como dos de las opciones más populares.
Yay lleva ya muchos años siendo uno de los nombres de referencia: es conocido, documentado, tiene una comunidad enorme y aparece por defecto en distros como EndeavourOS. Paru, por su parte, es más reciente, pero ha ganado bastante tracción porque ofrece una aproximación algo más estricta y segura al flujo de trabajo del AUR, y porque su autor estuvo relacionado con el desarrollo de yay en el pasado.
Diferencias técnicas: Go vs Rust, diseño y filosofía
Un punto que suele salir en todos los debates es que yay está escrito en Go y paru está escrito en Rust. Técnicamente esto importa menos al usuario final de lo que a veces se sugiere, pero sí dice algo del enfoque de cada proyecto.
Yay, desarrollado en Go, se inspira en antiguos asistentes como yaourt, apacman y pacaur. Su código resulta relativamente sencillo de leer y extender para quien domine Go, y una de sus virtudes históricas ha sido justamente que la compilación es rápida y poco dolorosa. Esa base ha permitido que se mantenga vivo incluso tras cambios en el equipo de desarrollo.
Paru, en cambio, está implementado en Rust y bebe directamente de la experiencia de yay, tanto en funcionalidades como en diseño de la interfaz de línea de comandos. Gracias a ello, migrar de yay a paru resulta muy sencillo: muchos comandos y opciones se sienten casi iguales, por lo que no hay que reaprenderlo todo desde cero.
A nivel filosófico, paru pone algo más de énfasis en la seguridad y la revisión de PKGBUILDs, mientras que yay ha tendido históricamente a priorizar un flujo más rápido y cómodo por defecto. Esa diferencia se ve con claridad en cómo cada uno te presenta los archivos antes de construir los paquetes.
Velocidad: ¿es paru realmente más rápido que yay?
Uno de los argumentos más repetidos en foros y redes es que paru es “más rápido” que yay. Aquí conviene matizar. Varios usuarios con hardware potente y buena conexión (por ejemplo, fibra de 1 Gbps) comentan que, en la práctica, la sensación de velocidad entre uno y otro es muy similar. En sistemas así, a menudo el cuello de botella es la descarga o la propia compilación del software, no tanto el asistente.
Aun así, hay quien ha comparado ambos en máquinas más modestas y asegura que paru realiza ciertas operaciones algo más deprisa, especialmente cuando se hacen búsquedas, sincronizaciones o actualizaciones globales que implican tanto repos oficiales como AUR. Esa diferencia no suele ser brutal, pero en equipos con pocos recursos o discos lentos puede notarse unos segundos de mejora aquí y allá.
La otra cara de la moneda es que paru te fuerza por defecto a revisar los PKGBUILDs antes de compilar. Esto añade un paso interactivo que, obviamente, consume tiempo humano (aunque sea poco). Algunos usuarios perciben esto como un “ralentizador”, mientras que otros lo consideran un compromiso razonable porque aporta seguridad y transparencia.
En resumen, si tienes un ordenador moderno y una buena conexión, las diferencias en velocidad entre yay y paru van a ser muy pequeñas. Donde realmente puede merecer la pena inclinarse por paru es en sistemas limitados donde cada segundo cuenta, o si quieres un asistente que esté optimizado hasta el detalle y notes esa ligera ventaja.
Sintaxis y experiencia de uso: lo que se siente al teclear
Más allá de benchmarks y discusiones técnicas, muchos usuarios se quedan con yay por un motivo bastante mundano: es muy cómodo de escribir. Hay quien comenta que literalmente “machaca las dos teclas a la vez” para lanzar yay porque es corto, fácil de recordar y de autocompletar en la terminal.
Paru tampoco es que sea un nombre horrible, pero algunas personas comentan que su sintaxis se les hace un poco más “tosca” al usarlo diariamente. No es que los comandos sean muy diferentes, pero la costumbre pesa, y quienes llevan años con yay sienten que el flujo de uso es más natural y rápido, tanto mentalmente como al teclear.
En cualquier caso, ambos asistentes proporcionan atajos, opciones interactivas y banderas muy similares. Por ejemplo, funciones como mostrar un menú combinado de actualizaciones de repos y AUR con detalles de versión están disponibles en los dos. En yay existe la opción --combinedupgrade, que muestra un listado coloreado con qué se va a actualizar y de qué versión a cuál. En paru se consigue algo equiparable mediante la opción --upgrademenu, que ofrece un menú detallado de actualizaciones.
Un detalle curioso que aparece en algunos hilos es que hay usuarios que incluso crean alias como yaya para yay, porque les resulta todavía más cómodo y divertido invocarlo así. Esto ilustra bien hasta qué punto la ergonomía y la costumbre tienen un peso muy real a la hora de elegir asistente.
Dónde guarda cada uno los paquetes compilados
Otro aspecto interesante que suele pasar desapercibido es la gestión de los paquetes ya construidos (los .pkg.tar.zst). Aquí yay y paru se comportan de forma ligeramente diferente, y eso afecta a cómo se integran con las rutas típicas de Arch.
Por defecto, makepkg coloca los paquetes construidos en el directorio de compilación. Esa ruta puede ajustarse mediante la variable PKGDEST en /etc/makepkg.conf, de modo que podrías, por ejemplo, enviarlos a /var/cache/pacman/pkg/ para centralizar los binarios empaquetados.
En el caso de paru, este respeta el comportamiento habitual de makepkg: los paquetes terminan en el directorio de compilación asociado a paru, normalmente algo como ~/.cache/paru/clone/$pkgname/. Si quieres modificar esa ruta globalmente, puedes usar la opción BuildDir en /etc/paru.conf, reenviando las compilaciones a otro sitio.
Yay se comporta de forma algo distinta. Varios usuarios señalan que yay copia los paquetes construidos a /var/cache/pacman/pkg/ después de compilarlos, lo que en la práctica hace que tengas tus paquetes AUR en el mismo sitio que los paquetes oficiales gestionados por pacman. Esto es cómodo pero implica que yay está, en cierto modo, pisando lo que hayas definido en PKGDEST en /etc/makepkg.conf, algo que algunos consideran poco respetuoso con la configuración global del sistema.
Para el usuario medio esto no suele ser un drama, pero si eres muy tiquismiquis con la forma en que se organizan los binarios en tu máquina, puede ser un motivo para preferir el comportamiento más “limpio” de paru, o al menos para ser consciente de lo que está haciendo cada asistente con tus paquetes.
Nivel de mantenimiento y actividad de cada proyecto
En distintos debates se ha extendido la idea de que yay está abandonado o desfasado y que paru es su reemplazo natural. Esta afirmación viene en parte de que uno de los desarrolladores relacionados con yay pasó a centrarse en paru, y en algunos vídeos y posts se interpretó eso como que el proyecto yay moría o quedaba sin mantenimiento.
Varios usuarios y desarrolladores han desmentido esa narrativa de forma tajante: yay sigue teniendo mantenimiento activo, con commits frecuentes en su repositorio y una comunidad bastante amplia detrás. De hecho, parte del enfado de algunos mantenedores viene precisamente de ver cómo se repite una y otra vez el mantra “yay está muerto” sin que la gente se moleste en comprobar el estado real del proyecto.
Al mismo tiempo, es cierto que paru muestra una actividad muy alta y constante, a veces incluso algo superior a la de yay en determinados periodos. Esto es lógico, ya que se trata de un proyecto relativamente nuevo, con muchas ganas de iterar y pulir detalles, y con un autor muy implicado que responde con rapidez a issues y peticiones de la comunidad.
En la práctica, para la persona que simplemente quiere instalar paquetes, estas diferencias de actividad rara vez se traducen en problemas. Ambos proyectos están vivos, reciben correcciones y nuevas funciones, y no hay nada que obligue a abandonar yay por miedo a que quede roto a corto plazo.
Seguridad, revisión de PKGBUILDs y filosofía de uso del AUR
Un punto clave donde sí se perciben diferencias claras de enfoque es cómo cada asistente trata la revisión de PKGBUILDs. Recordemos que AUR no es un repositorio oficial: son recetas enviadas por usuarios, y la responsabilidad final de revisarlas es tuya.
La comunidad de Arch insiste desde siempre en que hay que leer los PKGBUILDs antes de instalarlos, para evitar sorpresas desagradables (scripts maliciosos, descargas desde orígenes poco fiables, comandos peligrosos, etc.). Paru, alineado con esa filosofía, está configurado por defecto para mostrarte esa revisión y “obligarte” a prestarle atención antes de construir el paquete.
Yay, aunque también permite revisar los PKGBUILDs, facilita un flujo más “rápido y despreocupado” si quieres ir a tiro hecho. Esto gusta mucho a quien prioriza comodidad y confía en los mantenedores de AUR, pero también ha generado la percepción de que yay anima un poco más al “instalo sin mirar”, algo que no casa del todo con la mentalidad purista de Arch.
En cualquier caso, es importante recordar que, uses el asistente que uses, todo acaba pasando por makepkg y pacman. Es decir, ambos ayudan a automatizar la parte pesada, pero el modelo base sigue siendo el mismo: PKGBUILDs que se convierten en paquetes que pacman gestiona e instala. La responsabilidad de entender lo que instalas sigue siendo tuya.
Uso del AUR sin asistentes y el papel de pacman
En varios hilos también aparece una pregunta recurrente: “¿cómo actualizas paquetes del AUR sin usar un asistente?”. La respuesta ortodoxa, que enlaza directamente con la filosofía oficial de Arch, es clara: usando makepkg a mano con los PKGBUILDs correspondientes.
Los PKGBUILDs son recetas que definen cómo construir el paquete desde el código fuente o desde binarios precompilados, y una vez generado ese paquete, es pacman quien se encarga de instalarlo y de llevar el registro, igual que hace con los paquetes de los repos oficiales. No hay un tratamiento especial por ser “AUR”: para pacman, una vez empaquetado, todo es simplemente un paquete más.
Los asistentes como yay y paru no son más que capas de comodidad encima de ese flujo clásico de “bajar PKGBUILD → makepkg → pacman”. Hacen búsquedas, resuelven dependencias, automatizan descargas y compilaciones, y añaden menús y opciones útiles, pero no sustituyen ni modifican el rol de pacman como gestor central del sistema.
Por eso hay usuarios veteranos que presumen de no usar asistentes nunca y defender el método manual como el más transparente y controlable. Otros, la mayoría, prefieren ahorrar tiempo y tirar de yay o paru, confiando en que la automatización les simplifica la vida sin perder de vista del todo lo que están haciendo.
Paru y yay en distros derivadas: EndeavourOS, Manjaro, Artix…
En distros como EndeavourOS, yay suele venir preinstalado o recomendado como asistente principal. Esto marca bastante la experiencia de los recién llegados, que adoptan yay sin pensar demasiado porque es lo que trae el sistema y la documentación oficial. Posteriormente pueden descubrir paru y plantearse si merece la pena el cambio.
En algunos debates dentro de la propia comunidad de EndeavourOS se ha planteado si deberían pasar a incluir paru por defecto. Muchos usuarios y miembros del equipo han respondido que no ven una necesidad real de hacerlo, ya que yay sigue siendo una herramienta sólida, mantenida y bien conocida. En consecuencia, a corto y medio plazo, no parece que vaya a haber una sustitución masiva de yay por paru en esta distro.
En otras derivadas de Arch (Artix, Manjaro, etc.), la situación es parecida: lo importante es tener acceso al AUR y la posibilidad de usar un asistente, pero cuál uses al final suele depender de lo que recomiende la documentación, lo que diga la comunidad o simplemente de lo que probaste primero y te funcionó bien.
También es frecuente que se sugiera activar repositorios externos como Chaotic-AUR para facilitar la instalación de estos asistentes sin tener que compilar desde el propio AUR. En algunos tutoriales se explica cómo preparar el sistema, añadir dichos repos y luego instalar yay o paru directamente como paquetes binarios, evitando el paso de construcción manual inicial.
Instalar y convivir con ambos asistentes
Una opción que defienden bastantes usuarios, sobre todo quienes están probando cosas, es instalar tanto yay como paru y convivir con ambos una temporada. De esta forma puedes usar yay para lo que ya haces por costumbre y experimentar con paru en tareas puntuales, comparando sensaciones y características en tu propio hardware.
Al ser herramientas que se apoyan en pacman y makepkg, no se pisan ni rompen el sistema por coexistir. Puedes instalar paquetes con uno, listar actualizaciones con otro y seguir funcionando sin mayores dramas, siempre y cuando sepas qué estás haciendo. Cuando tengas claras tus preferencias, si quieres simplificar, puedes quedarte solo con el que más te convenza y desinstalar el otro.
En algunos casos específicos se recomienda instalar paru usando yay (ya que yay viene de serie en la distro), probarlo, y si te convence, cambiar tus scripts, alias y costumbres a paru y luego prescindir de yay. Pero, insistiendo una vez más, no hay obligación técnica de hacer este cambio; es más una cuestión de gustos y filosofía.
Por otro lado, hay quien prefiere seguir siempre el método “vanilla”: instalar los asistentes desde el propio AUR usando makepkg, para mantener la coherencia con la filosofía Arch pura y dura. En cualquiera de los casos, el resultado final es el mismo: tienes un asistente funcional que te simplifica el uso de AUR.
Mirando todos estos matices en conjunto, lo que se ve claro es que ambos asistentes cubren muy bien las necesidades del usuario medio de Arch: automatizar el trato con AUR, mantener el sistema al día y ofrecer ciertas comodidades que pacman, por diseño, no proporciona. Paru pone un poco más el foco en revisiones y en un rendimiento algo más afinado, mientras que yay ofrece una experiencia extremadamente familiar, rápida de teclear y con años de rodaje, lo que explica por qué tanta gente sigue fiel a él a pesar de la llegada de alternativas nuevas.
from Linux Adictos https://ift.tt/wUsmaIc
via IFTTT
Pacosite's Blog 