Switching to… Arch Linux!


Alright, now it’s official: Project E.e.r.i.e. abandons Gentoo and switches to Arch!

Moving away from Gentoo

The biggest downside of Gentoo ist surely that you compile everything from source and it takes way to long to set up bigger programs like a desktop. Half a day for re-compiling your system with a new USE variable and emerging GNOME 3 is not at all an exaggeration. Even on modern multicore processors like the i7 of the system I run my tests on. Every Gentoo user knows the phenomena of “overnight-emerge” – meaning that you begin emerging before going to bed and have the computer work all night. Dependent on how long you sleep and on how big the program(s) you are merging is/are, it may be done when you wake up…

Also the problems I had with the portage tree lately were rather annoying and a pure waste of time. I’m about one month behind with the tests I wanted to publish here.

But of course there are quite a few strong points of Gentoo – I still like this distribution and thus don’t want to leave that unmentioned. Thanks to the USE variable and the complexity of the portage system, Gentoo’s flexibility is simply unique. There’s nothing that comes even close to it. Oh you don’t want the default version of your package? No problem! Just unmask a newer one and hope it works well, if you feel like it. Or mask the default one and portage will simply provide you with an older version! I got used to think this goes without saying, but of course this is not necessarily the case with other distributions – like Arch. Actually it is one of the things that will be painfully missed.

Arch Linux

Well, Arch Linux is a “simple, light-weight” distribution. Sounds nice, eh? Sure it does. You can have the default basic system with as little as about 650 MB of used space, which is pretty nice. Other than Gentoo, Arch uses binary packages by default. It does however provide a rather good buildsystem, too.

The repos are split into “core”, “extra” and “community”. And if something is not in there, there are additional custom repos, which you can add to your pacman.conf. Oh, and you can always have a look at the AUR, the Arch User Repository. It doesn’t provide binary packages, but there are thousands of PKGBUILD files there which contain the information on how to build a certain package (kind of similar to Gentoo’s ebuilds, but far less complicated). Thanks to the AUR there’s ton’s of programs available for Arch which are not in the official repos. However it is completely user-maintained so there are many PKGBUILDS which are outdated, buggy or even orphaned, no longer maintained by anybody. Still it’s a very nice thing to have!

First impression

Pheakuser suggested using Arch from the beginning. Well, it follows the rolling releases system, too, and when I first wanted to try it out (perhaps five to six weeks ago), just on that very day, it was broken due to a default driver switch. The new one was added as a dependency but the old one not yet removed – and so pacman wanted to install both of them. However they were conflicting packages… Fortunately Arch lets you select which packages from a group you actually want to install. So this problem is easily fixable from the users side. But it’s thinks like that which I really despise and what makes me think that fixed releases really are not such a bad thing…

Working with Arch

Anyway: I’m getting along with Arch pretty well already and did not encounter such a glitches again in the last few days. Just following the desktop tests I’m doing is probably giving you a good impression of what it’s like.

First I’ve installed GNOME 3 from the main repos. No problem at all. Next I’ve installed Cinnamon from the AUR. Working fine. Then I tried to install Unity. Well… Things got a lot more unpleasant here. The ArchWiki (a really great source of information) pointed me to the Ayatana custom Arch-repo. However this repo seems to be seriously broken. It provides a package for Unity (version 5.x) however lacks at least some of its dependencies! Alright looking for those in the AUR. Nope. Hm!

Allright… Let’s try out the Unity package from the AUR. Ok, it’s marked “outdated”, but let’s try it out, anyway. Needs dependencies. Ok, download the PKGBUILDs for those from the AUR, too. Some work, some don’t. Time to take a look at the PKGBUILD. Looks clear and easy to understand. Spend about two hours getting into the PKGBUILD system and trying to fix things. No luck.

Well! Removing all these directories, I decided writing my first own PKGBUILD. A few minutes later it downloads the Unity source (this time the new version 6.0.0) from launchpad. Ok, taking a look at its docs, there’s a lot of dependencies. A long story short, I spent the whole rest of the day writing PKGBULDs, building package after package. Only to browse the forums before going to bed tiredly – and to find out that there’s another Unity repo which has a working version 6… I have no idea why this is not in the wiki! But well, the many hours were not a complete waste of time since I learned quite a bit about Arch in that process.

Downsides of Arch

I found out that there are no -dev packages with Arch. All the headers and stuff is in the main package. I guess, this is where “simple” beats “light-weight”. If you ask me, it should be vice-versa. The average desktop user who wants a light-weight system and never compiles his own packages, simply does not need all that ballast of the -dev packages!

Also, like I wrote above, it’s not really easy to get an old package installed. Keeping an old one is no problem. You can easily forbid to update it in pacman.conf. But older packages are simply not kept on the repo mirrors! After finding the right repo, installing Unity was no problem. However I was experiencing severe graphic glitches. I read a little on the forums and understood that this was due to Unity not being compatible with glew1.8. Luckily there’s a PKGBUILD for glew1.7 on the AUR as there’s no possibility to simply install an older version from the main repos. This is the point where I miss my Gentoo! But well – you just can’t have the best of both worlds, I guess.

What’s next?

The next blog entry will finally start with the desktop tests! Comparison of the modern GTK+ desktops should be ready on sunday.

Rolling Release trouble

Sorry that it took me so long to write a new entry. And since this is obviously not the test that I promised in the last one: Sorry again.

As a less funny coincidence I had a lot of trouble with the Rolling Release model of Gentoo just after talking about it in the New Team Member! post.

Gentoo, Portage and Rolling Release

On several occasions in the past I had problems with my Gentoo – starting with my very first day where I set up a Gentoo test system. Something did not work at all and after trying to get it working myself for hours, I asked in a forum. In the end the problem was not my stupidity but something broken in the portage tree. I was advised to “wait about a day”, resync and “see if it works then”. This was actually the case so this strange experience did not make me abandon Gentoo right away. There were so many new things that fascinated me.

As I stated before, this was not the only time something like that happened. And so it has happened again during the time when I wanted to do my tests. When everything went well as I prepared the test about four weeks ago (I had a working GNOME 3 system and a KDE one), I was content with it and confident that everything would go well. Unfortunately the next week I was unable to emerge GNOME 3. Yes, I did it right the same way that had worked before on exactly the same virtual machine. I knew this already and so I decided to postpone things (it was a rather busy week and I only had one day at the weekend for my testing).

One week later, I had a new problem: This time I could not even emerge GNOME 2 (which is the base for GNOME 3 on Gentoo – you don’t install the latter directly but install it over GNOME 2)! I tried to mess with package.accept_keywords and force portage to give me a working version. However this was rather time-consuming and in the end I was forced to postpone everything again.

So what’s the status now?

I used this sunday to give it a try again. Since my VM was quite old now (and for the sake of comparability I did not want to update the base), I set up a new Gentoo VM. For a change I chose to build a genkernel this time, since I’ve always wanted to give it a try but never found the time to do so. Then I changed profile, USE variable and rebuilt my system. Next I emerged GNOME 2 – things were working again. After that: GNOME 3. Success! But when I wanted to start it, GNOME 3 reports an error and advises me to log out and try again. Which however does not help…

Scanning through Xorg.0.log, I saw that there were problems with virtualbox’ graphic drivers. For the rest of my time I tried to get things working: Setting the video card in /etc/make.conf, putting both the driver and the guest-additions in package.accept_keywords for the newest version, updating the system… Well, everything failed. It seems like I can’t get it to work soon.

What’s next?

[update 08/07:] When writing this entry, I had intended to skip the 3D-desktops and start with the other ones. But due to some more issues that have arisen in the meantime, I’m really fed up with it all. Always compiling everything simply takes ages. I wouldn’t mind that if things were working afterwards! But since that has not been the case a little bit too often now, I’m going to try out something different. It’s likely that I’ll be switching my test distribution.[/update]