On Fri, Feb 18, 2005 at 05:34:19PM +0200, Dan Armak wrote: > On Thursday 17 February 2005 23:28, Paul de Vrieze wrote: > > I tend to have the feeling that this GLEP misses one important point. I > > can't see which problem it tries to solve. The rationale in the glep is > > incomplete in that the issues presented can easilly be solved by being > > smart about eclasses. Like Dan says, this does mean that sometimes new > > versions are needed. Well that's very very easy. > The GLEP doesn't merely propose this, it addresses three issues. > > The first is eclass signing. That's a real issue and it should be up to the > portage people to decide what's the best solution for them to implement. If > they want it to look like this GLEP proposes, that's ok with me. > > The second is removing the need for backward compatibility. We can live > without it, but it'd definitely be nice to have, since it doesn't impose > extra requirements on eclasses or ebuilds. I'd really enjoy cleaning up the > kde ebuilds.
Thanks for above ^^^.... been busy w/ real life, didn't have time to respond yet. > 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. Eclass's original intention, and the revised intention is to serve as basically custom ebuild templates- for kde, you just define a template that is common to the majority of your eclasses, and you now have your src_* funcs mostly taken care of. That said, eclasses inheriting other eclasses, just to get funcs is kind of backwards. As stated in the glep, if one of your kde eclasses is pulling in some other eclass because it has some nifty/neato func you want to use, why not just pull in the func w/out having the template/metadata potential changes? Another example, consider the importance of inherit order- you're pulling in multiple eclasses to get necessary funcs, but the order -absolutely- matters cause the last eclass defined, is the dominant template. Sort of, yes, an eclass may only export 2 of the 3 src_* funcs, so it's not a perfect example, but the point of having to worry when all your after is a function, still stands. Does that make the case for elib's clearer, or muddier? ~brian -- [email protected] mailing list
