On Sat, 22 Jan 2005 17:46:18 +0100 "Malte S. Stretz"
<[EMAIL PROTECTED]> wrote:
| 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.
Your entire argument is flawed based upon the "tree-breaking change" thing. We don't commit tree-breaking changes to eclasses any more than we do to ebuilds.
you know it happens, and w/o versioned eclasses there is no way back for the user
so dont pretend we are all flawless superhuman AIs
just cause you are doing flawless testing, doesnt mean we shouldnt keep an easy way open to revert eclasses or allow locking down of a setup for users
| 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.
No, only to whatever's in the tree at the current time.
signature.asc
Description: OpenPGP digital signature
