Intuitive packaging is vital to Gentoo

A post I made on the Gentoo development list last night deserves your attention because it illustrates a key aspect of Gentoo. I want to make sure it’s preserved instead of lost in mailing-list archives. This is in reply to a proposal to move a significant portion into a series of variables instead of being written as scripted functions:

I think the idea of ebuilds as scripts showing directly how to build software is a core part of the Gentoo build-system philosophy. This proposal pushes ebuilds toward a formatted file that is not a script. Instead, it is more like an Ant XML file that more abstractly describes a build. I think this is the wrong direction for ebuilds because they should directly resemble how software is built by hand.

One of the key reasons people use Gentoo is that ebuilds are so easy to “get” for anyone who has ever built software by hand. I will continue to vehemently defend anything that I think retains this key advantage of Gentoo over other distributions.

Gentoo is a distribution for advanced Linux users, or those who want to become advanced. Having packaging scripts that are easy to learn lowers the barrier to entry to editing them, which vastly increases our number of potential developers. It additionally comprises a key part of Gentoo’s ease of customization by allowing people to easily write their own packages or modify existing ones for their purposes. When users do this, it creates a natural pathway from building software by hand to editing ebuilds to becoming a Gentoo developer. The more difficult it is to learn how to write packaging scripts, the more of your potential developer base you repel.

7 thoughts on “Intuitive packaging is vital to Gentoo

  1. First comment – as a user, I’m really glad to see people posting on blogs.

    I’ve not done much with ebuilds besides read them, so I’m no expert. Seems like this is the typical problem of modelling vs. not modelling the domain in question. That is, by expressing data in variables, you’re modelling what those variables capture. I’d say the question is not as clear-cut as you frame it. If you model the data, that gives you much more flexibility in how the models get consumed – you no longer have to worry about legacy calls to old APIs, for example, since model instances don’t (by themselves) invoke code. That means fewer future bugs, and less complexity.

    Modelling only makes sense, though, if it really captures 90-100% of the domain in question. For example, ebuilds indicate dependencies. There is but one way to do it, and scripts currently model it. If, however, there end up being five or more ways that ebuilds do things, the resulting models could be more complex, and more confusing, than simply writing the scripts that you prefer.

    Like any tool, modelling can be over-used. The same can be said about scripting.

  2. I would personally be repulsed if they replaced ebuild with something XML driven. That’s horrible.

    And I’m pretty sure you’d see a lot of people running from Gentoo screaming.

    I know people who have to use Ant to distribute things, and its in many cases a solution that asks only for new problems.

    Imho, If you don’t know how to augment an ebuild, you can’t do shell scripting. If you can’t do shell scripting, you’re not very experienced with using shells. If you’re at this level, you’re not even really fit to be writing ebuilds, because what you’d be telling them to do in the first place would be stuff above your knowledge.

    I think were much better with software that “does the right thing” as hard as it can ( Ie: gcpan converters for Perl ) and have ebuilds available when that doesn’t work.

  3. The proposal does not make writing ebuilds any more difficult; you can continue to write ebuilds how you’ve always written it. This proposal is just for the really simple cases, where in some cases it’s more intuitive to write:
    than to fully write out:
    src_install() {
    emake INSTALL_ROOT=”INSTALL_ROOT=\”${D}\””

    It’s not really making ebuilds like ant, it’s just making it a bit simpler(and you can still write it the filled-out way). Which is easier to trace what’s going on:;a=blob;f=packages/media-gfx/ImageMagick/ImageMagick-;h=a19ed6c9665355def41103972a527087d8a2010a;hb=HEAD or gentoo’s ImageMagick ebuild? If the answer is gentoo’s ebuild, read the ebuild again.

  4. I have to agree with Donnie. The fact that ebuilds are so simple to write and learn from is one of the things I love about Gentoo. It makes packaging almost anything a breeze.

    While the proposal may mean less code, I think it will increase the amount of work for anyone who wishes to customize the package (add patches, create an ebuild for a newer version which perhaps requires a few more steps to install correctly).

    I think there’s a slippery slope here that Gentoo could easily fall down and end up with ebuilds becoming unreadable, mystic files that only those with a good knowledge of the format can edit.

    There is a difference between less code and simpler code.

    Gentoo is about giving people the tools to easily and flexibly maintain their system. Tools which work for the user instead of the user working for the tools.

    Currently I think ebuilds allow this to be done with very little specialist knowledge of how they work – you can look at the functions and immediately see how they fit together and edit them to your needs. I think that the proposed changes are a step away from this.

Comments are closed.