Blag

He's not dead, he's resting

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:

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.
  • 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.

Advertisements

3 responses to “Dependency Annotations

  1. doh May 14, 2008 at 3:11 pm

    Why not just keep metadata where it belongs?
    Everything but the bad-idea-anyway blocker is stuff for the metadata.xml file.

  2. Ciaran McCreesh May 14, 2008 at 3:19 pm

    Because a) there’s no way of uniquely identifying subparts of dependencies for doing the labeling, b) no package manager critical information is allowed to be in metadata.xml anyway and c) spreading the data out into multiple places makes things a pain in the ass for developers, especially when they have to start dealing with per-version information.

  3. dleverton May 14, 2008 at 3:50 pm

    > Everything but the bad-idea-anyway blocker is stuff

    Kindly explain what’s bad about it.

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s