Re: [gentoo-council] Preliminary Meeting-Topics for 12 February 2009

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

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

On Fri, 20 Feb 2009 00:11:32 +0300
Peter Volkov <pva@gentoo.org> wrote:
> Filename extension is a "suffix to the name of a computer file,
> designed to show its format" (-- wikipedia). General format of
> ebuilds is bash. Putting version of bash scripts inside filename
> extension just breaks common convention people got accustomed to.

Ebuilds are written in a domain specific language that's built on top of
bash. Hence why we use .ebuild, not .bash... An EAPI can be thought of
as a version of that DSL, so it's just like .mp3.

> You don't need to parse full bash script. You just need to get
> 
> EAPI="something"
> 
> string from there. If you wish to implement new ebuild format, e.g.
> ebuilds in xml, in such a case you'll change extension on .xebuild or
> whatever suits better.

Except with current rules, the only way you can get that EAPI=something
string is to evaluate the entire ebuild inside a special environment
that already knows the EAPI up-front.

> > Another cache won't solve anything since there's no way to generate
> > that cache to begin with -- and a second level of cache would slow
> > things down, not speed them up.
> 
> I told about caching just to avoid "it's slow to get EAPI from ebuild"
> argument.

Uh. So you don't understand the metadata generation process at all then?

> That said, technically there are other solutions for this problem,
> e.g. 1) it is possible to read one line of defined format from any
> file

No it isn't. The only way to get the EAPI from an ebuild is to evaluate
it in an environment where EAPI is already known.

> 2) it is possible to make eapi inside ebuild name
> (foo-1.0-eapi2.ebuild), but not as extension. Any solution, even
> breaking compatibility solution, we could already start using if we
> had forgotten about GLEP 55 long time ago...

This is just the same as GLEP 55, except that it breaks current package
managers and is more typing. In other words, it's a bad solution.

> Putting GLEP 55 infinite number of times on council agenda makes me
> feel that this issue has something common with perpetuum mobile. At
> least I'd like similar resolution from our council as the Royal
> Academy of Sciences in Paris did in 1775. It's hard to tell anything
> new about GLEP 55 but people still don't like it, so, council,
> please, ban it forever and let something else arise.

GLEP 55 is necessary, and there *still* haven't been any legitimate
technical objections to it, nor have there been any viable alternatives
proposed.

-- 
Ciaran McCreesh

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