Until today I was always updating my system with yay, or more specifically as part of an update alias as yay -Syu --answerupgrade none . When I get the system update notification (which I enabled for EOS) and click on it, then the system updates with a script specifically designed for EndeavourOS; it’s description even says it has additional features.
So, my question is, should I rather use eos-update in the terminal or use yay to update my system? Most of the time I do it manually in the terminal. What is the recommended way?
I did, it was the first thing I tried with which and vim, but cannot say with certainty if I prefer it at the moment. My question is, is there any reason why someone would prefer yay over eos-update? Why doesn’t everybody in example use that as the default update command?
As an example, I use pacman separately, and then MAYBE a yay-based AUR update, depending on such things as time available, what needs updating and how long til dinner and what the temperature is and the score of the game I’ve had on and…
I have an Arch-updates extension on my panel ( Gnome 45 - Arch Linux Updates Indicator ) That allows me to run my preferred command ( gnome-terminal -e 'sh -c “yay -Pw ; yay ; echo Done - Press enter to exit; read” ’ )… that’s my poison … you get to experiment & do it your way. You do you the way you want to. Experiment with all the ways to update & go with what FEELS best for you.
I have an alias to update bunch of stuff too (including cargo) and today replaced yay with eos-update with the yay helper flag and trying it out for now, if I notice any difference in real world usage. My command:
Since quite a while back, archlinux-keyring ships a systemd service for refreshing the pgp keys of the keyring regularly. The timer is set to run the service once a week by default:
$ systemctl status archlinux-keyring-wkd-sync.timer
● archlinux-keyring-wkd-sync.timer - Refresh existing PGP keys of archlinux-keyring regularly
Loaded: loaded (/usr/lib/systemd/system/archlinux-keyring-wkd-sync.timer; static)
Active: active (waiting) since Tue 2024-03-19 06:08:26 CET; 56min ago
Trigger: Sat 2024-03-23 11:55:56 CET; 4 days left
Triggers: ● archlinux-keyring-wkd-sync.service
Exactly this. I personally run the OS’s custom updater if one is provided then Topgrade right after that for everything that the OS’s updater doesn’t do. If the particular doesn’t have it’s own custom updater then it’s just Topgrade that I run. as for AUR helpers I avoid Paru and either use yay or Pikaur, and for individual package installs Pacseek is my go to.
May I ask why you avoid Paru? I hope my question does not start a war. Just curious because I never heard anyone talking bad about Paru. … unlike a helper from a specific cousin os …
In my opinion paru is alright, nothing wrong with it. It’s pretty much the same thing as yay except it’s not written in Go, but in Rust. The only thing I didn’t like about paru was advertising, where the author of paru, who was a former developer of yay, falsely claimed that yay was dead and will not be maintained by the remaining developer. This caused idiots to panic and switch from yay to paru. But that was a long, long time ago.
Since the Go programming language is made by Goolag, and there was some discussion about putting telemetry in the compiler – not in the compiled binary, mind you, but in the compiler itself – but even putting it in the compiled binary does not seem beyond Goolag. And since, if you’re building yay yourself, you need a Go compiler, I decided to either not build it myself and stick to the binary from the endeavouros repo, or just use paru.
That said, cargo, the package manager for Rust, is also very problematic, and could potentially download and install malware, so caution is advised.
Ah, I remember there was these talks about yay going away. I never understood what it was, as at that time I was using Pamac. I’m more of a Rust guy than Go, so naturally I would be towards Paru then. But to be honest, it does not matter if I don’t compile or edit source code or build settings.
But for fairness, if you criticize Rust for downloading packages from the internet (if you do not stick to a known version of the libraries), then you have to mention this for Go too. Go can download from arbitrary places, while Cargo does it from a central places.
Oh yes, Go is much worse, because it’s Goolag. So not only do you have to worry about third-party malware, but a real concern is also the official malware from Goolag themselves.
That said, cargo.io is absolutely infested with malware. Here is an article from 2021:
And what really, really bothers me is that most Rust programmers are morons when it comes to dependencies. There exist simple CLI tools written in Rust that have hundreds of dependencies! Why do you need that many “crates” to make a simple CLI tool? Thanks to cargo, Rust is the exact opposite of a safe language. Rust’s alleged safety is all advertising for idiots, including the US government.
But yes, I don’t want to be unfair to Rust by omitting other similar “programming language package managers”. By far, npm is the worst, everyone knows cases of malware from npm. PyPi is also not much better. Pretty much all these “dependency downloaders” are vulnerable to supply-chain attacks. You can distribute malware even with cmake.
I avoid it cause it doesn’t just list the differences, it list everything in the file to be reviewed. I like yay and pikaur can they only son the differences make it far faster to review.
That isn’t true. With both yay and paru, the first time you build an AUR package, they show you the entire file because they don’t have anything to diff against. But on subsequent times, they show the differences.
So if you switched to paru, the first time it will show you the whole file.
Here is an example of what I see in paru when updating.
But that was a long, long time ago.
advertising for idiots, including the US government. 