On Sat, Feb 19, 2005 at 02:47:52PM +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. Reread the glep please. Paragraph 4 of the elib section already covers the metadata reasons, beyond that I suspect you're confusing versioned eclasses with elibs.
The only comment about attempting to prevent accidental breakage is in making repoman do commit-time checks when working on elibs/eclasses, it also notes that the repoman checks for those directories would be akin to ebuilds- just simple checks to try and prevent people from commiting (fex) syntax screwups in an eclass/elib- "It won't solve developers doing dumb things with eclasses (no technological solution would, exempting a tazering)" > > 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. Re-read the glep. This isn't about preventing 'accidental breakage', this is about restructuring the beast so that people don't view eclasses as blackboxes, so that the eclass directory becomes less of a god awful mess, so that eclasses -themselves- become less of a god awful mess, and so that users at least -know- what the hell was done to an eclass/elib that lead to it's breaking (ChangeLogs). Those are the what the eclass/elib restructuring intends for future usage of eclasses/elibs. Beyond that, most of the glep actually centers around intentionally defining a cut off point for the existing eclasses, and doing a bit 'o' magic such that the compatability crap that eclasses have been required to maintain for as long as eclasses have existed, can be dropped -totally-. ~brian -- [email protected] mailing list
