Advantages of PARU over YAY

Hi, as the title says, Is using PARU better than using YAY

what are your opinions on PARU?

Good read on different aur helpers
https://wiki.archlinux.org/title/AUR_helpers

EDIT: Maybe we don’t need a new thread for every question? just saying …

4 Likes
3 Likes

image

4 Likes

They are both functional pacman wrappers/AUR helpers.

I think the biggest advantage of paru over yay is that it is written in Rust, whereas yay is written in Go. This doesn’t make much of a difference for the end user though, but Rust is a really nice language, while Go is garbage.

The biggest advantage of yay is that it is quicker to type, especially on a QWERTZ keyboard where Y and A are adjacent. I just mash both keys with my fat finger to type yay :rofl:

Yay is also an older program, so it had more time for quality control.


EDIT: despite all the rumours and fear-mongering about yay being abandoned, none of that is true: yay is still actively maintained and developed.

8 Likes

Also, yay places built pacakges in /var/cache/pacman/pkg/, whereas paru does not. To the best of my knowledge, these only reside in ~/.cache/paru/clone/$pkgname/ for paru.

Not really an advantage or disadvantage of either. Just a difference to be aware of.

2 Likes

Isnt that handled by makepkg? In /etc/makepkg.conf you can set any destination for the packages you build:

PKGDEST=/var/cache/pacman/pkg/

1 Like

I’m not sure. I have never manually set it before. This just seems to be what happens if I change nothing else. Currently, the packages I install via paru don’t end up archived in /var/cache/pacman/pkg/.

I like it. It is my default package manager for anything I do with packages.

Functionally there is not much difference to yay. But paru is noticeably faster if that makes a difference for you.

2 Likes

The packages are build by makepkg. makepkg by default puts the packages into the build directory. This is ~/.cache/paru/clone/$pkgname/ for paru by default. You can change that with option BuildDir in /etc/paru.conf

It looks like yay is copying the packages from the build directory to /var/cache/pacman/pkg/. From my point of view it should not do that because by doing so yay is overruling the PKGDEST setting in /etc/makepkg.conf.

4 Likes

all sounds plausible. Should one, if one is willing, install paru with yay and then later switch entirely to paru and uninstall yay? Or is there a chance in the foreseeable future that EOS will be shipped with paru right away, so that you can save yourself the detour via yay?

You do not need to switch to paru. Just stay with yay. yay is still good. Nothing to do for the EndeavourOS team.

4 Likes

OK, thx :slight_smile:

There is nothing wrong with paru. But the most important features(for me) in yay were removed in paru so I definitely prefer yay.

2 Likes

What is it?

There are a couple but the most important one and the only one popping into my mind this soon after waking up is --combinedupgrade which provides a color coded output that shows you exactly what versions is being upgraded in both the repos and AUR. It lets me see at a glace what I am dealing with, what might need a rebuild and if I might want to hold off on an update.

Here is tiny snippet of what I am referring to:
image

2 Likes

In paru this is accomplished with an extra option --upgrademenu

I just asked that question on github and got an immediate reply. I didnt know about this output feature. Not in yay and not in paru. But I like it.

3 Likes

Funny I do that BEFORE running either of them - see the bash functions thread for upls - an on demand formatted listing of repo and AUR pkgs awaiting update. (It is)/(they are) pretty though!

Nice, I guess he added that. It wasn’t there originally.

Is there a way to see diff’s with paru? The only thing I see is the ability to review the whole PKGBUILD or none of it.

I keep forgetting to add yaya as an alias for yay :slight_smile:

3 Likes