The expanses of WolfWings' land
scratched on the wall for all to see

July 19th, 2007
July 19th, 2007
July 19th, 2007
July 19th, 2007
July 19th, 2007

[User Picture]03:43 am - I've been using Gentoo for a'while...

The basic idea of my configuration approach is reducing interdependencies, so things might have dependency chains many layers deep, but things won't cross-depend on each other very much (if at all) so rebuild times are reduced.

First, don't enable 'unstable branch' globally. Even if you're using an esoteric platform, stick to the 'stable' stuff by default. This isn't to say don't enable the 'beta' stuff in some cases, but don't assume 'beta = better' since you have to recompile everything whenever a new beta version comes out. This takes a'while even on my 2.0Ghz machine w/ 2GB of memory.

Just as a refresher, if you need to manually add an arch-tag to emerge an individual package (say media-sound/niftysoundeditor):

echo media-sound/niftysoundeditor ~amd64 >> /etc/portage/package.keywords

Now, we'll take the most common component, audio interfaces, as an example for my dependency-chain approach:

First off, don't enable all your various sound-system options on all your individual programs. That means -sdl, -alsa, all that sort of jazz in your make.conf file.

Second, be ready to set custom settings for individual packages. Not everything will support the approach I take out of the gate, but Gentoo provides very good systems for managing options on a per-package basis. If the package is called media-sound/niftysoundeditor, and you need to enable ALSA on it because it doesn't support SDL:

echo media-sound/niftysoundeditor alsa >> /etc/portage/package.use

Basically, I have ALSA, OSS, most graphics, sound, and audio interfaces entirely disabled as a global default. What I do have enabled is SDL, and one or two other special-purpose interface libraries related to that. SDL itself has ALSA, OSS, and other options enabled. Why? Because it forces all the applications to go through a single system for access to my sound and graphics hardware, so I can control access and settings much more easily that way.

In a way it adds a layer of indirection, but usually only on setup and shutdown of an application. Once it's running, it's just transferring buffers of data that get transparently passed through the 'glue' libraries. And since the programs are only using one possible audio interface (so only one road to build), compile times are reduced as well.

Now... what if you just don't want to upgrade a particular app because it takes forever, and the new version doesn't add anything of interest to you? /etc/portage/package.mask is your friend! Same format as before, folks. Let's say you have media-sound/niftysoundeditor version 1.44 installed, and the newer version has a crashing bug in it whenever you try to load your Bach Symphony in it. How do you downgrade again, and prevent upgrades for now?

echo ">media-sound/niftysoundeditor-1.44" >> /etc/portage/package.mask

And in case the opposite occurs (some package has a wide-spread problem reported, but you don't exhibit the problem and don't want to downgrade because you'll lose some feature you're using now) here's how to undo a Gentoo-imposed package masking that suddenly wants to downgrade you from v1.44 of your niftysoundeditor:

echo ">=media-sound/niftysoundeditor-1.44" >> /etc/portage/package.unmask

A lot of longer-term Gentoo users will know all these /etc/portage/package.* files I'd imagine, and I'm sure there's some GUI tools to manage them that I'm unaware of since I live on the command-line so much. But I felt I should punt this info up for folks just in case it's useful, and somewhat for my own reference as well.

Now that I've written it though, I'm wondering if I should possibly clean it up and post it somewhere for longer-term display. Any thoughts from the peanut gallery out there?

2 commentsLeave a comment

Log in

No account? Create an account