On Saturday 22 January 2005 22:16 CET Chris Gianelloni wrote:
> 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.
Come around and I'll give you some. It's indeed 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. [...]
No, I won't excuse you but quote your sentence following on the one above
"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."
My whole posting was about that latter case and I doubt that you do
"extensive testing" on all versions of the ebuild which is still in the
tree. If you don't ever do interface-changing changes (including removal
of helper routines) then everything is fine. But if you ever need to do
so, you've got to create a new eclass which is more or less some kind of
versioning.
> > [...] 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. [...]
Even fundamental truths can change when time and code comes.
Cheers,
Malte
P.S.: That Reply-To address you set is a bit annoying because it breaks my
MUA's mailinglist handling.
--
[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
