On Saturday 22 January 2005 16:20 CET Chris Gianelloni wrote:
On Sat, 2005-01-22 at 01:12 -0600, Daniel Goller wrote:
do i have to meddle in an eclass to be able to point out that one version that is never constand used by many versions of ebuilds cant be a good thing? im not sure what it is you are after here
Funny. Over on the games team, we have a single eclass that we use for pretty much everything, and we haven't had problems like this. In fact, it greatly simplifies our lives, being 4 developers that maintain several hundred packages. The simple rule is that we don't commit things that will break the tree. If we are forced to make changes that could break the tree, then we change the affected packages and revision bump it after doing extensive testing.
I have not completely followed this discussion and actually don't want to get too much involved in it either. But I noticed that what you wrote above is actually an argument *for* (some kind of) versioned eclasses.
An example:
I've got that great binary only game games-foo/foobar-1.0 installed. Works great for me. Now there's a new version foobar-1.1 available and you create an ebuild for it. Very cool, but while you did so, you also did (for some reason or another) some tree-breaking change to the games.eclass. A few weeks later there's another new version foobar-1.2 for which you also create a new ebuild.
At that point I decide to upgrade from foobar-1.0 to foobar-1.2 because that one might fix that very nasty bug I encountered. But alas! after the upgrade the game is broken because beginning with foobar-1.1 the game doesn't work with my binary-only Radeon 10001 driver. Ok, no problem, foobar-1.0 is still in the tree, I can package-mask everything >1.0 and go back to that version.
But since you changed the games.eclass, the foobar-1.0.ebuild is now b0rked. And such I can't play foobar anymore. If you had created a games-r2.eclass and used that one for foobar-1.1 and later, everything would still work fine.
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. So with the current version-less concept you have no way to do *ever* tree-breaking changes to an eclass, even if you revision-bump all affected ebuilds.
OTOH is Daniel's proposal a bit overkill in my eyes. A single integer version number would be enough to circumvent the problems. All eclasses would start at version v=1 and if you really need to do a BIC change to the eclass, you bump it to v++ and use that one starting from there. BC changes don't affect the version at all. Old versions could be purged from the tree after, say, one year after the last ebuild which uses that version is gone from the tree.
you could even consider games.eclass as frozen and leave it as is, avoiding any work to change ebuilds using it
then start with games-1.eclass, should this thread lead to an accepted solution
then games-2.eclass is used for ebuilds after a change is introduced
the versioning scheme is not the problem to me, id like it finer grained as you wouldnt end up with any more or less eclasses either way but have more flexibility as to how big you think your change was
going from -1 to -2 vs going from -1.5 to -1.6 for the same change, the latter i think looks cleaner once you make a big change to switch from -1.6 to -2.0, but it is is merely an idea/ suggestion, if it comes down to the versioning scheme used as only thing keeping it from realization i would be very flexible on the scheme used for versioning, but ithought keeping thigs familiar might be better, better im wrong and eclassname-1.eclass through eclassname-99.eclass is more accepted, who knows :)
Somebody else said that he uses some special code paths in some classes to cope with certain ebuilds. Removing any of those would also be a BIC change of the eclass and required a version bump.
Ok, some much for my 2cents, as I said I don't really want to get too involved in this discussion (for me everything worked fine till now with the current concept but I rarely downgrade apps, at least not ones which rely on complicated eclasses).
Cheers, Malte
Thanks,
Daniel
signature.asc
Description: OpenPGP digital signature
