On Sat, Feb 19, 2005 at 05:16:23PM +0200, Martin Schlemmer wrote:
> 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.
Eclasses aren't supposed to change metadata from system to system, yet they
can. There are ways I can actually
enforce elibs to not modify metadata (late loading of elib functionality), but
I don't care to do that.
One thing that's starting to bother me a bit here, is that my example of -why-
using an elib if you don't want the
template/metadata modified -was- valid. Instead, you're just pointing at elibs
and stating "well they can still do
it". Of course they can, all of this crud is in *bash*.
Eclasses can also modify metadata based on a has_version, yet the majority of
eclasses in the tree -don't-
cause the author knew the eclass rules, and knew bones/me would come after them
with a bat if they did. Devs who
want to ignore the rules, can and do violate what the original intentions of a
component in the tree were for.
They also get slapped hard for not following proper QA.
Here's a question, what are -you're- intentions for elibs Dan? We've already
laid out how portage, and eutils would
benefit- in other words, what will be moved to elibs already.
> > > 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}).
The transfer over that's being kicked around involves importing a base eclass
(always), and a base elib (always).
Those would be the default template, and default ancillary functions that were
previously in portage, and transferred
out.
Regarding commit rights, not sure. That's a seperate issue. The proposal I
preferred was handing maintenance of
that base bit of code/env to the QA herd, and letting them handle it.
If they wanted to get acl's applied for cvs, well, that's they're battle.
My main push was just getting that functionality out of portage so it could be
fixed in a timely matter, rather then
bound to intermittent portage releases.
~brian
--
[email protected] mailing list
