Re: [gentoo-dev] RFC: The big eclasses massacre

[Brian Harring]

On Sun, 2004-11-07 at 21:32 +0000, Stuart Herbert wrote:
> > On Sunday 07 November 2004 21:23, Ciaran McCreesh wrote:
> > > Well, that wouldn't be a problem if people kept code in eclasses for as
> > > long as necessary. Avoiding the need to change multiple files more than
> > > necessary is one of the reasons we have eclasses. Versioned eclasses
> > > could very easily lead to that kind of horrid mess we already have with
> > > having to update zillions of profiles whenever something changes.
Offhand, I'll just state I'm against versioned eclasses.  I assume
you're attempting to free up the eclass development so that you can
basically forget about about backwards compatability, by leaving older
eclasses sitting in the tree for all of enternity so that packages
installed w/ that eclass can be removed.

You're attempting to restructure eclasses to compensate for a portage
deficiency.  Fix the deficiency, don't build kludges/duct tape to get
around it :)

The env code I worked up for in bug #56408 is in portage cvs- among
other things, the _only_ time the ebuild/eclasses are required for any
package phase is setup.  I'll be adjusting the code so that it's only
required for setup when building, not for setup when installing from a
package also, so eclasses from the tree are no longer used with binpkgs.

What this means is that when that code is released, eclass versioning is
no longer an issue.  The env is saved, and portage no longer cares if
the eclass exists- you could wipe your tree (exempting profiles), and go
and uninstall packages without any major issue, exempting a couple of
trivial aux_get exceptions that amount to noisy complaints.

Ultimately, I'd like to see the tree get to the point where everything
but the basic ebuild functions (internal ebuild.sh functions, like
dyn_preinst) are stored in the tree- basically move everything so that
the tree contains the needed code for creation of the stored ebuild env,
and buildling.  For a binpkg, you don't need the ebuilds, the tree
format is different, so the issue of having eclasses available shouldn't
be a requirement (this is a whole other thread however, one I'll bring
back up in the near future).

Back on topic, regarding having multiple eclasses of the same name
across repositories, that's a nastier/fuzzier issue.  Basically, portage
kind of crap shoots which repository it'll raid the eclass from- this
should be nailed down so that an ebuild merged from xyz repo, uses xyz's
eclasses -first-, then defaulting back to the main repository (portdir).
At the moment, inherit doesn't function in this manner- it basically
splits the PORTDIR_OVERLAY var, and walks it looking for an appropriate
eclass.  So if you had repositories a, b, and c, and repositories b and
c had eclass xfree, and you were merging an ebuild from, portage would
use repository c's xfree eclass.
/me notes that was wordy, but it's how it functions currently

If that seems sane, a bug could be filed regarding it and the inherit
function modified to work in the desired manner...

> What this says to me is that eclasses should be handled using
> DEPEND-like syntax. inherit x11, or inherit >=x11-2.
Err. no.  That dirties things up for minimal gain, imo.  Versioning
eclasses -will- allow you to make a clean break from the existing eclass
implementation, however its adding additional logic to inherit that's
ultimately no different then inheritting a different eclass name.  What
does the proposed inherit syntax bring to the table, that isn't already
available?

My two cents :)
~brian


--
gentoo-dev@g.o mailing list