Skipping to merge install phase in Paludis

Don't you hate it when building a lengthy package succeeds, installs all right into the image, only to fail for some trivial reason (like out of disk space) when merging into the filesystem? In portage you could just use the ebuild(1) command to short-circuit it right to merge. It's not that easy with Paludis, unfortunately.

But worry not, undocumented environment variables to the rescue! The SKIP_FUNCTIONS environment variable allows you to force paludis not to execute some phases of the install action. The magic combo is SKIP_FUNCTIONS="init killold setup saveenv unpack compile install". It fails on loadenv just before postrm for some reason (probably because we barred it from saveenv, but there seems to be no way to skip one saveenv and not another), but by that point the package is already merged.

But really, they ought to make it easier to do such tricks (or at least document the freakin' variable). I can only imagine how hard it must be to debug ebuilds with paludis... Or maybe there is something I don't know about?

Really nice system administration console

When you're like me, you don't like your CPU cycles waste — and if you're using Gentoo, you like to be constantly merging something in the background. The problem is that the CPU and IO load really can be a major PITA, rendering the machine essentially unusable to do any real work when compilation is running.

Luckily, Linux kernel offer a great deal of flexibility when it comes to scheduling and prioritizing processes. And using that, I hereby present you The Really Nice SysAdmin Console:

alias suscreen="sudo screen -drU || sudo nice -n19 ionice -c3 chrt -b 0 su - -c 'screen -U'"

What this code does, is to:

• try to attach to an existing root screen (won't work for more than one, sorry),
• in case that fails (ie. no screen running) it sets up a root login screen, scheduled on
  • lowest nice priority,
  • idle io priority class,
  • BATCH scheduler class.

Maybe chrt -b 0 and nice -n19 are a bit redundant, but you're never too sure. The bottom line is — you can have your compilation running in that screen and it doesn't go in the way with whatever you do; when need be, it just yields any CPU and IO to higher-class (ie. your) processes. So you can have your cake and eat it too.