He's not dead, he's resting

EAPI 3: Slot operator dependencies

This is part of a series on EAPI 3.

Traditional dependencies and slots don’t really work very well together. If a package depends upon foo, and foo has multiple slots, the package manager doesn’t know what that means at runtime. Some packages just need any foo, and don’t mind if a completely different version in a different slot is swapped in later. Others need the slot that was around when they were installed.

The original theory was that all dependencies would be runtime switchable, and that any that weren’t would be controlled via use flags. But that’s extremely impractical, and largely pointless for heavily slotted things like db. Slot operator dependencies are a more pragmatic solution for the common case; thus, as of EAPI 3, any package that has both a DEPEND and an RDEPEND upon anything that can match more than one slot should specify either :* or := after the spec.

A :* dependency means “I can use anything that matches the specification, regardless of what was there at build time”. This is often the case for packages using non-compiled dynamic language libraries. Any dependency that is just an RDEPEND and not a DEPEND is implicitly of this type.

In the simple case, a := dependency means “I can be built against anything that matches the specification, but I need the same slot at runtime”. This is the case for most C-style linkage libraries that have a more or less stable API but not a stable ABI or shared object version (db is the canonical example), along with some sort-of-compiled dynamic languages that don’t maintain ABI stability.

The definition of := is slightly trickier if there are multiple slots already installed at build time. Since slots are in no way orderable, it is taken to mean “the slot of the best version that was installed at build time”. We considered letting ebuilds specify which slot they used, but real world use has shown that this is unnecessary and impractical — in reality, packages either just go for the best version of something automatically, or require complex special case handling.

Ebuild authors won’t see this, but anyone poking around in VDB may notice :=blah slot operator dependencies. This is how the package manager handles := dependencies — at install time, it rewrites the dependency specification to have the slot name straight after the equals.

We decided against having a form meaning “I need all the slots that were there at compile time”. Although at first glance this might sound useful, a closer look reveals that it doesn’t solve the whole ABI problem (it just makes it even messier), and we’ve yet to run across a legitimate use case for it that isn’t merely a horrible hack to work around lack of multi-ABI support.

It’s possible to combine either slot operator dependency form with normal dependencies just like EAPI 1 slot dependencies; >=cat/foo-1.3:= is fine. Slot operator dependencies do not make sense when combined with conventional slot dependencies.

Widespread use of slot operator dependencies will allow a package manager to know whether older slots of slotted packages are really required or not, rather than having to assume that they are for safety reasons, or assume that they aren’t and risk causing horrible breakage.

Slot operator dependencies were originally in exheres-0, and were used in kdebuild-1.


One response to “EAPI 3: Slot operator dependencies

  1. Pingback: What’s in EAPI 3? « Ciaran McCreesh’s Blag

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s