Re: [gentoo-dev] GLEP 55

[Ciaran McCreesh]

On Mon, 09 Jun 2008 22:09:04 -0600
Joe Peterson <lavajoe@g.o> wrote:
> Ciaran McCreesh wrote:
> > And a file extension is far less obscurely complex than enforcing
> > arbitrary syntax restrictions upon ebuilds.
>
> I disagree.  One is exposed to devs only as ebuild syntax; the other
> is exposed in an inappropriate location to everyone looking at the
> portage tree.

You might as well say "We should get rid of Manifest because anyone
looking at the tree is exposed to security internals"...

> > No it can't. EAPI has to be known before the source can start. Bash
> > doesn't provide traps for executing code upon changed variables.
>
> Doing it out-of-band solve this.

Doing it out-of-band but in-the-file means the file format is fixed in
annoying ways.

> > No, it's only needed once per non-trivial change. So we might as
> > well just change it for every EAPI.
>
> Huh?  If the "new" portage knows how to determine the EAPI
> definitively (and that would be defined), it can deal with the
> differences.

Sure, until there's another format change. Then we need yet another new
extension. What will we use then? '.ebld'?

The EAPI-in-extension format is cheap. People have been using it for
character sets and languages for decades.

> > And then how do we deal with EAPI 3, where the syntax changes again?
>
> Portage (or whatever PM) reads the EAPI, determines it is 3, and goes
> from there.  If you change the way you declare EAPI each time, yeah,
> that's a problem, but I'm not sure why that would ne necessary.

But you're not sure that it's not necessary, so why impose entirely
pointless restrictions that everyone in the future has to stick by?

> > Which is way more obscure, complex and arbitrary than a file
> > extension change. And it still imposes massive restrictions upon
> > future EAPIs.
>
> Massive?  Simply a one-line EAPI declaration is not massive nor
> complex. And is more elegant than putting it in the filename.

You're suddenly imposing restrictions upon the content of comments, and
requiring a whole new parser to deal with it. The point of comments is
that they're ignored.

> > Every issue you've raised so far was already discussed and debunked
> > the first time this discussion happened. Please read the original
> > discussions before continuing.
>
> Debunked according to whom?  I believe that some, including you,
> believe you debunked them, but I do not believe there was wholesale
> agreement from the dev community.

That doesn't really matter. Most of the dev community don't care to
understand the underlying issue, so all they need to do is go along
with the informed decision that the Council was supposed to have made
on their behalf.

> > We had that discussion when the GLEP was first proposed.
>
> Yes, but nothing was decided, and agreement was not reached.  I'd be
> very surprized if I were the only one here who is not entirely
> satisfied with GLEP 55's solution to this.

Yet GLEP 55 is the only solution that's been proposed that solves the
requirements. And your entire argument boils down to "file extension
changes don't look pretty", for some arbitrary value of pretty that
also precludes index.html.en and index.html.utf-8.

-- 
Ciaran McCreesh