FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 03-19-2012, 02:21 AM
Brian Harring
 
Default RFD: EAPI specification in ebuilds

On Mon, Mar 19, 2012 at 02:36:34PM +1300, Kent Fredric wrote:
> On 19 March 2012 14:12, Steven J Long <slong@rathaus.eclipse.co.uk> wrote:
> >
> > As for non-bash ebuilds, I have always agreed with antarus that they should
> > simply use a different extension. Adding a new extension per source language
> > is a *lot* cleaner than one per EAPI.
>
> Ok: If we take this notion and enshrine it in stone:
>
> If we assume Bash 4 is a seperate language from Bash 3, as its
> syntax-backwards-incompatible, is it fair to suggest that for some
> future EAPI which require Bash 4, that the extension change to suit?
>
> ie: move from .ebuild to .ebuild4 , where '.ebuild' conveys the
> format is bash, and that '.ebuild4' is bash4 only?
>
> That way you have a forwards declaration of the syntax/file format
> required to parse the file, but no declaration of the EAPI, so you're
> not breaking encapsulation.
>
> This is breaking the direct file==eapi connection, but still
> maintaining a loose file<->eapi connection.
>
> Its /sort/ of like the "one time extension change" proposal, except
> its less 'arbitrary' than something like .eb , and it gives us the
> future option of changing the suffix again if bash 5 comes out with
> different syntax.
>
> Then we can do
>
> .ebuild = EAPI 0 - 4 & bash >= 3
> .ebuild4 = EAPI5 - 9 & bash >= 4
> .ebuild5 = EAPI10 - 15 & bash >= 5
>
> Thoughts?

This is a bad idea; it arbitrarily bleeds the bash version into the
ebuild name, still requires an EAPI mechanism w/in the actual file,
and is likely to break tools that have assumptions about extensions
(even ones sooner or later written against such a setup).

Besides; it's not bash version as much as global scope settings,
functions, etc, that are the issue.

Syntax is generally minor in comparison.
~harring
 
Old 03-24-2012, 12:24 PM
Steven J Long
 
Default RFD: EAPI specification in ebuilds

Kent Fredric wrote:
> On 19 March 2012 14:12, Steven J Long <slong@rathaus.eclipse.co.uk> wrote:
>>
>> As for non-bash ebuilds, I have always agreed with antarus that they
>> should simply use a different extension. Adding a new extension per
>> source language is a *lot* cleaner than one per EAPI.
>
> Ok: If we take this notion and enshrine it in stone:
>
> If we assume Bash 4 is a seperate language from Bash 3, as its
> syntax-backwards-incompatible, is it fair to suggest that for some
> future EAPI which require Bash 4, that the extension change to suit?
>
I don't agree that it's a separate language: a lot of work goes into keeping
BASH backward-compatible, so it's only when you use a new feature that your
script will no longer work on an older version. We dealt with the move from
bash2 to bash 3 quite well, I thought, and I don't see what's wrong with
stipulating support for a new BASH version in a new EAPI: that seems
quintessential use of the EAPI mechanism to me.

Another example would be use of extglob: as a scripting feature it needs to
be enabled before any of the functions or script using it are even parsed,
or BASH will bail with a syntax error. Specifying that it is so enabled in
an EAPI (which I believe was done a while back) allows the ebuild author to
use syntax that would otherwise fall over. Again, the EAPI mechanism works
fine, and there is no need for a different extension, even though the syntax
accepted has changed.

So we already have an example of where syntax changes, not just the
available environment, work with an EAPI inside the file, as it should be.

> ie: move from .ebuild to .ebuild4 , where '.ebuild' conveys the
> format is bash, and that '.ebuild4' is bash4 only?
>
> That way you have a forwards declaration of the syntax/file format
> required to parse the file, but no declaration of the EAPI, so you're
> not breaking encapsulation.
>
> This is breaking the direct file==eapi connection, but still
> maintaining a loose file<->eapi connection.
>
> Its /sort/ of like the "one time extension change" proposal, except
> its less 'arbitrary' than something like .eb , and it gives us the
> future option of changing the suffix again if bash 5 comes out with
> different syntax.
>
> Then we can do
>
> .ebuild = EAPI 0 - 4 & bash >= 3
> .ebuild4 = EAPI5 - 9 & bash >= 4
> .ebuild5 = EAPI10 - 15 & bash >= 5
>
> Thoughts?
>
As Brian said, you still need an EAPI mechanism, and further you've still
leaked metadata that simply doesn't need to be leaked. The only thing that
has ever held up adoption of EAPI extraction using a simple EAPI="foo"
declaration, matching tree-usage, is the fact that PMS does not specify
which characters are allowed in an EAPI name. This was asked for a couple of
years ago, iirc, and it is clearly necessary whether you scan for a token in
the ebuild, or you stick EAPI into the filename. (After all you are even
more restricted when you're talking about the filename, as opposed to a text
string given in a script.)

It just seems like a major hole in the spec, given that EAPI is so critical
to how you deal with the ebuild, and characters allowed for other tokens
such as category, package, version, keywords, USE-flags etc are specified.
It would be necessary for GLEP-55, but is not mentioned therein, which I
guess means the GLEP is under-specified as well.

.eapi-NN just strikes me as similar to having M$ Word format as .doc95
.doc2000 and the like- a complete mess. Or indeed sticking the charset
encoding (which has profound consequences when reading a file) from an HTML
file into its filename. Again, a similar, if not worse, piece of metadata--
just extracting it is hard if you don't know the charset in advance, but
I've never heard of anyone arguing that it should belong anywhere other than
in the file, from where tools dealing with it locally can extract it and,
say, emit the correct HTTP header.

What I was referring to with an extension-per-language would be something
like .pbuild for python-based build scripts, or .xbuild for your XML-
declarative example, and so on. In each case, you'd still need a supporting
infrastructure, but it's clear that you are using a completely different
setup, and it's no longer a traditional BASH-based ebuild. It would be quite
reasonable to suppose that you'd have EAPI specified there as well, since
you'd want to be able to add to and change the features you support over
time. Would you really want to change the extension each time you did,
though?

Regards,
Steve.
--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
 
Old 04-12-2012, 07:53 PM
Ulrich Mueller
 
Default RFD: EAPI specification in ebuilds

There is consensus in the gentoo-pms mailing list that we should
tighten the rules for the position of the EAPI assignment in ebuilds,
namely that it should take place in the first non-blank and
non-comment line.

The devmanual already requires that "if you want to override the EAPI
variable, you have to specify it at the top of the ebuild."

In any case, the portage tree mostly complies with this. There are 130
ebuilds in 66 packages (or 0.4 % of the total number) that don't, but
they can be trivially fixed (and I volunteer to do the work).

Any objections against this?

Ulrich
 
Old 04-12-2012, 08:19 PM
Mike Frysinger
 
Default RFD: EAPI specification in ebuilds

On Thursday 12 April 2012 15:53:07 Ulrich Mueller wrote:
> There is consensus in the gentoo-pms mailing list that we should
> tighten the rules for the position of the EAPI assignment in ebuilds,
> namely that it should take place in the first non-blank and
> non-comment line.
>
> The devmanual already requires that "if you want to override the EAPI
> variable, you have to specify it at the top of the ebuild."
>
> In any case, the portage tree mostly complies with this. There are 130
> ebuilds in 66 packages (or 0.4 % of the total number) that don't, but
> they can be trivially fixed (and I volunteer to do the work).

do it
-mike
 

Thread Tools




All times are GMT. The time now is 05:14 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org