Re: [gentoo-dev] The fallacies of GLEP55

[Ciaran McCreesh <ciaran.mccreesh@googlemail.com>]

[-- Attachment #1: Type: text/plain, Size: 2057 bytes --]

On Sat, 16 May 2009 18:54:41 +0200
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.

>  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.

> > > My point is this: from experience I suspect having a hard change
> > > once and having easy progress on either side of it is preferable
> > > to having mid-range complications all the time.
> > 
> > .ebuild-? is not complicated.
> 
> Oh, it adds a variable portion to something that's otherwise
> static. 
>             glob        regex
> classic   *.ebuild    .*\.ebuild
>                       \.ebuild$
> 
> pms-style *.ebuild-*  .*\.ebuild-[0-9]+
>                       \.ebuild-[0-9]+$
> 
> The newer sort of extension is much more involved to get *really*
> right in patterns. Globs and regexen are only the two most
> popular examples.

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.

> > The only way it'll be "in the next ten years" rather than "in the
> > next two years" is if Gentoo continues its current approach of
> > making changes require every single person to agree...
> 
> 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.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]