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. Ah, you didn't mention caching before...
If caching is what matters, then e.g. kde-functions.eclass can't be an elib, either. It's true that merely inheriting it doesn't change metadata or ebuild functions. But most of the functions defined in it are then used (by ebuilds and by the other kde eclasses) to change metadata. Like DEPEND="$(deprange-dual a b foo)", and like need-kde(). 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. 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. -- Dan Armak Gentoo Linux developer (KDE) Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951
pgpm0ykdYt1tz.pgp
Description: PGP signature
