On Saturday 22 January 2005 03:23, Daniel Goller wrote:
Michiel de Bruijne wrote:
On Friday 21 January 2005 05:25, Daniel Goller wrote:
<snip case for 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
ok, this is a little different from your original implementation idea, which suggest to support the usual operators and therefor allow ebuilds to inherit multiple versions of an eclass.
absolute inheritance is something that simply looks easiest to implement right now while guaranteeing predictability, path levels could be dealt with with said operators, it seems that such would require more policy changes than simply using absolute inheritance, that's the idea behind me favoring absolute inheritance at this point
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?
<snip confirmation that it's worth the gain and amount of work is not enormous>
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)
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
<if this is true then this can be debated until the end of time without ever coming to an general agreement>
well mood can be dealt with policies one has to abeit by, it looks though more it was mostly misunderstanding the idea behind predictability and or the misunderstanding of technical examples in my initial thread as the final solution that is causing the most problems
<snip reasons to achieve (100%) predictability>
am i that wrong to think people don't want bad surprises with their toolchain/system in particular?
Absolutly not
<snip use case scenario where predictability is desired>
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
Absolutly not
Like I said before, we have discussed this in the "GLEP 19 project group". GLEP 19 primary focus is on predictability and keeping the Gentoo security standards (GLSA). Predictability is the easy part (locking ebuilds in a profile or creating a seperate tree).
It's becoming difficult the moment we want to add GLSA's and GLSA-related ebuilds to the tree/profile and a big part of these difficulties are related to eclasses.
Let me give an example;
We have locked two ebuilds in the tree/profile (foo-1.6-r1.ebuild and bar-2.4-r3.ebuild). Both ebuilds inherit foobar.eclass.
In the current tree foo-1.8-r1.ebuild and bar-2.7-r2.ebuild are the current stable marked ebuilds. The eclass has changed as well. Both ebuilds work perfectly with the new eclass.
Then a GLSA is released for foo-1.8-r1.ebuild and foo-1.8-r2.ebuild is created.
Now what should the stable tree/profile maintainer do?
- add foo-1.8-r2.ebuild and hold the locked eclass
It's possible that foo-1.8-r2.ebuild dies in a horrible way with the old eclass
- add foo-1.8-r2.ebuild and the new eclass
It's possible that bar-2.4-r3.ebuild dies in a horrible way with the new eclass
- add foo-1.8-r2.ebuild, bar-2.7-r2.ebuild and the current eclass We have removed predictability for program bar, because foo had a GLSA
Above scenario is with two ebuilds that inherit an eclass, imagine if 20 or more ebuilds inherit an eclass.
Without some sort of versioning in eclasses maintaining the stable tree/locked profile will be a difficult and time consuming task.
which is why we would like to have versioned eclasses that are not used on such a large amount of ebuilds and one change of the single eclass breaks them all, or rather, can be used on 50 versions of ebuilds as long as they dont change, if a change is required for the 51st, bump it, do not affect any of the 50 inheriting the working one (numbers used are excessive for illustration)
-- gentoo-dev@gentoo.org mailing list
signature.asc
Description: OpenPGP digital signature
