He's not dead, he's resting
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:
DEPEND=" zoo/monkey [[ description = [ it needs a monkey ] url = [ http://explain.example.com/?zoo-monkey ] ]] !zoo/clown [[ description = [ clowns will murder us in our sleep ] url = [ http://explain.example.com/?clowns-are-evil ] resolution = uninstall-blocked-after ]] >=zoo/rabbit-2.3 [[ note = [ configure.ac suggests 2.1, but we get runtime failures ] ]]" PDEPEND=" suggested: 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.
note, which shows up in
--query --show-dependenciesbut not
--pretend --install. Contains developer-relevant notes.
resolution, for blockers. A hint to the resolver, with values along the lines of
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.