The popularity of EOS is unbroken, I always wondered why. Then I realized that simply because it’s easy to install, it just works, and there’s a great community behind it. He achieved all this in two years, which in itself is a great achievement. Whatever question that seems obvious to anyone here in the community, you can always count on an answer.
My answer is: because it’s a good distro. It’s Arch Linux that is easy install and get working, and has a noob-friendly community where anyone can get help.
So, I pretty much agree with the review. I disagree with the details, like using Pamac to install stuff, and GNOME looking nice, lol
Top notch distro with friendly community, not bloated, and i agree with @Kresimir, pamac is useless on EOS, imho yay and pacman are just excellent.
And personal thing i really much appreciate and rarely happening on other distros is that (i intentionally disabled VM and Software Guard Extension in Bios), so i am a happy “EMPTY JOURNALCTL”
I agree with that, it is currently not possible to upgrade the pamac due to a package conflict. I also mostly use pacman or yay.
PS: I searched for the word Pamac in the two reviews, but there were no hits.
Did you mean pacman
Not sure if this solution might help you out.
You’re right, writer’s speech, because I really meant pacman, but I wrote pamac. I corrected.
Because it is the easiest and cleanest way to install Arch.
I think its more the forum is mainly friendly, As their are many easy ways to install Arch Linux including the Arch way if you can be bothered to read lol.
I would add that using EOS is also the best way to get acquainted with Arch Linux without having to install clean Arch from the command line. I think nowadays not only the average user but also the pros are choosing this method of installation as convenience and speed are paramount. Just think that it is no longer customary to compile a kernel today, just install a ready-made kernel. The installed EOS, on the other hand, has all the features of Arch.
I think the forum and community are much friendlier than most known Linux distributions. And Arch way becomes much friendlier to novice and intermediate users alike in their interpretation of the EOS, and they learn to use the command line unnoticed without making a conscious effort to do so.
One question though. I see this often but don’t understand it. why use pacman AND yay? i mean what purpose does pacman serve you if you use yay? yay already has all the flags pacman has, working like an alias basically. Am I missing something?
No, I don’t think you’re missing anything significant. There’s really no reason, yay
does pretty much everything pacman
does.
Maybe if you only wanted to update the repo packages, but not foreign packages from the AUR, you could run pacman -Syu
. But why would you want to do so, is unclear.
Pacman of course because of ILoveCandy
…
There are many occasions (for me) when this is the preferred outcome - many of the AUR things take significant time/resources even to update… whereas an ‘average’ (if there is such a thing) main repo update can be done in under a minute (if no kernel).
That’s my excuse, and I’m sticking to it! Mainly I just like to do separate things separately, I suspect - not to mention that I like to select which AUR items get updated, and which skipped - I am not sure I have that choice with saving max typing with just a yay.
I guess so. But beware: when you update dependencies of the AUR packages, this can break them. That’s basically a partial update scenario, but assuming you are not using the AUR for any vital package (like graphics drivers), it shouldn’t be too big of an issue.
Yay does the ILoveCandy
thing too.
Does doing the update with yay mitigate the risk of ‘partial update’ of AUR dependencies? Does it even check? I doubt that any of mine have much in the way of dependencies that didn’t come with them, but it IS possible…
AUR stuff
┌13:20:24 WD= [~]
└───freebird@nest ─▶$ pacman -Qm
audacious-gtk3 4.1-1
audacious-plugins-gtk3 4.1-2
brave-bin 1:1.31.88-1
breeze-amber-cursor-theme 1.0-3
brother-dcp7060d 2.0.4-2
ckb-next-git 1:0.4.4.r102.gdc04037a-1
conky-cairo 1.12.1-1
conkywx 210321-1
dnslookup-bin 1.5.0-1
font-manager-git 0.7.7.r31.g7feded7-1
gdu 5.9.0-1
kvantum-theme-arc 20180614-3
libaudclient 3.4.90-1
libopenaptx 0.2.0-1
libxfce4ui-nocsd 4.16.0-1
mintstick 1.4.6-1
openrgb-git r1788.9f18edf9-1
python-pyparted 3.11.7-1
rainlendar-beta 1:2.14.3.b161-1
ruby-mdless 1.0.14-1
screenkey-git 1.1.r10.g9312e68-1
ttf-mac-fonts 20100901.134-1
xfce4-panel-profiles 1.0.13-1
Usually, the AUR package maintainer updates the build files to use new dependencies. So when you update your system with pacman, you don’t get the new version of the AUR packages, so they may break. But when you do it with yay, you update both the repo packages and the AUR packages, so everything works.
Of course, if the maintainer of the AUR package is slow, then it’s the same thing, you update your system, some AUR packages are not yet updated to new dependencies and so some of them break.
I must add that yay performs the update in stages. First it updates the packages in the system repositories. Then it does an AUR update. At which point you can reject the update of those AUR packages altogether, or specify which to exclude.
Of course, that’s essential for yay
's functionality. It would be very difficult to rebuild an updated AUR package if your repo packages (which contain dependencies and build dependencies) were not updated first.
And yes, while you can reject updates, typically you should not do so. If you do not intend to update, just don’t run updates. If you just want to see what updates are available, use checkupdates
and yay -Qua
. The best update strategy is “all or nothing”. This is not a big issue with AUR packages (those that are not updated can break, of course), but with the repo packages, rejecting updates after synchronising the local package database is a bad idea, because then you are in a situation where installing any new package before updating can cause a partial update and sometimes even make your OS unbootable.
Of course, there are many exceptions to all of this. Sometimes you may need to keep an older version of the package.