He's not dead, he's resting

Category Archives: exherbo

My Exherbo Supplemental Repository

I’ve tidied up my Exherbo supplemental repository (which is what Gentoo people confusingly call an ‘overlay’) and published it for the foolish.

Current goodness is:

Expect these to be neglected and / or broken irregularly.


Installing and Configuring Exherbo

Unfortunately some people think that Exherbo‘s assertion that you aren’t supposed to use it means “you’re supposed to use it”. To stop these people from asking the same annoying questions again and again, here’s how you do an install. Note that you will almost certainly find lots of weird and obvious bugs — this is of course a deliberate feature.

  • Boot your system off a netboot image or livecd or whatever. Set up your disks and networking.
  • Pick a stage based upon arch, datestamp and which developer you think is least likely to have screwed up / deliberately broken things to see if you’re paying attention. Extract said stage into your root.
  • Tinker with the Paludis config you get from the stage until you’re happy.
  • Do your bootloader and kernel thing.
  • Reboot into the stage using init=/bin/bash.
  • Set up mounts, device nodes and networking by hand. Hope it’s your lucky day, and try to use Paludis to install Paludis (you’ll need current SCM trunk, not a release). This probably won’t work, because we probably completely changed the exheres-0 format between when your stage was made and when we updated the tree. So install Paludis by hand, then reinstall it using itself.
  • Idly consider installing a proper init system. Your choices appear to be:
  • Reboot.
  • Belatedly realise that no-one told you to set a root password. Curse.
  • Try updating things.
  • Realise you just wasted the past three days.

Solving the server / headers / libs USE flag problem

There’s been some discussion on the paludis-user mailing list about embedded package management. This got me thinking about the server / headers / libs problem, which is roughly as follows:

In some situations, we’d like to be able to split a package up into different ‘parts’. A part is something like ‘headers’, ‘libraries’, ‘server’, ‘client’, ‘binaries’ and ‘docs’. Some distributions do this by having separate packages. This is nasty:

  • It means either building gcc five times or introducing new hacks to make multiple packages from a single build.
  • It hides information from the package manager.
  • It means the user has to have lots of packages installed to represent one real ‘package’. This in turn leads to complications like “if I uninstall foo-libs, should foo-headers go automatically too?”.
  • It’s a hack introduced to get around package manager limitations.

Use flags for parts, as use flags are currently, aren’t the solution either, since packages need to be able to depend upon “foo with at least libs and headers enabled”. Theoretically USE dependencies (which are in kdebuild-1 and hopefully future 0-derived EAPIs) solve this. But it’s a mess — every package DEPENDing upon foo would have to do DEPEND="blah/foo[libs][headers]" RDEPEND="blah/foo[libs]". This doesn’t scale well.

I used to think that solving this required package manager knowledge of something we could call ‘parts’, which aren’t use flags. But it occurs to me that parts really are just use flags, with a few extra requirements:

  • Enabling some parts might require enabling others, and enabling no parts at all might not make sense. So we need some way of restricting valid combinations of USE flags.
  • Dependencies upon packages with parts need to be simpler. Rather than saying “I need foo with this part and foo with that part at DEPEND time, and this part at RDEPEND time”, we’d like to be able to say “I need foo” and only specify parts in special cases.
  • The package has to be able to do the splitting and partial builds as appropriate or possible. This one needs per-ebuild support, since packages vary wildly in how they support partial builds.

The first bullet point is something we need to solve for future EAPIs anyway. The second is more interesting, and I think there might be a fairly simple solution…

One thing we’ve been playing with for consideration for future EAPIs or exheres is tweaking IUSE (or MYOPTIONS for exheres) syntax somewhat:

IUSE="foo bar linguas: en fr userland: gnu"

instead of:

IUSE="foo bar linguas_en linguas_fr userland_gnu"

This gets especially important when one learns that there is talk of removing the “expanded values don’t need to go in IUSE” special case that current EAPIs have.

When thinking about implementing this for Paludis, I started considering whether anything else useful could go in IUSE. And it seems to me that solving the parts problem could be as simple as this:

IUSE="foo bar libs(+DEPEND,+RDEPEND) headers(+DEPEND)"

What this means is “unless explicitly stated otherwise, when I resolve a DEPEND, I need to be built with libs and headers enabled, and when I resolve a RDEPEND I need to be built with headers enabled”. Then we’d need a new kind of USE dependency meaning “I don’t care about this flag” for special cases.

This also solves another problem:


Which means “if I’m built with minimal enabled, I don’t satisfy any dependencies unless they explicitly say that minimal is ok”.

Syntax could change. And I might drop the entire idea if it turns out it doesn’t do its job. But it’s interesting enough to write up so that I don’t forget about it entirely, at least…

Dependency Annotations

There are various issues with the lack of expressiveness of ebuild dependencies. Some of these include:

  • There’s no way to explain unobvious dependencies, either to end users or to developers.
  • When using suggested dependencies (in kdebuild-1), there’s no way to explain the suggestion.
  • Blockers need to indicate whether they can be uninstalled straight after rather than before the blocking package. Zac thinks this can be done automatically, but in the general case this is dangerous.
  • User-visible blockers need to be explainable. Rather than showing a horrid red flashy, the user should be told “foo and bar both provide /usr/bin/fnord. See someurl for details”.

If we do a kdebuild-2, we’ll probably go with something like this:

    zoo/monkey [[
        description = [ it needs a monkey ]
        url = [ ]

    !zoo/clown [[
        description = [ clowns will murder us in our sleep ]
        url = [ ]
        resolution = uninstall-blocked-after

    >=zoo/rabbit-2.3 [[
        note = [ suggests 2.1, but we get runtime failures ]

        zoo/snake [[
            description = [ otherwise we can't strangle things ]

Note how we’re using square brackets for quotes. Single and double quotes get a bit messy inside shell strings. If real world experiments show that this isn’t enough, we can easily extend the syntax to also allow various other kinds of quotes.

We’ll have a number of ‘recognised’ keys for annotations:

  • description, which gets shown to end users. Generally a good idea on suggestions and blockers, usually not a good idea on normal dependencies.
  • url, ditto.
  • note, which shows up in --query --show-dependencies but not --pretend --install. Contains developer-relevant notes.
  • resolution, for blockers. A hint to the resolver, with values along the lines of manual, uninstall-blocked-after, uninstall-blocked-before and upgrade-blocked-before.

For automatically-generated ebuilds, tools can add their own keys.

The nice thing about doing annotations this way is that any unrecognised annotation keys can be ignored. Annotations probably aren’t the right solution when the information they convey is mandatory (they shouldn’t be used to implement use dependencies, for example), but for optional extras they’re clean, flexible and extensible.