is answered here
1 Like
I’ve been using paru for quite some time, cuz Rust. That said, yay is also very solid.
1 Like
I recommend pikaur. It’s actively maintained, and I have not seen anymore releases from paru and yay.
yay last saw a release in March of this year and there’s been plenty of activity on the github, not sure why you’d assume it was abandoned?
Why would they release updates just for the sake of it? “If it ain’t broke….”
8 Likes
I use both. Usually I try yay first cause it’s less letters. 
Recently there were some issues with cuda. Neither paru nor yay worked. Had to just ignore the cuda package. Still took nearly 40 mins for the update.
An app like a AUR helper will naturally, eventually, be feature complete and no longer require releases or active development, unless something fundamental regarding the process of installing AUR packages changes.
3 Likes
Since I have a fresh, clean install of EOS on my new mini-PC, I’m sticking with yay since it’s preinstalled and included in Welcome and such. Still a quick and snappy AUR helper.
My laptop, on the other had, is running Arch. So I never installed yay but opted to install paru. I like paru equally to yay. It seems a bit snappier to me as well.
2 Likes
I use both. . . . for redundancy. . . . . Both are excellent and equally work well.
Rich;)
2 Likes
I switched from paru to yay just to try it out again after not having used it for a long time. Since paru is broken since yesterday after pacman got updated and it’s still not fixed today. So that gives yay bonus points for me as in how fast they fix it when an update breaks it.
It would be a good option if, during system installation, you could choose whether to install yay or paru. I know, I know — it’s more work, but it would make a lot of sense. And as for the argument that this might be too confusing for new users: they probably won’t customize the installation packages anyway; they’ll just let the process run its course.
You can have my yogurt when you pry it from my hands, which might get messy.
1 Like
It would be very little work but the complexity is the real issue.
We are very conscious of adding more options since we get a lot of feedback that we already have too many. However, we have the ability to add a custom list of packages so you can technically add whatever packages you want to the installer.
3 Likes
Hi all, I was just reading through this thread and thought it would be interesting to try Paru.
This is probably an idiotic question with a really obvious answer but how can I change the order in which search results are shown?
For example, here I searched Firefox with paru firefox but I have to scroll back miles to see the top result…
It is an option in paru.conf
Here is mine:
[options]
CombinedUpgrade
UpgradeMenu
SudoLoop
BottomUp
1 Like
Aha, thanks Dalto, great stuff. 
1 Like
I have more than a half dozen different AUR helpers installed on my main computer. I can’t even remember all the ones I have installed, (and I’m currently on my phone).
Why? Because at times yay or paru will fail at building a specific package, but one of my other helper utilities will succeed. What do I care how many I have installed if I have the extra room, so the more the merrier in my book.
Kind of like keeping the LTS kernel installed as as a backup, just in case another kernel has a problem booting.
YMMV.
1 Like
I hear you and (though to lesser degree) I do the same.
However there are those folks that start jumping up and down and screaming ‘Bloat’ (I’ll never understand them)
If you were talking about having a half dozen full fledged graphical web browsers installed I would tend to agree that bloat would be an issue. However with small size terminal based programs who cares. The size they add is negligable.
It would be bloat if we installed them all by default. If an individual chooses to install things and then refers to it as “bloat”, I am not sure what to say about that.
5 Likes
The couple of times it happened to me, I used the basic git clone+makepkg, no need to test several helpers.
1 Like