Except it automates the steps you’d have to take to inspect and edit the script, if needed. Also, PKGBUILDs are much nicer to read than just plain install scripts. And, of course, it actually builds a package, which is then installed, so it’s not only tracked but can be updated like the rest of the system.
I’d say that yay encourages checking the PKGBUILD or its diff more than the average “curl xy | sudo sh” instruction, but considering most people see yay just as yet another package manager, instead of an AUR helper, that’s probably true for most people
That’s why it’s one step above. The user is given an option to read the PKGBUILD (or a diff with the cached copy if it exists), but beyond that, it’s still unverified arbitrary code from an external source (the project’s actual source, binaries, or packages from another repository). Packages in the official Arch repos are verified by the downstream packagers. For AUR packages, it’s up to the community to moderate itself, and the user to determine whether the package is trustworthy, and I’m willing to bet that not many people do it. I certainly don’t vet everything I install.
That’s probably the “just one step above” part. You do have the option to inspect the script you’re executing before you do so with curl | sh too, if you know what you’re doing. If you don’t, then you’d be pretty likely to just skip the prompt from yay as well. (Automatic diffs are nice tho.) Note: I use paru instead so I don’t know what yay does.
yay <package name>
There is a 99% chance it’s in there, and there is an 80% chance it uses the latest version/git HEAD
Yay?
yay, a utility to access the AUR, where users share build scripts instead of binaries. It’s just one step abovecurl | sudo shin terms of security.Except it automates the steps you’d have to take to inspect and edit the script, if needed. Also, PKGBUILDs are much nicer to read than just plain install scripts. And, of course, it actually builds a package, which is then installed, so it’s not only tracked but can be updated like the rest of the system.
To be fair, that’s why they said
I’d say that yay encourages checking the PKGBUILD or its diff more than the average “curl xy | sudo sh” instruction, but considering most people see yay just as yet another package manager, instead of an AUR helper, that’s probably true for most people
That’s why it’s one step above. The user is given an option to read the PKGBUILD (or a diff with the cached copy if it exists), but beyond that, it’s still unverified arbitrary code from an external source (the project’s actual source, binaries, or packages from another repository). Packages in the official Arch repos are verified by the downstream packagers. For AUR packages, it’s up to the community to moderate itself, and the user to determine whether the package is trustworthy, and I’m willing to bet that not many people do it. I certainly don’t vet everything I install.
That’s probably the “just one step above” part. You do have the option to inspect the script you’re executing before you do so with
curl | shtoo, if you know what you’re doing. If you don’t, then you’d be pretty likely to just skip the prompt fromyayas well. (Automatic diffs are nice tho.) Note: I useparuinstead so I don’t know whatyaydoes.I don’t think the aur can switch the delivered script whether you are piping it into sh or not.