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. On the other hand, whenever I try dist-upgrade in Debian et al. I always end up blowing up something.
apt-get autoremove only removes now unused packages that were previously installed automatically as a dependency.
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.
In my opinion, the only real effort that is required to keep Debian clean is to remember to do the updates regularly, and dist-upgrade semi-regularly. If you get far behind, then there are going to be headaches, but if you stay relatively current as you move along with new updates, and upgrades to packages, Debian is very smooth sailing. So smooth that I instantly thought to myself "huh, who needs spring-cleaning? My debian-systems pretty much keep themselves clean all along.." and was subsequently surprised about how Arch Linux seems to do things ..
(Nevertheless, its also prompted me to put "try Arch out" on the TODO list for the next down-time period..)
> In my opinion, the only real effort that is required to keep Debian clean is to remember to do the updates regularly, and dist-upgrade semi-regularly.
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.
Indeed. The installation on my laptop is now 4.5 years old and was on 3 different laptops and 2 different SSDs and yet there is absolutely no need to reinstall. I maintain my system every now and then and never exceeded 1000 installed packages.
If you have some time to spend on your system and the occasional hickups after/during updates then Arch is very easy to keep clean imo.
One of the biggest differences between Arch and Debian is that the configuration in Arch is left up to you. This dramatically simplifies the dependencies. In Debian you often run into circumstances where a very large number of people want related apps to be set up to communicate with each other. Even if you don't want the dependency you are kind of stuck with it because otherwise the configuration is broken. Then the dependencies bring in other popular dependencies and in the end you can get a bit of a mess.
This is BS. I am using debian since many years and apt-get dist-upgrade never blows up anything.
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 LOVE LOVE ARCH. I use OpenSUSE at work. It is 100% my choice and I always feel that Arch is great, in production I have to many little things that just need a few moments of attention.
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.
I believe an important reason why Arch is easier to maintain has to do with its minimal package customization:
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.
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.
Never blows up on anything? I guess the times I tried and failed to dist-upgrade my laptop were just a bad dream... Nothing never blows up. I've had pretty serious issues doing dist upgrades and linux version updates where my hardware (drivers) no longer worked without warning.
That said obviously it works most of the time. Otherwise noone would use it. Myself included.
Did you add non-standard repositories? In my experience dist-upgrade is absolutely fine, unless you installed updated version from alternate repositories. That can blow up in your face during dist-upgrade.
One example I vividly remember was Lenny → Squeeze.
• 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).
I'm an aptitude user, but I learned the hard way that you need to switch to apt-get to do a dist-upgrade. Something broke. Can't recall what it was - I think I was dist-upgrading to Squeeze, so it was a while back.
One time I had MIT Kerberos installed. The /etc/krb5.conf file had been edited.
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.
Many linux distros release a new version every 6-12 months, depending on the distro. While ubuntu offers 5 years of support on long-term support (lts) releases, desktop users tend to like the latest version and reinstall or upgrade every 6 months. A lot of the time, upgrading to a new release causes packages to skip forward by several versions. This often breaks packages with kernel dependencies, like graphics drivers, so it's common to advocate a fresh install every release. If you choose to remain on a lts release, you can easily run the same install for many years-- the price you pay is not necessarily having the latest shiny packages in return for a fairly stable system.
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.
Well, if you are on a rolling distro like Gentoo or Arch you are going to run into breakage eventually because you are out on the leading edge. The tools are evolving quite steadily, so it's the price you pay to run the latest and greatest. Package dependency management is the trickiest part of package management, especially the reverse dependencies.
Just for the record: Arch does have testing and staging repositories for testing new versions of packages that may cause major breakage if they have bugs or packaging problems.
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.
Yes, both Arch and Gentoo are rock solid IMHO, and I enjoyed many years in both those communities. Breakage was very rare, less than one per year even, and I always ran test releases for my desktops.
I've been using linux + gnu since I was about 14. I cargo-culted almost exclusively for the first 4 years of my using of linux. Things broke constantly. I would install a new distro just to try out a different DE, not realizing that the differences between kubuntu and ubuntu could be exchanged with a simple apt-get command. Everything I ran in a shell was copy pasted.
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.
Is it also possible that in the intervening year the distributions improved as well? I don't know what your timeline is looking like, but I've also just found linux is much less likely to break since I started using it (~1997) because it has better packaging, more reliable contribution for hardware drivers, improved init, etc.
It's a bigger business and thus the stakes to keep it running reliably are higher.
I was really thrown by the ligatures in some of the command snippets (diff and lostfiles).
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?
If a package really is installed as a dependency, it will be marked as such. If for some reason you manually install a package that is needed by another one, then it's a good thing to mark it as dependency.
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.
My Archlinux based LiveUSB setup comes around to 1GB and has Libreoffice, Wine, Firefox/Chromium. That said, there are some questionable dependencies in Archlinux lately. For example, mpv now requires smbclient, which then pulls python2.7.
Not really. I thought of installing gcc 5.1 through its binary package and it tried to install gcc-ecj 4.5 along with it. I ended up installing it through the ports system, disabling Java support.
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".
pkg install binutils && make -C/usr/ports/lang/gcc install clean :-)
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.
The dependencies are mainly insane upstream defaults, which Arch doesn't try to hide. For many packages there are modified PKGBUILDs available in the AUR for these situations (mplayer-nosmb, pidgin-mini, …). Sadly not for mpv (yet, I've been meaning for a while to make one, but didn't yet get around to it).
Here's a handy one. It lists packages that are both explicitly installed (and therefore won't be removed unless you remove them yourself), but are also needed by other packages.
And here's a more practical version that ignores the base and base-devel group (I don't know why package maintainers keep adding things in base like glibc as direct dependencies, but they do)
Unless you have a personal reason to explicitly keep these packages, they usually need to be marked as dependencies again so that, when you remove the things that depend on them with -Rs, they'll be removed as well.
pacman -D --asdep packagename
If you want to know what depends on each of these packages run
pactree -r packagename
Sorting this out should eliminate the need to ever resort to a -Rc (--cascade) removal, which is dangerous.
A little on the side: Is it possible nowadays to install an Archlinux that out of the box can do about as much as a fresh installed Ubuntu (Gnome, Firefox, a Terminal, Git, mostly)?
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.
I think it took me less than 2 hours to do a full install reading the wiki 5 years ago. Now, with systemd doing mostly everything it's a lot simpler. I think it can be scripted in 10 lines of code. I use Arch because I'm quite lazy and I find it straightforward.
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.
I bet you can script it. But for that first you need to know enough about it. That's where the trouble comes in getting started. E.g., a colleague suggested me to put "noatime" into my fstab. Now you might say that's about 5 seconds. But if you don't know what it is and you take responsibility for your system, then what you first do is read about it. So I spent about 10 hours reading and discussing about noatime and then decided not to put it into my fstab because I learned that the default is already "relatime" which is a little slower but much more compatible with some tools. Instead of 10 seconds I've spent 10 hours and in the end didn't change my config at all.
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?
I know what you mean - I installed arch a month or two ago, and the hardest thing for me was setting up the boot partition (I wanted to dual-boot the laptop with windows).
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.
The arch beginners' guide on the wiki will walk you through the installation process even if you don't know what you're doing. Still not as easy as Ubuntu, but should be feasible.
This file contains a list of all packages you emerged manually. Just remove anything that you don't want.
Then simply:
emerge -uNDa world && emerge -a --depclean
This will first update the system and then remove any package that isn't listed or is a dependency of [a package listed] in the world file.
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 also have my Gentoo 64bit installation since 2007 and have changed 4 or 5 machines since then. There are the occasional problems (as is the case with any distro) but if you are a bit interested in how things work instead of how things get fixed, you can solve them.
Nice read! Unfortunately, on mobile it's difficult to figure out what the options do individually. Too bad they're not easily predictable. It would be nice if they were written in long form and short form for people like me. I'll have to read through the man page later.
59 comments
[ 2.5 ms ] story [ 122 ms ] threadHowever, 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.
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.
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.
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.
Please consider adding them to the Arch Wiki (if they're not already on it).
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.
[0] http://antergos.com/
I recommend the XFCE flavour as, imho, KDE Plasma 5 isn't ready.
https://manjaro.github.io/
Then simply:
This will first update the system and then remove any package that isn't listed or is a dependency of [a package listed] in the world file.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:
I also have my Gentoo 64bit installation since 2007 and have changed 4 or 5 machines since then. There are the occasional problems (as is the case with any distro) but if you are a bit interested in how things work instead of how things get fixed, you can solve them.