Re: [gentoo-dev] The future of eclasses

[Karl Trygve Kalleberg <karltk@prosalg.no>]

> This is all almost certainly portage v2 stuff. However I'd like everyone 
> working on portage (e.g. Bevin, with whom I've spoken) to know where we 
> stand, to coordinate our efforts. As always, any ideas, forecasts, 
> suggestions etc. are always welcome.

I like the idea. If its documentation becomes part of the ebuild howto,
it will get adopted fairly quickly. 

The main concern Hallski and me (and possibly others, such as John
Stalker, if memory serves) was that the current ebuild system mirrors
the manual build process so closely that external contributors have
little or no difficulty sending us ebuilds.

I think this can be solved somewhat if it is clearly documented _what_
is assumed by the various eclasses and perhaps a motivation when the
assumptions are less than crystal clear.

What plagues many non-kde ebuilds is that their build systems are fairly
non-standard. And even packages with seemingly standard build systems
quickly turn out to have both minor and major flaws (Mailman is a good
example of a horrible build system that on the surface looks nice, but 
in practice turns out to be a real bitch).

The minor nuisances of the various build systems mean that we might find
it easier to patch the generated Makefiles instead of the Makefile.in or
Makefile.am files, thus requiring an intermediate step between
configure and make (ie, patching in src_unpack is too troublesome).

Consequently a simple wrapper for src_compile will only work a certain
percentage (possibly relatively low; <= 50%) of the time, and a
full-blown manual src_compile() function must be written for the rest of
the ebuilds.

The situation for src_install() is even more dire, as it would appear
that close to all packages have trouble conforming to any kind of FHS,
and installing in a temporary directory is completely foreign.

Now, for our regular ebuild writers, the 50% saving is a big deal. For a
new submitter, it means he has to figure out which eclasses are
available (+ what they are), which criteria his package must meet to be
able to avail himself of the various eclasses, and finally test that
this is really so.

In conclusion, I am very positive about eclasses for our regular
contributors; it would possibly give us yet another advantage to our
package system that would allow us to add more ebuilds more quickly (one
could argue that quantity in itself is not a good thing, and of course I
agree ;). But if our intention is that "regular" users should easily
be able to submit ebuilds, and more easily so than writing a debian
package or an rpm spec, then we must be very careful to consider the
result eclasses have on our "regular" users.

</rant>

Kind regards,

Karl T