Re: [gentoo-dev] The fallacies of GLEP55

[Tobias Klausmann <klausman@gentoo.org>]

Hi! 

On Sat, 16 May 2009, Ciaran McCreesh wrote:
> Tobias Klausmann <klausman@gentoo.org> wrote:
> > > Why? What's the big deal with .ebuild-? or .eapi-?.eb instead
> > > of .ebuild?
> > 
> > One that you illustrate yourself: what aboud .eapi-11.eb or
> > .ebuild-11?
> 
> Then you include those in your static list not using patterns that
> deals with them.

I'm unable to parse this sentence. 

> >  What if you want to be able to choos EAPI names more
> > freely?
> 
> Not a problem. We used .kdebuild-1 rather than .ebuild-kdebuild-1 for
> kdebuild, for example.

Which makes the whole thing more obscure. Are those templates for
proper Ebuilds? Or maybe something KDE invented and accidentally
chose a strange name for? The kdebuild example is of limited use:
very few people outside the original project ever got in contact
with it. That does not hold true for good ol' ebuilds. As such,
the confusiong by the ever-mutation file extension would be much
broader if we did that to the classic portage tree and overlays.

> You shouldn't be writing anything that even tries to look at any EAPI
> you don't support. You should be using a static list of file
> extensions, not a pattern.

Not every piece of code dealing with ebuilds does care about EAPI
/at all/. And it needn't. There is just no way I can do this with
your proposal:

	find /usr/local/portage -iname foobar\*ebuild -print

Or it won't be as easy, at least.

> > There is such a things as too much change too quickly. And even
> > if we take that 2 years number: do *you* know what changes we
> > might need in two years? I suspect not. Neither do I (or just
> > about anybody else). I just think the hoops we have to jump
> > through now to tackle hypothetical problems in two (or ten) years
> > aren't worth it. 
> 
> That's my point -- I don't pretend to know what we'll need in the
> future, so I don't advocate a solution that requires that we do know.

And I don't pretend that I know a way to ensure that the change
will be easy. So I advocate *not* going out of our way to comfort
that possible Mother of All Changes.

Don't get me wrong: I don't want to build format dead-ends into
the package manager design specs, either. But I think the amount
of work and hassle you want to pour into avoiding it outweighs
the benefits, however speculative they may be.

Regards,
Tobias

-- 
Found on a small utility knife in MIT's lab supply:
"Caution.  Blade is sharp.  Keep out of children."