On Sat, 2005-02-19 at 14:47 +0200, Dan Armak wrote: > On Saturday 19 February 2005 12:45, Martin Schlemmer wrote: > > > IOW, if someone changes an elib, that can still change an ebuild's > > > behavior and even its metadata - depending on how that elib is used. Just > > > as if I changed the way /bin/cp works, some ebuilds would break. The > > > restriction that elibs can't affect metadata and ebuild functions simply > > > by being imported won't prevent developers from breaking things. > > > Therefore IMHO elibs don't help us deal with the problem described in the > > > GLEP. > > > > I do not agree. Last time I checked, the 'metadata' was referred to the > > data or variables in the ebuild that portage needs to calculate > > dependencies, etc. This do not include src_unpack/whatever that do not > > modify DEPEND/whatever (or at least should not), so your cp example is IMHO > > invalid in metadata context. > My cp example was only meant to demonstrate that changing elibs can still > break ebuilds, so separating elibs from eclasses wouldn't help with the > problem the GLEP talks about - accidental breakage. This example indeed has > nothing to do with metadata caching. >
Then I guess we do agree that the GLEP's topic might need a bit tweaking
=)
> > Forget about caching for now. The main reasons for elibs (correct me if I
> > am wrong), besides the caching issues are:
> > 1) To sanitise eclasses so that they can do the original template function
> > that I think you intended for them. Lets call it a general crap cleanup
> > solution.
> > 2) Have a library repository of ebuild.sh helpers that are not bound to
> > portage releases. The original reason why I did eutils.eclass and not
> > submit epatch to the portage guys, was because I wanted it _now_, and if
> > I needed to change/fix anything, I wanted to do it _now_ - not wait for
> > the next portage release.
> >
> > And 2) really does go broader than just eutils - then we might be able
> > to have live updates to dobin, etc (as Mike already mentioned I think).
> That's fine. It's just not what the GLEP said. In fact, if you move things
> like dobin to live code in CVS, that would only increase the potential for
> accidental breakage of the tree, which is the opposite of what the GLEP asks
> for.
>
I think ferringb or someone else said those will go into say
elibs/(default|core|whatever), and only they will have commit rights
(prob more
virtual like gentoo-src/{portage,rc-scripts}).
--
Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa
signature.asc
Description: This is a digitally signed message part
