Re: (optional) AUR helper in archinstall
Please forgive me for playing devil's advocate here, but I see that many of you are strongly opposed to adding an AUR helper to archinstall because “AUR packages shouldn't be in official repositories,” and yet we have aurpublish [1] in the extra repository. In my opinion, having some AUR helpers maintained as extra packages (such as paru or yay, which are the most widely used) is just like any other package maintained in the extra repository, and having them there would certainly make life easier for many users, since they wouldn’t face the chicken-and-egg problem when they start using AUR. I think a simple notice stating that this is no longer supported and that you use it at your own risk is sufficient. Ultimately, it’s about making life easier for the user. Greetings. [1]: https://archlinux.org/packages/extra/any/aurpublish/ -- Óscar García Amor | ogarcia at moire.org | http://ogarcia.me
On Fri, 2026-04-24 at 08:38 +0200, Óscar García Amor wrote:
In my opinion, having some AUR helpers maintained as extra packages (such as paru or yay, which are the most widely used) is just like any other package maintained in the extra repository, and having them there would certainly make life easier for many users, since they wouldn’t face the chicken-and-egg problem when they start using AUR.
Hi, I'm not against an AUR helper in extra, however, it’s really an exaggeration to call it a chicken-and-egg problem when users can’t install an AUR helper from the official repositories, since you don’t actually need a helper to build and install from the AUR. In fact, a helper can actually be a source of errors. Regards, Ralf
Am 24.04.26 um 09:06 schrieb Ralf Mardorf:
On Fri, 2026-04-24 at 08:38 +0200, Óscar García Amor wrote:
In my opinion, having some AUR helpers maintained as extra packages (such as paru or yay, which are the most widely used) is just like any other package maintained in the extra repository, and having them there would certainly make life easier for many users, since they wouldn’t face the chicken-and-egg problem when they start using AUR.
Hi,
I'm not against an AUR helper in extra, however, it’s really an exaggeration to call it a chicken-and-egg problem when users can’t install an AUR helper from the official repositories, since you don’t actually need a helper to build and install from the AUR. In fact, a helper can actually be a source of errors.
Regards, Ralf
I'd go as far and say that AUR helpers are for those that have understood the process and want it automated. Thus for someone installing Arch for the first time, they should take the time and learn how to build packages before using an AUR helper. Even if it is only the AUR helper itself that is built manually. And for someone experienced building the helper is no stress at all. My 2 cents, Uwe
On 2026-04-24 09:36, Uwe Sauter wrote:
I'd go as far and say that AUR helpers are for those that have understood the process and want it automated. Thus for someone installing Arch for the first time, they should take the time and learn how to build packages before using an AUR helper. Even if it is only the AUR helper itself that is built manually.
And for someone experienced building the helper is no stress at all.
I think this is more or less the general consensus on this topic, at least of the devs? It seems to me that this is what I have mostly been reading on the topic of AUR helpers. The one place where I can see that this might be a big bother, is for still somewhat common drivers (I wil use the nvidia-580xx driver by way of example here). Someone new to Arch Linux would probably benefit from a GUI, so that they can easily read the Wiki while attempting to install from the AUR. At the same time, they might find that their video card is no longer supported by the nvidia driver in the repo. Building that one from scratch might be a hurdle. As an aside: In a VM, for testing purposes, you would not have to build the nvidia-580 driver (and if someone is capable of setting up a video card pass-through, then that person is probably okay building that driver as well). However, to me this would indicate that we might want to consider either having some more heavily used drivers back in repos (nvidia, wifi chips come to mind. which would block a new user from getting into a working GUI with Internet); or have an unofficial repo with those drivers, and point new people there until they have their system set up and could change to AUR packages. Back to the general discussion: I don't think AUR helpers should be in official repos, because AUR software is not supported by Arch Linux, and not tested, vetted, audited or anything by the devs. Besides for the reasons brought forward by `kpcyrd`, I think this is important, too. Great discussion, thank you for bringing it up, and for all the contributions. Kind regards, Edmund -- Edmund Lodewijks <edmund@proteamail.com> TZ: UCT+2 / GMT+2
On Fri Apr 24, 2026 at 9:36 AM CEST, Uwe Sauter wrote: [...]
I'd go as far and say that AUR helpers are for those that have understood the process and want it automated. Thus for someone installing Arch for the first time, they should take the time and learn how to build packages before using an AUR helper. Even if it is only the AUR helper itself that is built manually.
And for someone experienced building the helper is no stress at all.
My 2 cents,
Uwe
I'm going to side with this. Being new to archlinux and first manually installing some AUR packages before you discover the helpers is a flow that should be promoted. Once you encounter AUR packages depending on other AUR packages you discover where helpers actually help. For experienced users, downloading a snapshot and running `makepkg` is not particularly cumbersome. Br, Linus
On Fri, 2026-04-24 at 12:23 +0200, Linus Probert wrote:
For experienced users, downloading a snapshot and running `makepkg` is not particularly cumbersome.
There are situations where you either need to know how something works or you need to learn it. If you need help with this, you can find it in the Arch Linux forums, for example. Building in a clean chroot or the question of whether or not you can build in tmpfs are the first things that come to my mind in this context. I don’t believe that users should be denied packages as a teaching tool, but they should understand that it’s not a problem if an AUR helper isn’t provided by the official repositories. Personally, I think that pacman-static, even though I’ve never needed it myself, fits better in official repositories than an AUR helper. Unless I need to compile something in a clean chroot environment, I stick with yaourt. Just because yaourt is blind in one eye and missing a paw doesn’t mean you should put it down. Instead, you stick a repair patch here and there on a gaping wound. If yaourt were a cat, you wouldn't just throw it away and buy a new one. -- What have you done to the cat? It looks half-dead. - Schrödingers's wife
El vie, 24-04-2026 a las 09:06 +0200, Ralf Mardorf escribió:
I'm not against an AUR helper in extra, however, it’s really an exaggeration to call it a chicken-and-egg problem when users can’t install an AUR helper from the official repositories, since you don’t actually need a helper to build and install from the AUR. In fact, a helper can actually be a source of errors.
I really don't think it's an exaggeration; it's just that I might not have expressed myself clearly (English isn't my native language). What I mean by the chicken-and-egg problem is that newer users might find it a bit difficult to build the AUR helper from scratch and then install packages from the AUR, but if you provide it to them pre-built, you make things a lot easier for them. In any case, it’s clear that using an AUR helper, or even without one, can cause problems when building an AUR package. I don’t dispute that. Greetings. -- Óscar García Amor | ogarcia at moire.org | http://ogarcia.me
Am 24.04.26 um 09:38 schrieb Óscar García Amor: What
I mean by the chicken-and-egg problem is that newer users might find it a bit difficult to build the AUR helper from scratch
As others pointed out: That's intentionally! You should not use the AUR if you don't know that "building a package" entails and what parts an AUR helper automates and what parts it does not. Call it the "entrance exam" :)
El vie, 24-04-2026 a las 09:50 +0200, René 'Necoro' Neumann escribió:
As others pointed out: That's intentionally! You should not use the AUR if you don't know that "building a package" entails and what parts an AUR helper automates and what parts it does not. Call it the "entrance exam" :)
True, you could look at it that way. But IMHO, that doesn't guarantee that the user knows what they're doing. They could very well be following a guide that tells them which commands to run without understanding any of it at all. In my view, whether or not an AUR helper is included in the extra repository is simply a matter of convenience for the user, to avoid having to build it. It doesn’t add to or detract from security because, as I said before, a user can always do things without understanding what they’re doing (and even more so now with AI assistants). Greetings. -- Óscar García Amor | ogarcia at moire.org | http://ogarcia.me
yay has +2560 and paru has +1181, both of these are popular enough to be considered adopted as extra. Both have `-bin` version of precompiled packages, which I'd assume many would resort to if build fails for them.
You should not use the AUR if you don't know that "building a package" entails and what parts an AUR helper automates and what parts it does not. Call it the "entrance exam" :)
If the goal here is to protect the user, wouldn't it make sense to have vetted AUR helper that follows certain criteria, such as showing PKGBUILD, tell them about how these are community maintained? Imagine if there were a "very-helpful" AUR helper that promises auto update, zero user interaction, completely shielding users from the build process. Vetting known-good helpers would prevent those helpers from getting main stream, while funneling users to understand the build system. I think the goal should be helping user while keeping them safe, rather than letting them figure out things on their own and potentially seeking the easy (wrong) way out.
On Fri, 24 Apr 2026 at 10:54, <evansjahja13@gmail.com> wrote:
yay has +2560 and paru has +1181, both of these are popular enough to be considered adopted as extra.
I've always considered AUR as non official, user submitted, non vetted Having an AUR helper inside core or extra flies against that and may imply an endorsement Maybe a fake package can be added that explains how to get the helpers and add appropriate warnings
On Fri, Apr 24, 2026 at 06:54:01PM +0900, evansjahja13@gmail.com wrote:
Imagine if there were a "very-helpful" AUR helper that promises auto update, zero user interaction, completely shielding users from the build process.
Vetting known-good helpers would prevent those helpers from getting main stream, while funneling users to understand the build system.
This is not possible. Shielding the user from the build process is exactly what we do not want to do, and what a good helper (like yay) does. There is nothing lacking in the current helpers, functionality wise, but its goals contradict with the Arch developers' pedagogical goals. Sam
paru (which I use almost exclusively for building AUR packages, except my own and when things severely break) shows you the PKGBUILD and every single file in the package repo, including with diffs if you are updating the package. There is the --skipreview flag but it’s not the default (and I only found out now that it exists when double-checking the CLI). All to say that paru, from a users perspective, is barely doing anything more than git clone https://aur.archlinux.org/<pkgname>.git cd <pkgname> git diff ..<origin commit or previous commit> makepkg -i meanwhile the output of all relevant commands is displayed as if you ran them yourself. Anyone who wants to spend less time fiddling with AUR packages would have written a shell script like that sooner or later. In my opinion, paru is much better than packagekit, which was yeeted/is in an unsupported state (at least for pacman) for the same Arch philosophy reasons. I don’t personally agree with that change, but since/if we agree that packagekit is bad, then I don’t think we can agree that paru is equally bad, as it is explicitly upholding all principles of using AUR packages: check everything in the package repo, show all output of all commands to the user, allow them to cancel at any time, etc. etc. The main thing we lose is people not knowing how to operate makepkg, whose primary CLI options can be learned in 5 minutes and are ultimately very simple. People won’t learn PKGBUILDs faster or slower through either method, as they both allow you to skip reviewing and understanding them. At least paru puts the PKGBUILD prominently on your screen, and you have to press two keys to continue. No such feature exists in makepkg (or in pkgctl, FWIW). All to say that these arguments are a bit hypocritical, since it’s already so easy to build AUR packages in a careless manner. I would argue that at least paru makes this harder (while still saving time). I have never used yay so maybe the situation is worse there, I can’t speak to that. ~ kleines Filmröllchen
On Fri, Apr 24, 2026 at 01:37:59PM +0200, kleines Filmröllchen wrote:
paru (which I use almost exclusively for building AUR packages, except my own and when things severely break) shows you the PKGBUILD and every single file in the package repo, including with diffs if you are updating the package. There is the --skipreview flag but it’s not the default (and I only found out now that it exists when double-checking the CLI).
All to say that these arguments are a bit hypocritical, since it’s already so easy to build AUR packages in a careless manner. I would argue that at least paru makes this harder (while still saving time). I have never used yay so maybe the situation is worse there, I can’t speak to that.
That's actually sounds really good. The main reason why I use yay is because of popularism (at the time) and it sticked with me. I have not used paru, mostly because I didn't know about the pros/cons of all the different AUR helper. I might just switch to paru then
On 4/24/26 1:37 PM, kleines Filmröllchen wrote:
paru (which I use almost exclusively for building AUR packages, except my own and when things severely break) shows you the PKGBUILD and every single file in the package repo, including with diffs if you are updating the package. There is the --skipreview flag but it’s not the default (and I only found out now that it exists when double-checking the CLI).
All to say that paru, from a users perspective, is barely doing anything more than
git clone https://aur.archlinux.org/<pkgname>.git cd <pkgname> git diff ..<origin commit or previous commit> makepkg -i
The main advantage of AUR helper is dependency management - if I want to install package X, helper will install all dependencies from AUR and from official repos. Doing it by hand with makepkg is cumbersome. Regrds, Łukasz
On Fri, 2026-04-24 at 14:52 +0200, Łukasz Michalski wrote:
The main advantage of AUR helper is dependency management - if I want to install package X, helper will install all dependencies from AUR and from official repos. Doing it by hand with makepkg is cumbersome.
• rocketmouse@archlinux ~ $ makepkg --help | grep Install\ missing\ dependencies -s, --syncdeps Install missing dependencies with pacman Of course, only if these dependencies are provided by official repositories. I see a growing risk in the automated installation of dependencies and the dependencies of those dependencies, and the dependencies of those dependencies, and the dependencies of those dependencies... from the AUR. Of course, responsible users should be able to decide for themselves whether they want to take such a risk, but there is a compelling argument against including such a feature in the official repositories and certainly against making it available in an installer. This isn't about education, it's about security. -- The S in IoT stands for security.
On 4/24/26 8:27 AM, Ralf Mardorf wrote:
This isn't about education, it's about security.
Agreed, The priority should be safeguarding the distribution against sprawling dependencies outside the official distribution, and especially in the current climate where lag time between identifying a bad package and removing it can impact a large number in that supply chain. The KISS philosophy has served Arch well. People can use whatever AUR helper they like, but that doesn't mean any particular help need be made part of the official distro. Ralf has nailed the salient point. -- David C. Rankin, J.D.,P.E.
Arch Linux does have pip, npm and many other package managers in the official repos, which can be used to install external packages, many of which are user submitted. Why is an AUR helper any different? Pulkit Krishna On Sat, Apr 25, 2026 at 11:53 AM David C Rankin <drankinatty@gmail.com> wrote:
On 4/24/26 8:27 AM, Ralf Mardorf wrote:
This isn't about education, it's about security.
Agreed,
The priority should be safeguarding the distribution against sprawling dependencies outside the official distribution, and especially in the current climate where lag time between identifying a bad package and removing it can impact a large number in that supply chain.
The KISS philosophy has served Arch well.
People can use whatever AUR helper they like, but that doesn't mean any particular help need be made part of the official distro. Ralf has nailed the salient point.
-- David C. Rankin, J.D.,P.E.
I think Linux is better than FreeBSD in so many ways, but sometimes, well, sometimes... ;) On Sat, 2026-04-25 at 12:12 +0530, Pulkit Krishna wrote:
pip
Pip and Friends, as well as Flatpaks and Snaps, are a whole different story, if you start mixing that up with a distro’s native package management, you might as well just light a can of gasoline on fire. Please, don't open that can of worms! There is a difference!
El sáb, 25-04-2026 a las 09:04 +0200, Ralf Mardorf escribió:
Pip and Friends, as well as Flatpaks and Snaps, are a whole different story, if you start mixing that up with a distro’s native package management, you might as well just light a can of gasoline on fire.
Pip, when run as root, can cause far more damage than simply installing packages from the AUR. Ultimately, the reality is that any tool used without proper oversight can break your system, so if the decision not to include an AUR helper is for security reasons, then it’s better not to include anything at all. ;-) Greetings. -- Óscar García Amor | ogarcia at moire.org | http://ogarcia.me
On Sat, 2026-04-25 at 09:17 +0200, Óscar García Amor wrote:
Pip, when run as root, can cause far more damage than simply installing packages from the AUR.
I completely agree with that, but on the other hand, if you install dependencies on top of dependencies on top of dependencies... using an AUR helper as root, that can have just as bad consequences as installing something via pip and friends. To stick with pip: No one is forcing you to use Python. However, once you’ve chosen a Linux distribution, you’re dependent on that distribution’s package management system and security team. There’s a difference, I’m not claiming that pip and its friends are harmless, but that’s not the topic of this thread.
El sáb, 25-04-2026 a las 09:32 +0200, Ralf Mardorf escribió:
[..] using an AUR helper as root [..]
As far as I know, you can't do that. The pkgbuild tools (which is ultimately what AUR helpers use) don't allow you to run them as root, so you couldn't run an AUR helper as root under any circumstances. In fact, the only thing helpers do as root (using sudo or similar) is install the resulting package once it's been created.
To stick with pip: No one is forcing you to use Python.[..]
No one is forcing you to use packages from the AUR, either. ¯\_(ツ)_/¯
There’s a difference, I’m not claiming that pip and its friends are harmless, but that’s not the topic of this thread.
As far as safety is concerned, I personally don't see any difference. Both systems can cause a lot of harm if things are done wrong. Greetings. -- Óscar García Amor | ogarcia at moire.org | http://ogarcia.me
On Sat, 2026-04-25 at 09:51 +0200, Óscar García Amor wrote:
El sáb, 25-04-2026 a las 09:32 +0200, Ralf Mardorf escribió:
[..] using an AUR helper as root [..]
As far as I know, you can't do that.
So we find ourselves in a dilemma, and we could start a discussion about something that won’t resolve the dilemma. Okay, so if users build packages with an AUR helper and then don’t install them, you have a point. Why should an AUR helper be in the official repos if it’s used to build packages that aren’t subsequently installed as root? It goes without saying that you shouldn’t download, unpack, or build anything with root privileges.
On Sat, 25 Apr 2026 at 09:01, Ralf Mardorf <ralf-mardorf@riseup.net> wrote:
On Sat, 2026-04-25 at 09:51 +0200, Óscar García Amor wrote:
El sáb, 25-04-2026 a las 09:32 +0200, Ralf Mardorf escribió:
[..] using an AUR helper as root [..]
As far as I know, you can't do that.
So we find ourselves in a dilemma, and we could start a discussion about something that won’t resolve the dilemma.
Okay, so if users build packages with an AUR helper and then don’t install them, you have a point.
Why should an AUR helper be in the official repos if it’s used to build packages that aren’t subsequently installed as root? It goes without saying that you shouldn’t download, unpack, or build anything with root privileges.
You build them as normal user, but sudo install them when they're ready
On Sat, 25 Apr 2026 at 08:17, Óscar García Amor <ogarcia@moire.org> wrote:
El sáb, 25-04-2026 a las 09:04 +0200, Ralf Mardorf escribió:
Pip and Friends, as well as Flatpaks and Snaps, are a whole different story, if you start mixing that up with a distro’s native package management, you might as well just light a can of gasoline on fire.
Pip, when run as root, can cause far more damage than simply installing packages from the AUR.
I'm not sure the danger and damage from one over the other can be quantified that way and it may distract from the actual issue which I understand to be distribution endorsement of AUR
From my point of view as a user, I was perfectly happy with the default installation documentation to get up and running with Arch. After I found my feet and wanted things not in the core/extra I looked and found AUR with all appropriate warnings and decided to go ahead with it, and in the process learn much more. Not saying that my experience should be the template, but there's undoubtedly a benefit in keeping AUR installation helpers seperate, and the benefits for including it seem very minor, just confort.
El sáb, 25-04-2026 a las 09:04 +0100, Andy Pieters escribió:
just confort
Exactly, that's what it boils down to. Tools that make your life easier or more convenient. Why is archinstall used? To make installation easier. Why are AUR helpers used? For convenience. Greetings. -- Óscar García Amor | ogarcia at moire.org | http://ogarcia.me
On Sat, 2026-04-25 at 10:19 +0200, Óscar García Amor wrote:
El sáb, 25-04-2026 a las 09:04 +0100, Andy Pieters escribió:
just confort
Exactly, that's what it boils down to. Tools that make your life easier or more convenient.
Why is archinstall used? To make installation easier. Why are AUR helpers used? For convenience.
I have nothing against AUR helpers in "extra". I’m simply pointing out that they differ from other packages. Users should use the installer to set up a minimal and, as far as possible, secure Arch Linux system. After that, users can set their own priorities. The original thread is about "optional" AUR helpers in the installer. I think that’s wrong. I myself have used new hardware that required a kernel patch just to be able to connect to the Internet at all. That particular extension was available via the AUR. But that’s a step further. You shouldn’t make everything user-friendly if the policy is user-centric, for the good and for the bad. Different distributions cater to different user needs. I firmly believe one should not try to force incompatible things together.
El sáb, 25-04-2026 a las 10:45 +0200, Ralf Mardorf escribió:
The original thread is about "optional" AUR helpers in the installer. I think that’s wrong. I myself have used new hardware that required a kernel patch just to be able to connect to the Internet at all. That particular extension was available via the AUR. But that’s a step further. You shouldn’t make everything user-friendly if the policy is user-centric, for the good and for the bad.
Generally speaking, I agree with you wholeheartedly, but I’m not opposed to having an AUR helper available during installation precisely for the reason you mentioned. I think it’s about giving users options and then letting each person act accordingly. If the installer has a separate AUR section with a red banner at the top stating that it’s unsupported, it could break everything, and you’d be acting at your own risk, since the user has already been warned, and from there, it’s every man for himself. Just so you know, this is just my personal opinion. Greetings. -- Óscar García Amor | ogarcia at moire.org | http://ogarcia.me
looking at the discussion: Andy Pieters <arch-general@andypieters.me.uk> wrote:
I've always considered AUR as non official, user submitted, non vetted
Having an AUR helper inside core or extra flies against that and may imply an endorsement
i see this (avoiding an appearance of endorsement, "nothing to worry about") as a good reason not to put an AUR helper in core/extra. Łukasz Michalski <lm@zork.pl> wrote:
The main advantage of AUR helper is dependency management - if I want to install package X, helper will install all dependencies from AUR and from official repos. Doing it by hand with makepkg is cumbersome.
on the other hand, it is dealing with dependencies that moves me to use an aur helper (aurutils in my case). cheers, Greg
On Fri, Apr 24, 2026 at 09:15:31PM +1000, SK wrote:
On Fri, Apr 24, 2026 at 06:54:01PM +0900, evansjahja13@gmail.com wrote:
Imagine if there were a "very-helpful" AUR helper that promises auto update, zero user interaction, completely shielding users from the build process.
Vetting known-good helpers would prevent those helpers from getting main stream, while funneling users to understand the build system.
This is not possible. Shielding the user from the build process is exactly what we do not want to do, and what a good helper (like yay) does. There is nothing lacking in the current helpers, functionality wise, but its goals contradict with the Arch developers' pedagogical goals.
Sorry, there's a misunderstanding here so let me rephrase. New users must understand that AUR is community-maintained, they are not maintained by Arch Linux team. Using AUR helpers might make these processes easy, and (depending on the helper) people may not see the PKGBUILD, or even made aware what they are, how harmful they could be. Imagine there's this hypothetical "very-helpful" AUR helper that shields users from build process. This is exactly what we DO NOT want to do. 100% agree with this. What I am saying is that this AUR helper _could_ exist. Now let's consider the user journey. Someone who doesn't know much about these nuance hearing from someone that they can get rich quickly by installing "evil-package". The package is present on AUR, and the user also heard that they should use AUR helpers to make their lives easier. The option is either using something like "yay" which is hard to use, lives on the CLI... or they could use "very-helpful" AUR helper that even has GUI, click to install, auto updating, even AI integration!. The user then click on "evil-package" and loses bitcoin. Very sad. What I am saying is, From a user perspective, there's not much incentive of using our trusted AUR helper, vs using some shoddy automated "very-helpful" AUR helper. These users barely know `pacman`, otherwise they won't be needing archinstall script. So my argument on having trusted AUR helpers on official repo is that there will be incentive of keeping people away from these "very-helpful" AUR helpers that bring more harm than good. There can be policies such as the amount of warnings for first-time users on interacting with AUR packages. So my stance here is: Yes, people should read PKGBUILD. Because of that, let's make sure they use AUR helpers that make it obvious to read the PKGBUILDs. ... I bet majority of the newcomers only use `makepkg` once to install AUR helpers
On Fri, Apr 24, 2026 at 08:53:42PM +0900, evansjahja13@gmail.com wrote:
There's a misunderstanding here so let me rephrase.
Sorry, yes you're absolutely right. I should read more before I start writing. Unrelated, but do you recieve one copy of this email or two? My email client is showing two but I think it may be a client side issue. Sam
On Fri, 2026-04-24 at 21:15 +1000, SK wrote:
its goals contradict with the Arch developers' pedagogical goals
"didactical" vs "pedagogical" ^^^^ child, boy or girl further education vs parenting This makes a big difference. So far, however, I haven’t found anything in the Arch policy about an educational mandate. Or let's put it this way: at least so far, I've interpreted it differently. "Whereas many GNU/Linux distributions attempt to be more user-friendly, Arch Linux has always been, and shall always remain user-centric: The distribution is intended to fill the needs of those contributing to it, rather than trying to appeal to as many users as possible. It is targeted at the proficient GNU/Linux user, or anyone with a do-it- yourself attitude who is willing to read the documentation, and solve their own problems." I do think an AUR helper in the official repos is unnecessary, but I find it ridiculous to refuse to include it there for educational reasons.
My understanding is that the AUR is third-party to Arch Linux in general though? So then I would agree it should be kept separate as you don't need the AUR to run Arch... On 24/04/2026 07:38, Óscar García Amor wrote:
Please forgive me for playing devil's advocate here, but I see that many of you are strongly opposed to adding an AUR helper to archinstall because “AUR packages shouldn't be in official repositories,” and yet we have aurpublish [1] in the extra repository.
In my opinion, having some AUR helpers maintained as extra packages (such as paru or yay, which are the most widely used) is just like any other package maintained in the extra repository, and having them there would certainly make life easier for many users, since they wouldn’t face the chicken-and-egg problem when they start using AUR.
I think a simple notice stating that this is no longer supported and that you use it at your own risk is sufficient. Ultimately, it’s about making life easier for the user.
Greetings.
participants (15)
-
Andy Pieters
-
Ben Lavender
-
David C Rankin
-
Edmund Lodewijks
-
evansjahja13＠gmail.com
-
Greg Minshall
-
kleines Filmröllchen
-
Linus Probert
-
Pulkit Krishna
-
Ralf Mardorf
-
René 'Necoro' Neumann
-
SK
-
Uwe Sauter
-
Óscar García Amor
-
Łukasz Michalski