Re: EAPI spec (was Re: [gentoo-dev] Re: let's clear things up (was Slacker archs))

[Ciaran McCreesh]

On Tue, 20 Feb 2007 14:12:12 -0700 "Daniel Robbins"
<drobbins.daniel@×××××.com> wrote:
| 1) ebuilds and *especially* eclasses do way too many weird things and
| can often depend on idiosyncrasies of portage. The eclass bash scripts
| can be quite complex and probably 9 out of 10 (99 out of 100?) times
| I'd put the burden of compatibility on the eclass rather than the
| package manager, because it's the eclass that's trying to do "weird
| stuff."

Yep. Here's the problem though:

How much of the tree is it ok to modify, and how complex are the
modifications allowed to be, for the sake of compatibility?

The aim with Paludis is to ask for modifications only where it's a hard
dried "the ebuild / eclass is doing something highly stupid", simply
because that's the only way it will be accepted. Even then, some
maintainers refuse to make changes to code that works with one
particular version of Portage. And until PMS is standardised, there's
nothing that can be done to make them do otherwise.

| 2) to ensure cross-package-manager compatibility, all one would need
| to do is document what one can and cannot assume regarding Portage
| functionality. I see no harm in having the ebuilds/eclasses assume
| less and encourage others to write more robust and compatible ebuild
| and eclass functions.

In principle, I agree. In practice, writing robust bash code is a pain
in the ass. If it's the case of a couple of lines of hacks in the
package manager or a dozen lines of hacks in hundreds of ebuilds, it's
simply more practical to impose a weird requirement upon the package
manager.

| 3) I regretfully added eclasses to portage. Although they're useful, I
| don't think they ever made sense from an architecture perspective and
| are certainly not pretty. Eclasses are nearly ubiquitous now, which is
| unfortunate. I can't remember seeing an eclass that I ever liked, even
| if the functionality was really useful and everything was
| well-written, thought out, documented, etc.

Eh, my objections to eclasses are purely based upon the limitations
imposed by Portage (the "no API change" one). As a general idea they
make the tree a lot less complex, and they often move all the package
manager dependent hacks into one place...

| If you wanted to get me to agree with you by giving me lots of eclass
| compatibility issues, then it worked :)

Hm. Maybe I should have picked up some of the dodgy ebuild code
instead... There's a heck of a lot of that too. It's just that eclass
weirdness is easier to find.

-- 
Ciaran McCreesh
Mail                                : ciaranm at ciaranm.org
Web                                 : http://ciaranm.org/
Paludis, the secure package manager : http://paludis.pioto.org/