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.
it comes down to everyone complying to whatever solution would be chosen (no technological is not the only way, policy can work too), this thread is intended to get input on which solution would work, not to say this is what we think it should be
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.
indeed, this way we know say foo-1.2-r3 worked with foo-1.14.1.eclass
1.14.1 wouldnt ever be changed, if it is touched it would be based on the how much was changed foo-1.14.2.eclass, foo-1.15.1.eclass or if a total rewrite even foo-2.eclass
(.1 and .2 or -r1 and -r2, this is not me wanting it that way, it is using an example only)
what you have then is that foo-1.2-r3 can rely on inheriting foo-1.14.1.eclass
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.
see above, agreed
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?
we think it is worth it, and we don't think the effort is enormous
the effort doesnt have to be big to achieve this at al, how hard is it ti bump a ebuild currently? bumping an eclass and making changes to the bumped version only would be minor compared to the gain of a user to be able to trust that emerge foo -vp greeting him with an:
[ebuild R ] sys-devel/foo-1.2-r3 -bootstrap -build -debug +fancy* 0 kB
he gets nothing more than foo with the optional feature of fancy added, not fancy + unknown change in unversioned eclass added
if fancy wasnt every used by anyone, he would be able to at least remove USE=fancy and get his working foo-1.2-r3 back, not have lost the working 1.2-r3 he had before trying to add USE=fancy
now he has no USE=fancy in his foo-1.2-r3 but also he can not go back as the eclass foo-1.2-r3 used to successfully build and work with thereafter is no longer on his system
mood, as i said an eclass bump would take less than the time it takes to make their changes for which they have time, much less time/effort actually
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).
i dont think it would be required to settle and still end up without the required predictability
what i am admitting is that my main focus was toolchain (and id love it for anything in system), since changes to those have a much farther reaching effect, but once you have something in place, be it technological (no, i'm not out for a tool one can blame for their mistakes) or policy change, why not utilize it more than just there?
for example i dont want to force people to remerge something for a small bugfix not affecting them or header or typo fixes (as it is policy now)
what i do want them to be able to do is say, my toolchain works as is and i want to keep my toolchain should remain as is, and let them decide when they change what versions of ebuilds and eclasses build their system, especially if you were to use gentoo in a production environment for example you would want to have at least predictability of your toolchain, if noone is willing to give you 100% predictability
am i that wrong to think people don't want bad surprises with their toolchain/system in particular?
as long as a change to an (unversioned) eclass can affect many versions of a package, there is no way to say i will not upgrade to -r3 of this package, because the changes were done for me in a way i can not stick to -r2, there is no -r3 cause the changes were tucked away into the eclass that i cant get back unless i go and find it via viewcvs
now imagine you have a running server, everything works well and you want to duplicate it, or much worse the hardware failed and all redundancy later are faced with remerging your system from scratch
luckily you know which version of every crucial package you had installed (your old system was running so great you havent touched it's system in months and taken care of auditing its system), you start merging, but thanks to unversioned eclasses you are getting a surprisingly poorer acting system
or worse it might not even build with the recorded versions of ebuilds any longer
that is what i want to avoid and or achieve, i want to avoid the surprise and id like to achieve the reproducable system everyone should be able to expect
i want to thank you for your input and would like to ask you to tell me if my desire to achieve this is so ill fated
thank you
Daniel
-- [email protected] mailing list
signature.asc
Description: OpenPGP digital signature
