He's not dead, he's resting

Intuitive Packaging is Doing It Wrong

Donnie has taken time out of his busy schedule of managing Gentoo to comment on some possible design issues for EAPI 3. He believes that adding support for exheres-0 style DEFAULT_ parameters to ebuilds would result in a less intuitive packaging system, which he considers bad.

Unfortunately, both the term ‘intuitive’ and the conclusion are nonsense. Ebuilds are not intuitive, intuitiveness would not be a useful property for them to have, and allowing parametrisation of default_ functions would not alter any of this.

The only truly intuitive interface is the nipple.
– Jay Vollmer

Let’s look at what intuitive means:

in⋅tu⋅i⋅tive /ɪnˈtuɪtɪv, -ˈtyu-/ [in-too-i-tiv, -tyoo-]

  1. perceiving by intuition, as a person or the mind.
  2. perceived by, resulting from, or involving intuition: intuitive knowledge.
  3. having or possessing intuition: an intuitive person.
  4. capable of being perceived or known by intuition.

Ok, let’s look at intuition:

in⋅tu⋅i⋅tion /ˌɪntuˈɪʃən, -tyu-/ [in-too-ish-uhn, -tyoo-]

  1. direct perception of truth, fact, etc., independent of any reasoning process; immediate apprehension.
  2. a fact, truth, etc., perceived in this way.
  3. a keen and quick insight.
  4. the quality or ability of having such direct perception or quick insight.

So apparently Donnie wants people to be able to write ebuilds without requiring rational thought. Whilst that would go some way towards explaining the state of the tree, it’s evident that ebuilds are not currently intuitive and should not be made intuitive.

What qualities, then, should ebuild design aspire to? Let’s start with these:

  1. Ebuilds should be as obvious as reasonably possible, given the complications of the underlying packaging system and the overall design requirements, to a person with an appropriate level of skill and access to the documentation.
  2. Ebuilds should work to reduce the amount of boilerplate and cut-and-paste duplication required.
  3. Ebuilds should take steps to catch and prevent common errors.

Looking at the first point, one may think it is too weak a requirement — why not “ebuilds should be accessible to your average user”? But then, why should it be?

If you think the average user should have to write ebuilds to be able to get their package manager to track a package they can build by hand — why? Why not simply improve the package manager to be able to track hand-built packages without ebuilds?

If you think the average user should be able to modify ebuilds to add in patches — why? Why not simply improve the package manager to make it easy for the user to add in patches to existing packages?

If you think it will help solve the developer shortage problem — why? There’s no shortage of badly written ebuilds sitting around in bugzilla; making it easier to create more badly written ebuilds won’t fix this. The problem Gentoo faces is how to get more high quality ebuilds, and doing that requires skilled developers who have read and understood the documentation.

Introducing DEFAULT_ parameters has no major effect either way on the first point.

The second and third points are where DEFAULT_ parameters kick in. The reason the default src_configure does something as opposed to nothing is that the something it does is enough for many ebuilds. If instead it were a no-op, a typical simple ebuild would be considerably longer.

Except, these days a lot of ebuilds have a few simple configure options controlled by use flags, so the default src_configure in EAPI 2 (or src_compile in EAPIs 0 and 1) is no good. DEFAULT_ parameters bring this proportion way down.

This brings us to why the default src_install is a no-op. For most packages, something along the lines of “if there’s a Makefile, make DESTDIR="${D}" install” is not enough. For a good proportion of packages, though, that plus an ebuild-supplied list of doc files would suffice.

Donnie claims that specifying things in variables this way is a major change in how ebuilds work. But there are already plenty of examples of things done in this style:

  • The S variable is a declarative parameter to the package manager’s “before we run a phase” functions.
  • Lots of eclasses make use of a DOCS variable.
  • Indeed, nearly all parameterisation of eclasses is done through variables. It could just as easily be done by callback or overridable functions, but developers haven’t opted to do so.

A perfect example of that last point: Donnie’s own x-modular eclass has a variable named PATCHES, which ebuilds set in global scope. If x-modular were using EAPI 3 with a src_prepare and exheres-0 style declarative patches lists, the package manager would already be providing exactly what he’s gone out of his way to implement.

So what gives, Donnie? Do you think your use of PATCHES was a design mistake that you will be correcting? And do you think all those other developers who have been doing the same kind of thing for years are fundamentally wrong?


7 responses to “Intuitive Packaging is Doing It Wrong

  1. Donnie Berkholz March 10, 2009 at 4:26 pm

    I don’t really find the definition part of this post very interesting, because I think people generally know what point I’m trying to make.

    I think that the addition of more granular functions like src_configure and src_prepare makes global variables like PATCHES less interesting because they’re avoiding less work. Unfortunately EAPI=0 doesn’t have those so I’ll have to move all the X ebuilds to EAPI=2 before I can drop it from the eclass.

    I think it’s important for Gentoo to have people writing ebuilds. I think that people will have a hard time writing good ebuilds before they write bad ones, and the more people we have writing bad ones, the more will percolate up to the top.

    • Ciaran McCreesh March 10, 2009 at 4:33 pm

      Words have meaning. If you don’t use words to mean what they mean, no-one knows what you’re talking about. Precision is important when discussing technical design aspects.

      Avoiding less work isn’t the issue — why did you use PATCHES in the first place, rather than defining an empty x-modular_apply_patches function that ebuilds could override? The former’s declarative, which you claim to dislike, whilst the latter is in line with how ebuilds currently work.

      Gentoo already has lots of people writing ebuilds. Most of them suck, and end up sitting in bugzilla forever. Raising the barrier to entry slightly to make things easier for competent developers will just filter out a few of the worse submissions.

  2. cwr March 11, 2009 at 5:50 pm

    One useful thing would be a program that parses an ebuild, and checks it
    for conformity; an ebuild with DEPEND=${RDEPEND} and RDEPEND=${DEPEND] is
    quite tricky to parse automatically, and at least one of these exists.
    There are other glitches, too, which I found when building a partial
    Sqlite3 database for portage.

    Be nice if some of the more common circular dependencies could be removed
    too, but clean ebuild files would be a first step.

    • Ciaran McCreesh March 11, 2009 at 5:54 pm

      The only thing that can parse ebuilds is bash, which means masses of screwing around with debug traps to get anything done. Checking ebuilds for that kind of thing is extremely tricky.

  3. Pingback: EAPI 3: default src_install « 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