On Friday 21 January 2005 05:25, Daniel Goller wrote: > The case for versioned eclasses > =============================== > > * We want a reproducable system. Arbitrary changes to eclasses change > the behaviour of core components and make testing and validation a lot > harder to do. With versioned eclasses every change is visible. If your > "profile" is locked, you will continue with an old eclass. If you want > new and bleeding edge, you get the new and hopefully improved eclass. > > * When an eclass upgrade causes problems it is at the moment pretty much > impossible to revert to an older versions. Should some critical eclass > not behave as expected the user should at least have some automation > beyond "Read changelog, grab file from viewcvs, copy > to /usr/portage/eclasses, hope it works".
<snip implementation ideas> Hi Daniel, From an outsiders point of view and willing to give constructive criticism; We had an equal discussion about this at the "glep 19 project group". I think that the two points you described above can be summarized in one word; predictability. To achieve predictability you also need some sort of policy. Only a technical implemention wont give any guarantees that predictability will change. But for argument sake let assume that we have versioned eclasses; From a predictability/stability point of view changing a versioned eclass without a revisioned bumping the eclass can be just as bad as having a non-versioned eclass. Same rule applies for unrevisioned bumps for changes in ebuilds. To achieve 100% predictability it's necessary to have versioned eclasses (bumped at every change) and ebuilds can only inherit a single version of an eclass. If the ebuild needs a newer version of an eclass the ebuild should be bumped as well. The problem is to realize 100% predictability the extra work you need to put in this is enormously. You/we have to ask yourself is all this extra work worth the gain? I think your points are very valid, however I think you need to settle with less then 100% predictability. If you can accept that the Gentoo developers don't have the time/mood/(other reason) to achieve 100% predictability, then I think you can also accept that the current implementation is sufficient (foobar-stable.eclasss vs foobar-unstable.eclass). -- [email protected] mailing list
