Cleaning an Arch Linux installation
blog.andreascarpino.it
blog.andreascarpino.it
However, once set up, you can slap unattended-upgrades on top and have a (usually…) self-updating and self-maintaining system, which is quite neat.
Probably the way to go is Nix/Guix. Transactional upgrades and declarative configuration.
debfoster explicitly asks you which packages you want to keep and removes everything else. You can use it to strip down an existing Debian installation to just the base packages.
(Nevertheless, its also prompted me to put "try Arch out" on the TODO list for the next down-time period..)
The beauty of Debian is that unattended-upgrades works well enough that most of the time you can defer updates (within one release) to it and don't have to bother at all.
My only gripe is that if it breaks, it breaks hard. Botched Arch installations are much easier to fix.
Debian is one of the distros I use for long term installations because it is the only distro that gets release upgrades right, it is no problem using the same installation for several years and jump across several releases. Of course you should read the release notes, but what you are saying is the opposite of my real life experience. Of course it is also very easy to just reinstall.
Writing "every dist-upgrade blows something up" is an indication that you must be doing something very wrong with that computer in front of you. Please provide some bug reports.
I find Debian and Ubuntu to be also problematic for dist-upgrades and have been using my main work computer for 3.5 years with the same install. It is not unique to Arch to keep a system clean. Zypper in SUSE is also very capable of keeping things clean by just doing a zypper dup to go back to vanilla install again. If you read the forums of SUSE and the forums of Debian you will see a historical issue with Debian which I heard has gotten MUCH better.
No, it's not. The parent is reporting a personal experience. Just like you.
Back in 2009 when I switched to Arch, one of the reasons why I switched was because dist-upgrade frequently blew up on me and I didn't know how to fix it.
Maybe it was user error. Maybe I didn't know what I was doing. Maybe Arch just empowered me to understand my system better. I don't really know what the reason is, but nevertheless, the experience isn't bullshit. It really happens.
Applications already have their own learning curve, custom packaging only adds to this. Just reading the documentation or googling for answers may not be enough, one also needs to understand how and why packagers have changed things to be different from upstream.
Personally, I prefer the Arch way of keeping package customization to the bare minimum. Combined with the very simple package format and powerful tools, Arch is a winner.
Why would you run dist-upgrade frequently?
Its hard to diagnose a bug report like that, BUT, one reason to run dist-upgrade frequently would be if you're tracking unstable or testing especially during the early times of a dev cycle. Don't do that. Run unstable or testing I mean. Its a "let you shoot yourself in your foot if you insist on doing it" type thing. Unstable will tend to be unstable...
You should have to run dist-upgrade exactly one day per release cycle if you run stable. You may have to run it twice for certain historical upgrades lost in the mists of time, so I can't say it never happens and always only run it once per release cycle.
(This my memory from 6-7 years ago. For all I know, it could have failed twice because I did something stupid, didn't know it, and moved on.)
My central point is calling someone's else's experience bullshit, is, well, bullshit. My comment has little to do with anything else.
That said obviously it works most of the time. Otherwise noone would use it. Myself included.
Back this up with examples, please. I use Debian since potato and can't remember dist-upgrade failing me once.
• Apache was installed, but stopped for the upgrade (resource-constrained device, I figured I'd better free up the memory up front).
• Apache's preinstall script tried to stop it anyway
• The old init script returned exit code 1 when trying to stop an already stopped service (PID not found, well duh)
• …and the preinstall script used set -e
• …and was called in the middle of a full dist-upgrade, that among other things installed binary-incompatible library upgrades, so after apt bailed out, it wouldn't start any more.
In the end I just wiped the machine. Haven't seen it happening since, but apt/dpkg is way, way more anal than pacman when it detects problems, which usually gets in the way of fixing them (ex.: package didn't list a dependency it needs in its pre-/post-install-script → dpkg gets in an endless loop where it tries to re-execute said script and dies before it gets to installing the dependency).
The dist-upgrade included an upgrade of the mit-krb5 RPMs. One of those RPMs had a %postinstall that ran a sed command on the krb5.conf, to try to change a setting.
The sed command, run on the krb5.conf I had in place, blew away half the file.
That krb5.conf was necessary for users to log in; after the dist-upgrade, neither SSH nor local logins worked properly because the pam module bailed out entirely.
That's why I have Arch on my laptop now.
I've always found Arch to be among the easiest
distros to keep tidy. There's people that have
been running the same install for many years.
Archlinux, as a rolling distribution, does not have new release versions. Packages upgrade continuously-- as long as you pacman -Syu somewhat frequently, you avoid skipping package versions, reducing general breakage. Of course, most frequent maintenance is the cost you pay for a smoothly running archlinux system, but it's nice not to worry about reinstalling while still having the shiniest new packages.
I've used archlinux on my personal laptop for roughly 4 years now, and I've only reinstalled once when I upgrade to an ssd about two years ago. Prior to that, I used to install the latest fedora every 6 months.
AFAIK new versions of glibc, other major libraries, systemd, Linux kernels, etc. are always kept in one of these testing repositories for a while to catch serious problems.
To help make Arch better, consider running one or more systems on [testing] (a chroot or VM will do) and reporting any problems you find.
Then one summer I installed gentoo. I used it for about a year. If something broke, I made sure to understand why, and to not just fix it. I learned more in that year than I had in the first 4 combined.
Now I use debian and arch linux, it's not worth the hassle of running a gentoo system. But oddly, nothing seems to break anymore. I don't feel like I'm doing anything differently.
That leads me to the conclusion that not breaking installations is more about uncovering the unknown unknowns of your understanding of your system than anything.
Just my $0.02.
It's a bigger business and thus the stakes to keep it running reliably are higher.
comm -23 <(pacman -Qqe | sort -u) <(pacman -Qqet | sort -u)
comm -23 <(comm -23 <(pacman -Qqe | sort -u) <(pacman -Qqet | sort -u)) <(pacman -Qqg base-devel base | sort -u)
pacman -D --asdep packagename
pactree -r packagename
Please consider adding them to the Arch Wiki (if they're not already on it).
emacs /var/lib/portage/world
Then simply:
emerge -uNDa world && emerge -a --depclean
Though if you are serious about system maintenance, whenever you emerge a package you don't want in your world file (e.g you may want to re-compile a dependency) you should use the '-1' flag of emerge:
emerge -1a dependency
I've always wanted to try it. But since I'm working full time I don't get around to start an installation with manual FS setup and networking, both topics which I mostly know a few little basics about. Altogether Arch looks much nicer, and I agree that you should have as much control of your system as possible. But I think the approach should be that you can choose to learn only little chunks here and there until you have most of the ideas in your head and fingers, then setup everything as you desire. That's why I'm still stuck on Ubuntu.
It doesn't hide anything and there's little magic. It's all about getting your components well chosen.
Arch might work well with Gnome, but I think it really shines using a minimal setup with no desktop environment.
That's what I would expect when I get started scripting the setup myself. If I don't do it then using a sensible, community decided default would be better than doing something without investigating. Would you agree?
My familiarity with grub and the UEFI boot-process was really limited. The beginner's guide and the rest of the Arch wiki are extremely useful, and I was able to get everything set up, but it did take several hours.
Then, a couple of weeks later, my system broke with a kernel update. I hadn't properly set up my fstab to point /boot to the correct partition, so I had a separate /boot directory in the same partition as my root system... stupid on my part.
It was a bit of a pain to fix, because I couldn't boot into the system. I ended up using the USB installer that I had setup Arch with. Now things seem to be running fine again (except that recently "suspend" and "hibernate" randomly disappeared from the shutdown options in my Cinnamon DE... weird).
But yeah, Arch forces you to learn the things that you can just overlook on something like Ubuntu. I takes time, but at least you learn how to fix them when they break. I've shot myself in the foot a few times, but it's been with a BB gun instead of a shotgun.
I recommend the XFCE flavour as, imho, KDE Plasma 5 isn't ready.
feh WARNING: 01.mp3 - No Imlib2 loader for that file format
Its ports are where FreeBSD really shines. They're something in between Arch's ABS and Gentoo's portage. I just wish there was someway to say "install binutils via pkg, and only compile gcc itself".
You can also `make package` to, well, make your own binary package (it will be in /usr/ports/lang/gcc/work/pkg) to distribute to other machines. Or use poudriere to setup a proper package build server.
Why do things manually have to be marked as dependencies? Is that because they were manually installed at one point, or does Arch's package manager not properly track dependencies?
In the case of cleaning your system, it is interesting to mark an unused package as a dependency; the resolver (see https://www.archlinux.org/pacman/pacman.8.html#_remove_optio...) will see that it's installed as a dependency, but no package depends on it. It's a quick way to "tag" them as unused so they can be "garbage collected" at a later time.