On Sat, 2005-01-22 at 17:11 +0000, Ciaran McCreesh wrote: > | Somebody noted that eclasses are like libs and must stay "binary > | compatible" (as far as one can say that with a bunch of bash > | functions) to the old versions. > > No, only to whatever's in the tree at the current time.
Exactly. Also consider this example. You have a function, let's call it games_make_wrapper. This function accepts four arguments: name, binary to run, directory to chdir to, and extra LD_LIBRARY_PATH to load. Now, provided that the function named games_make_wrapper always accepts these same options and produces the same output, what does it matter if the internals of the function are completely re-written? The functionality is the same and the end result is the same, so 100% compatibility exists. Now, consider the addition of a 5th optional parameter to this function. Since it is optional, it would not affect *any* of the ebuilds that call the function using only 4 parameters, but would act differently for ebuilds that use the 5th option. Under Daniel's proposal, I would have been required to make a new eclass version for this and would have to start inheriting the new eclass when it serves no purpose. This should be true with *every* function in *every* eclass. If the function's compatibility is broken, then every ebuild that uses the functionality needs to be touched or a new eclass needs to be written for the new function. At no point is a "version bump" required to get this functionality. -- Chris Gianelloni Release Engineering - Operations/QA Manager Games - Developer Gentoo Linux
signature.asc
Description: This is a digitally signed message part
