On Sat, 2005-01-22 at 17:46 +0100, Malte S. Stretz wrote: > > 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.
Hand me whatever you're smoking. It must be good. > 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. Allow me to quote myself, then. "The simple rule is that we don't commit things that will break the tree." Your immediate assumption is that we will do exactly the opposite of this. Excuse me if I think I smell something funny. If foo-1.1 required a change from the eclass, then the change would be in the ebuild itself, or a new eclass function would have been made. As I said, we actually do QA and testing on what we commit. > 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. EXACTLY! You do not *ever* break the tree with an eclass change. This has been my sole argument since the beginning of this completely worthless thread, however nobody has seemed to get it until now. > 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. Eclasses can never be removed from the tree. This is a fundamental truth of the current way things are done. No versioning will help this, but instead will just add more legacy crap in the tree that can *never* be removed. I don't want to have 85 versions of games.eclass in portage, which is how many we would have, given the cvs version of the eclass currently. Considering many of these were adding new functionality or bug fixing, this would be unacceptable. > 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. No. Because only those ebuilds would use them. Hence, zero reason to bump the eclass, as it would affect nothing else. > 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). Just one thing. "for me everything worked fine" pretty much sums it up. Thank you. -- Chris Gianelloni Release Engineering - Operations/QA Manager Games - Developer Gentoo Linux
signature.asc
Description: This is a digitally signed message part
