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.
> 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. -- 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
pgpL6LPkAbMN9.pgp
Description: PGP signature
