21
Arch Linux limitations?
(programming.dev)
A community for everything relating to the GNU/Linux operating system (except the memes!)
Also, check out:
Original icon base courtesy of lewing@isc.tamu.edu and The GIMP
This is a really good way of saying it!
I'll give concrete examples. With Arch:
pacman -Sy <package>
is bad). So if you want to upgrade to Inkscape to a new version, you may find yourself having to install a new kernel which might force a reboot./etc
, and then keep track; and if you do want to upgrade a pinned package it's a bit of a PITA. You can easily get yourself into a bad state by pinning packages, and it's easy to forget about pinned packages./etc
) management is primitive. It just dumps new versions of config files in the filesystem, and it's up to you to notice, find, and merge them. There are third party tools to help, but they're basically dev-level diff/merge tools. You have to realize this is going on, go find a tool, install it; and because of the previous points, it means if you want to upgrade Inkscape, you may find yourself being forced to merge a grub config.pacman
. You may be lucky, but it you aren't and it bites you, you'll be told by the Arch community it's your own dammed fault for not checking news first.Despite all of these terrible, fixable aspects of Arch, I run it everywhere. Why? Because, unlike Debian, I don't have to wait two years to get package updates, because the Arch package repository is simply vast and comprehensive, and because if you get in the habit of navigating the Arch maintenance minefield, it is the least breaky of distros, and the easiest to fix if it does get broken. I've had Debian installs get so fucked up, the package db so broken, that the only fix is to re-install. I've had Arch get borked, but never to an unrecoverable state.