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

[Daniel Robbins]

OK, my initial impression of this is:

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

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.

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.

4) Building on 3, I think there are two ways of life in the world of
Portage - either the eclasses control you, or you fight back a bit and
control the growth of eclasses. The eclasses are sort of an
"anti-architecture" so I think our will should to be imposed on them
rather than the other way around. Otherwise you are in a catch-22
where we are continually adding tons of weird "legacy code" in the
form of eclasses and this problem of cross-package manager
compatibility will never go away.

Those are my thoughts, anyway...

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

-Daniel

On 2/20/07, Ciaran McCreesh <ciaranm@×××××××.org> wrote:
> On Tue, 20 Feb 2007 12:19:12 -0700 "Daniel Robbins"
> <drobbins.daniel@×××××.com> wrote:
> | I think that standardization is a good thing and interoperability
> | between paludis, portage, pkgcore and others is something we should
> | strive for. If at all possible, I think that this standardization
> | effort should be "multi-lateral" in the sense that Gentoo and pkgcore
> | are also active participants in the standardization process.
>
> Well, Gentoo already is a participant, in that there are a number
> of Gentoo developers with access to the document... At this stage, we're
> deliberately keeping the numbers down because we want to get it done
> rather than spend huge amounts of time arguing with the peanut gallery
> (the same approach we took with eselect, the devmanual and Paludis,
> rather than the approach taken with portage-ng and Zynot).
>
> | Also, I don't think that the council itself needs to be involved
> | directly, as a standards/spec project can be created and worked on,
> | and the conformance of Portage to this standard can be measured, and
> | if desired Portage developers can tweak portage so that it is more
> | conformant to this standard. This can be done voluntarily by all
> | parties, as they deem it useful.
>
> The reason the Council is involved is because someone has to give final
> approval. This won't be asked for until late on in the process.
>
> | I think standardization should focus on real interoperability issues,
> | rather than esoteric technical issues.
>
> The esoteric technical issues are the problem, though. The areas where
> there are interoperability problems are the areas where ebuilds are
> doing weird things, like relying upon side effects of one
> implementation of inherit or trying to manually modify vdb or assuming
> that certain variables that contain directory names will not include a
> trailing slash. The question is whether the ebuilds are wrong in
> expecting to be able to do this, or whether package managers have to
> emulate weird quirks in how Portage is currently implemented.
>
> I'll give you a perfect example. Paludis currently includes the
> following workaround:
>
>     archives = strip_trailing(archives, " ");
>     all_archives = strip_trailing(all_archives, " ");
>
> The reason that this is necessary is because kde-meta.eclass does this:
>
>     [[ -n ${A/${TARBALL}/} ]] && unpack ${A/${TARBALL}/}
>
> Which means that if a package manager includes trailing spaces in ${A},
> the eclass will break. Personally I consider this to be an eclass bug,
> but without some standard to back it up there's no concrete answer
> either way.
>
> Another example along the same lines (this one's now fixed in the tree,
> but it's a good example of weird side effect behaviour): The PHP
> eclasses used to set a global scope variable called EXT_DIR based upon
> the value of a variable called PHPCONFIG. The PHPCONFIG variable was
> set in pkg_setup, and the EXT_DIR variable was used later on. For
> Portage as it is currently implemented, this happens to be ok, because
> eclasses are re-sourced for every phase. For Paludis this breaks,
> because we implement the environment saving that Portage is going to do
> at some point to avoid the eclass API problems.
>
> Another example: A certain eclass we all know and love used to use
> SLOT=${PVR} and then force uninstalls by overwriting VDB SLOT files
> when installing packages. As it happens, Portage doesn't cache those
> entries, and because of how it implements cleaning the hack happens to
> work. The question is whether ebuilds are allowed to rely upon weird
> quirks like that (and, indeed, whether ebuilds should be reading VDB at
> all).
>
> Another example: Various ebuilds rely upon the order of items in $A
> matching the order in $SRC_URI. This one's arguably useful, but at the
> same time it's questionable as to whether it works by fluke.
>
> It's these cases that are the problem, not the generalities. On the one
> hand, requiring that package managers implement every Portage quirk
> identically is insane, and stops Portage from changing behaviour in the
> future. On the other hand, restricting the API to only completely sane
> things makes it much harder to code certain ebuilds -- the $A ordering
> is one example of this.
>
> --
> Ciaran McCreesh
> Mail                                : ciaranm at ciaranm.org
> Web                                 : http://ciaranm.org/
> Paludis, the secure package manager : http://paludis.pioto.org/
>
>
>
-- 
gentoo-dev@g.o mailing list