On Sat, 2005-02-19 at 10:27 +0200, Dan Armak wrote: > On Saturday 19 February 2005 03:00, Brian Harring wrote: > > > The third is eclass/elib separation. That's the only one I feel not to be > > > a real issue. The proposed solution won't benefit anyone IMHO. I support > > > the other two parts. > > > > Well, what is eutils? Yes, portage thinks it's an eclass, but -what- truly > > is it? It's bash functionality, that doesn't modify the ebuild > > template/metadata. > > > > So why is (basically, at this point) the whole tree regenerated for an > > eclass, that doesn't actually modify anything? This ^^^ is a nasty load > > infra wise. It's minor, but it's also a nasty load for people working on > > the eutils eclass too- single change, and most of your cache is > > invalidated. > > 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. As for the wrong usage - at least then we can tell them to move some or other crap to the right place, other then the current mess we are sitting with. Also, I do believe we have QA people ? > As for this new issue of caching, I don't know firsthand how important it is > to infra. I do know though that even if we somehow enforced the restriction > that functions from elibs can't be used to create metadata, the great > majority of today's eclass code would correspond to new-style eclasses, not > to elibs. And so there would still be frequent changes invalidating the cache > for big pieces of the tree. I don't expect the benefit from elibs to be very > large here. But perhaps I just don't have enough data on that. 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). As for the current eutils.eclass/flag-o-matic.eclass metadata issues - the patch/sed/libtool depends are really more cosmetic than anything else, as we already have those in stage1 (last time I checked). -- Martin Schlemmer
signature.asc
Description: This is a digitally signed message part
