
Cleaning an Arch Linux installation - ilpianista
http://blog.andreascarpino.it/cleaning-an-arch-linux-installation/
======
nextos
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.

~~~
WalterGR

        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. 
    

Is this uncommon for desktop Linux?

~~~
oldpond
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.

~~~
ackalker
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.

~~~
oldpond
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.

------
nly
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.

    
    
        comm -23 <(pacman -Qqe | sort -u) <(pacman -Qqet | sort -u)
    

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)

    
    
        comm -23 <(comm -23 <(pacman -Qqe | sort -u) <(pacman -Qqet | sort -u)) <(pacman -Qqg base-devel base | sort -u)
    

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.

~~~
ackalker
Those are some very useful oneliners, thanks! :)

Please consider adding them to the Arch Wiki (if they're not already on it).

------
andmarios
In Gentoo it would be:

    
    
        emacs /var/lib/portage/world
    

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.

------
erikb
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.

~~~
nextos
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.

~~~
erikb
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?

~~~
BFay
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.

------
vamur
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.

~~~
RexRollman
There's always been little things like that. For example, installing Feh pulls
in libid3tag (which for whatever reason is a dependency of imlib2).

~~~
leni536
Maybe for opening album art? Feh complains if I want to open an mp3 with
embedded album art though:

    
    
       feh WARNING: 01.mp3 - No Imlib2 loader for that file format
    

And imlib2 does depend on libid3tag.

~~~
RexRollman
I know but it's a weird dependency to me. One would think that an ID3 editor
would need that, not the image processing utililty itself.

------
zatkin
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.

------
dr4g0n
I was really thrown by the ligatures in some of the command snippets (diﬀ and
lostﬁles).

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?

~~~
rakoo
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...](https://www.archlinux.org/pacman/pacman.8.html#_remove_options_a_id_ro_a))
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.

