List Archive: gentoo-alt
Note: Due to technical difficulties, the Archives are currently not up to date.
provides an alternative service for most mailing lists.c.f. bug 424647
> Sort of responding to/being inspired by haubi's comment on -dev about
> "inherit eapi 4", I wondered whether we should make a prefix.eclass.
> Currently we have eprefixify as function provided by Portage, and hence
> ebuilds that use eprefixify cannot be straight ported to gentoo-x86.
> Most notable are the eselect-* ebuilds that some gentoo-x86 devs like
> give full Prefix support, but simply can't because eprefixify (which we
> would use) cannot be used in gentoo-x86.
> So, should we start an eclass with for now eprefixify in there, and for
> every ebuild where we use it, start inheriting prefix and nuke the
> function from Portage? Somehow I think this is a good idea.
Hmm, sounds like a good idea. This would indeed solve some of the posed problems.
> Since I like haubi's idea about inherit doing the magic for eapis,
> perhaps this can even solve the problem we have with our EAPI mungling
> (all our ebuilds just inherit eapi prefix to "tag" them) and all
> eclasses (it remains a hell of a job to keep it working), as well as
> having prefix ebuilds live happily next to non-prefix ones. But for
> that we really need Portage to be able to mask based on what's in the
> inherit line, e.g. the resolver needs to take it into account.
I believe this can be done without too much effort, although I'm not sure if this can be considered "clean". OTOH, why not? This would enable users to express things like: "I want live ebuilds, but none that come from svn" (and thus inherit subversion.eclass).
> Fabian Groffen
> Gentoo on a different level