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-08-2012, 07:13 AM
Alec Warner
 
Default RFD: EAPI specification in ebuilds

On Wed, Mar 7, 2012 at 11:27 PM, Ulrich Mueller <ulm@gentoo.org> wrote:
>>>>>> On Wed, 7 Mar 2012, Alec Warner wrote:
>
>>> *** Proposal 1: "Parse the EAPI assignment statement" ***
>>> [...]
>
>> I don't like this idea because the sane way should be easy and
>> straightforward. Mixing a constant declaration with bash assignment
>> just confuses users who think the assignment is full bash when in
>> fact it is not.
>
>> EAPI=$(somefunc)
>> EAPI=${SOMEVAR%%-*}
>> and so forth all don't meet the regex (and would be flagged
>> invalid.) However a naive author might think they work.
>
> Such constructs also cannot be used with any of the other proposed
> solutions. And in fact, nobody is using such things in practice.
> _All_ ebuilds in the Portage tree can be successfully parsed with the
> regexp proposed.

I'm not saying they are valid EAPI syntax; but they are all valid
bash. I tend to assume all authors are as...ignorant as myself. Lets
not give them the rope to hang themselves.

>
> The obvious sanity check, i.e. comparing the EAPI obtained by parsing
> and by sourcing, could be added to repoman, which would prevent such
> non-conforming ebuilds from being committed to the tree.
>
>>> *** Proposal 2: "EAPI in header comment" ***
>>> [...]
>
>> Overloading is bad.
>
>> There is no real difference between:
>> #!/usr/bin/ebuild --eapi 5
>> # EAPI=5
>
>> The problem is that the former is also the way to specify how to
>> execute the ebuild; so unless you plan to make ebuilds executable and
>> having /usr/bin/ebuild provide the ebuild environment, using that
>> syntax is confusing to users.
>
> I agree with this point.
>
> Many file formats are identifying themselves with a magic token (as
> it is used by sys-apps/file), but it is not necessarily a shebang.
>
> Ulrich
>
 
Old 03-08-2012, 08:42 AM
Marc Schiffbauer
 
Default RFD: EAPI specification in ebuilds

* Ulrich Mueller schrieb am 08.03.12 um 08:27 Uhr:
> >>>>> On Wed, 7 Mar 2012, Alec Warner wrote:
>
> >> *** Proposal 1: "Parse the EAPI assignment statement" ***
> >> [...]
>
> > I don't like this idea because the sane way should be easy and
> > straightforward. Mixing a constant declaration with bash assignment
> > just confuses users who think the assignment is full bash when in
> > fact it is not.
>
> > EAPI=$(somefunc)
> > EAPI=${SOMEVAR%%-*}
> > and so forth all don't meet the regex (and would be flagged
> > invalid.) However a naive author might think they work.
>
> Such constructs also cannot be used with any of the other proposed
> solutions. And in fact, nobody is using such things in practice.
> _All_ ebuilds in the Portage tree can be successfully parsed with the
> regexp proposed.

Ebuilds are bash scripts. I think introducing exceptions or
constraints here is not straightforward.

I think the only relevant part whether EAPI is set correctly or not
should be the outcome of $EAPI.

I would vote for a solution in a bash comment where repoman would
have to check for its existance and equality to $EAPI.

-Marc
--
8AAC 5F46 83B4 DB70 8317 3723 296C 6CCA 35A6 4134
 
Old 03-08-2012, 11:03 AM
Michał Górny
 
Default RFD: EAPI specification in ebuilds

On Wed, 07 Mar 2012 17:14:13 -0500
Michael Orlitzky <michael@orlitzky.com> wrote:

> On 03/07/2012 03:41 PM, Ulrich Mueller wrote:
> >
> > *** Proposal 2: "EAPI in header comment" ***
> >
> > A different approach would be to specify the EAPI in a specially
> > formatted comment in the ebuild's header. No syntax has been
> > suggested yet, but I believe that the following would work as a
> > specification:
> > - The EAPI must be declared in a special comment in the first line
> > of the ebuild's header, as follows:
> > - The first line of the ebuild must contain the word "ebuild",
> > followed by whitespace, followed by the EAPI, followed by
> > end-of-line or whitespace.
> >
>
> Someone suggested using a standard shebang the last time this came
> up, and if I remember correctly it was one of the least-disagreeable
> solutions proposed. We could of course define our own custom format,
> but I think something like,
>
> #!/usr/bin/eapi5
>
> would be perfect if we could hand off the interpretation of the
> ebuild to that program. That solves the problem with new bash
> features, too, since you could point that command at a specific
> version.

And what would /usr/bin/eapi5 do? Are you suggesting misusing shebang
or making ebuilds PM-centric?

--
Best regards,
Michał Górny
 
Old 03-08-2012, 11:06 AM
Michał Górny
 
Default RFD: EAPI specification in ebuilds

On Wed, 7 Mar 2012 20:12:25 -0800
Alec Warner <antarus@gentoo.org> wrote:

> On Wed, Mar 7, 2012 at 12:41 PM, Ulrich Mueller <ulm@gentoo.org>
> wrote:
> > Hi all,
> >
> > The way how we currently specify the EAPI in ebuilds has some
> > problems. For example, there is no sane way to allow usage of
> > features of a new bash version in a new EAPI. So we are currently
> > stuck with bash 3.2. Also changes of global scope behaviour, like
> > addition of new global scope functions (similar to "inherit") are
> > not possible.
> >
> > These flaws are outlined in GLEP 55 [1]:
> > | In order to get the EAPI the package manager needs to source the
> > | ebuild, which itself needs the EAPI in the first place. Otherwise
> > it | imposes a serious limitation, namely every ebuild, using any
> > of the | future EAPIs, will have to be source'able by old package
> > managers | [...]
> >
> > The council has voted down GLEP 55 more than a year ago, but at the
> > same time requested that a solution for the mentioned issues should
> > be found. [2] However, there was no progress since then.
> >
> > The issue arose again in bug 402167 [3] where several solutions have
> > been discussed. Below, I try to summarise the possible options
> > resulting from that discussion.
> >
> >
> > *** Proposal 1: "Parse the EAPI assignment statement" ***
> >
> > This first proposal would require that the syntax of the EAPI
> > assignment statement in ebuilds matches a well defined regular
> > expression. A scan of the Portage tree shows that the statement only
> > occurs in the following variations (using EAPI 4 as example):
> >
> > * EAPI=4
> > * EAPI="4"
> > * EAPI='4'
> >
> > Sometimes this is followed by whitespace or a comment (starting with
> > a # sign). Also, with very few exceptions the EAPI assignment occurs
> > within the first few lines of the ebuild. For the vast majority of
> > ebuilds it is in line 5.
> >
> > Written in a more formal way, appropriate for a specification:
> > - Ebuilds must contain at most one EAPI assignment statement.
> > - It must occur within the first N lines of the ebuild (N=10 and
> > N=30 have been suggested).
> > - The statement must match the following regular expression
> > (extended regexp syntax):
> > *^[ ]*EAPI=(['"]?)([A-Za-z0-9._+-]*)1[ ]*(#.*)?$
> >
> > Note: The first and the third point are already fulfilled by all
> > ebuilds in the Portage tree. The second point will require very few
> > ebuilds to be changed (9 packages for N=10, or 2 packages for N=30).
> >
> > The package manager would determine the EAPI by parsing the
> > assignment with above regular expression. A sanity check would be
> > added. Citing Zac Medico in [3]: "The fact that we can compare the
> > probed EAPI to the actual EAPI variable after the ebuild is sourced
> > seems like a perfect sanity check. We could easily detect
> > inconsistencies and flag such ebuilds as invalid, providing a
> > reliable feedback mechanism to ebuild developers."
> >
> > This proposal comes in two variants:
> > 1a) The change is applied retroactively for all EAPIs.
> > 1b) It is only applied for EAPI 5 and later (which means that the
> > * *result of the EAPI parsing would be discarded for earlier EAPIs).
>
> I don't like this idea because the sane way should be easy and
> straightforward. Mixing a constant declaration with bash assignment
> just confuses users who think the assignment is full bash when in
> fact it is not.
>
> EAPI=$(somefunc)
> EAPI=${SOMEVAR%%-*}
> and so forth all don't meet the regex (and would be flagged invalid.)
> However a naive author might think they work.

And they all should be invalid due to our policies. The most important
ebuild variables like EAPI should be readable on sight, without having
to lookup random variables, functions etc.

--
Best regards,
Michał Górny
 
Old 03-08-2012, 02:27 PM
Zac Medico
 
Default RFD: EAPI specification in ebuilds

On 03/08/2012 12:13 AM, Alec Warner wrote:
> On Wed, Mar 7, 2012 at 11:27 PM, Ulrich Mueller <ulm@gentoo.org> wrote:
>> Such constructs also cannot be used with any of the other proposed
>> solutions. And in fact, nobody is using such things in practice.
>> _All_ ebuilds in the Portage tree can be successfully parsed with the
>> regexp proposed.
>
> I'm not saying they are valid EAPI syntax; but they are all valid
> bash. I tend to assume all authors are as...ignorant as myself. Lets
> not give them the rope to hang themselves.

Something like DEPEND="foo bar" is also valid bash, and yet we don't
allow that either because "foo bar" does not contain valid dependency
atoms. Also, keep in mind that we're not allowing people to "hang
themselves" with invalid EAPI assignments. We'll simply give them a
reasonable error message so that they can quickly and easily correct
their mistake.
--
Thanks,
Zac
 
Old 03-08-2012, 02:56 PM
Michael Orlitzky
 
Default RFD: EAPI specification in ebuilds

On 03/08/2012 07:03 AM, Michał Górny wrote:


Someone suggested using a standard shebang the last time this came
up, and if I remember correctly it was one of the least-disagreeable
solutions proposed. We could of course define our own custom format,
but I think something like,

#!/usr/bin/eapi5

would be perfect if we could hand off the interpretation of the
ebuild to that program. That solves the problem with new bash
features, too, since you could point that command at a specific
version.


And what would /usr/bin/eapi5 do? Are you suggesting misusing shebang
or making ebuilds PM-centric?



I was saying that I'd prefer a more-standard use of the shebang (if
possible), rather than defining our own header comment syntax. Either
way I think the second option is cleaner than regular expressions.


Right now, we're guaranteed the features of bash-3.2. I guess we
actually use whatever is executing ebuild.sh to source them. But we need
to interpret the ebuild file with something: we might as well put *that*
in the shebang, since that's what it's for.


So if we were to do this with an ebuild right now, we'd add,

#!/usr/bin/eapi4

to the header, and instead of sourcing the ebuild with whatever
ebuild.sh is using, we would run it with 'eapi4' and pass whatever we
need back and forth. Or maybe ebuild.sh would reload itself using
'eapi4'. If any of that makes sense, the PMS would just need to specify
some requirements on the shebang command.
 
Old 03-08-2012, 02:58 PM
Michael Orlitzky
 
Default RFD: EAPI specification in ebuilds

On 03/07/2012 03:41 PM, Ulrich Mueller wrote:


*** Proposal 1: "Parse the EAPI assignment statement" ***



There's also libbash now:

http://www.gentoo.org/proj/en/libbash/index.xml

Anyone know how close we are to being able to use it to parse the EAPI?
 
Old 03-08-2012, 03:11 PM
David Leverton
 
Default RFD: EAPI specification in ebuilds

On Mar 8, 2012 3:29 PM, "Zac Medico" <zmedico@gentoo.org> wrote:
> Something like DEPEND="foo bar" is also valid bash, and yet we don't
> allow that either because "foo bar" does not contain valid dependency
> atoms.

There's a bit of a difference between caring about the value of a
variable and caring about what syntax was used to assign it....
 
Old 03-08-2012, 03:21 PM
Zac Medico
 
Default RFD: EAPI specification in ebuilds

On 03/08/2012 08:11 AM, David Leverton wrote:

On Mar 8, 2012 3:29 PM, "Zac Medico"<zmedico@gentoo.org> wrote:

Something like DEPEND="foo bar" is also valid bash, and yet we don't
allow that either because "foo bar" does not contain valid dependency
atoms.


There's a bit of a difference between caring about the value of a
variable and caring about what syntax was used to assign it....


Maybe that sort of distinction truly makes a difference to some people,
but to me it just seems like hair-splitting [1].


[1] http://en.wikipedia.org/wiki/Trivial_objections
--
Thanks,
Zac
 
Old 03-08-2012, 03:29 PM
Ciaran McCreesh
 
Default RFD: EAPI specification in ebuilds

On Thu, 08 Mar 2012 08:21:53 -0800
Zac Medico <zmedico@gentoo.org> wrote:
> Maybe that sort of distinction truly makes a difference to some
> people, but to me it just seems like hair-splitting [1].

So just to get this straight, you think that the following two
restrictions are effectively equivalent?

* The variable DEPEND's value must be set according to the following
rules:

* The EAPI variable assignment must not use full bash syntax. Instead,
it must be assigned according to the following rules:

And you believe that having exactly one place inside ebuild text where
there are different whitespace, quoting and indenting rules for
something that otherwise looks exactly like any other metadata variable
isn't going to cause problems?

--
Ciaran McCreesh
 

Thread Tools




All times are GMT. The time now is 01:07 AM.

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