Gentoo — A FHS following FHS violator

•March 3, 2007 • Leave a Comment

Long time no blog, so I thought Id complain about something that Ive had issues with for some time. Gentoo really tries to be FHS compliant. It is fairly successful with that for the most part. One part of the spec that Gentoo, unfortunately, breaks is the location of the portage tree. To my (VERY limited) knowledge, the reason for continuing the broken tradition is exactly that — tradition. The location has become more or less ingrained into the minds of the users and the developers.

Change is something that we need to deal with. I understand that changes like this are difficult, especially for those of us who have been using the system for a long time.

Fortunately, for those of us who are brave enough, relocating portage to a more compliant (or sane as your prefer) location is not so complicated.

A quick perusal of /etc/make.conf.example should point out a certain variable of interest: PORTDIR. Simply setting this variable in /etc/make.conf allows us to relocate the portage tree to a location of our choice. I personally, prefer /var/portage. Though this directory is not specified by FHS, it is more compliant, as it has variable data that has system-wide implications. In order to be nice to the servers, you should move the portage directory to its new home.

Next you need to update the location of your profile.  This is simple as well. It is just replacing the symlink with the updated path (hint: you can view the old path of the profile via ls -l /etc/make.profile).

Moving on, we need to address the distfiles location.  This directory holds the distfiles for the packages that you install.  We need to  relocate this, otherwise, portage will just recreate this location.  Again, a quick perusal over /etc/make.conf.example should show you an interesting variable: DISTDIR.  Setting it to the value from the example is sufficient (${PORTDIR}/distfiles).

Another such directory that we need to worry about is the packages directory.  This defaults to /usr/portage/packages.  As in the previous cases, adding a simple variable to /etc/make.conf makes portage and FHS all happy.  In this case, the variable is PKGDIR, and just like distdir, the value from the example file is sufficient, (${PORTDIR}/packages).

If you try to actually use emerge now, you will notice that it is quite a bit slower. This is due to the fact that the metadata is location specific. The metadata is stored in /var/cache/edb/dep/. We can safely remove the existing metadata to reclaim the space. After this, you should run emerge –metadata. This should restore the metadata information for the repository, resulting in portage’s speed being restored.

For the interested, the relevant parts of the FHS Specs (v2.3) are Chapter 4, Section 1 and Chapter 5, Section 1.



•January 25, 2007 • Leave a Comment

So, drobbins blogged about something which has come up before (or am I just imaging that I have conversed with others about this topic before?).

Gentoo’s package set has grown immensely over the past years. While this is a great thing, it also can be a bad thing. One big issue that crops up when you have such a large group of packages is that the maintainence overhead grows. The result of this is that you start to loose quality. As more and more quality is lost, users will become uninterested. It is not fun when you can not even install a package because of insufficient QA.

The base tree could house the core packages, and then everything else could easily be pulled in from overlays. This way, more attention could be provided to QA, and you also get space savings! Currently, the portage tree on my laptop is 524 MB. I dont use a large portion of the tree, and I would imagine that most users dont use a large portion of the tree either.

Almost every other distribution faces this problem, and most of them came to the same solution: split up the packages. Collectively refer to the sets maintained by developers as the official packages, and then allow contributions. Gentoo could do the same: split up the tree, but still maintain an official and user-supported set of packages.

I think that splitting up the tree is the way to go, but of course I may just be a dillusional insane code monkey.

metapackage bumps made easier

•December 30, 2006 • Leave a Comment

So, the other day tsunam prodded me to whip up a script to make it easier for him to version bump beryl. The result? A semi-decent version bumping script in bash. You can grab it at svn:// . Its a fairly simple script, that hopefully will be somewhat useful.

Theres a few things which have yet to be done, one of which will be automatically changing the KEYWORDS to ~arch if it is not so. Ideas to improve it (as well as patches!) welcome.

Using it is fairly straight forward. bump-pkg <pkg> <old version> <new version>. You can specify the commit message to be used as well, but that is an optional parameter. It does however depend on gentoolkit-dev for the echangelog, which, if really desired, I could change into bash as well.

Why Blog Now?

•December 22, 2006 • Leave a Comment

So, I finally start blogging, and this is my second entry already. This is mostly to separate out the two different topics of the posts. Im sure that one of the questions that anyone who finds this would wonder. Why did I decide to start blogging now? Well the reason is more or less tsunam‘s constant poking at me that I should do something with my domain (well, more so than use it to host random files and mail and such). He bugged me enough to actually blog , and since I didnt feel like actually setting something up on my server (atleast, for the time being), and I had already picked up this account a while ago, I thought Id put it to use. If I end up actually blogging sufficiently, I may consider moving over to my actual domain. But time shall tell how that goes.

Happy tsunam? Im finally blogging!

GNOME 1.x Removed

•December 22, 2006 • Leave a Comment

Well, its finally done. Yesterday marked the end of GNOME 1.x packages in Gentoo. It was rather fun removing all the packages, which I couldn’t have done it without the help from jakub and the rest of the GNOME herd.

We had been looking towards removing GNOME 1.x for quite some time now. It has been deprecated for quite some time. Upstream has stated they do not wish to continue support it. As a result, we had to mantain it. So this will allow us to focus more on the newer current packages.

The removal of the packages did help one other thing as well. It made me realize how terrible CVS really is for management of sources. As a result, I have written up a few helpful wrappers to deal with CVS.  The idea was inspired by tsunam’s suggestion of scripting some of the removal.   Im hoping that this will be helpful to others as well as myself. The helpers are at svn:// . Feel free to suggest additional commands which would be useful for this.

This set of cvs command wrappers wont exactly make dealing with CVS as nice and easy as say Subversion or GIT, but every little thing helps. Perhaps I may draw up the courage to make a few helpers to help remove packages from portage’s repository, though Im not sure what the utility of such a utility would be. If others feel that it may be useful, I think I may give it a shot.