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.
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
--
[SGT] Simon G. Tatham: "How to Report Bugs Effectively"
<http://www.chiark.greenend.org.uk/~sgtatham/bugs.html>
[ESR] Eric S. Raymond: "How To Ask Questions The Smart Way"
<http://www.catb.org/~esr/faqs/smart-questions.html>
--
[email protected] mailing list
