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, 03:30 PM
Zac Medico
 
Default RFD: EAPI specification in ebuilds

On 03/08/2012 01:42 AM, Marc Schiffbauer wrote:

* Ulrich Mueller schrieb am 08.03.12 um 08:27 Uhr:

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.


Given that ebuilds already have to conform to a vast number of
constraints that ordinary bash scripts do not. I think that it's
perfectly reasonable for ebuilds to have a constrained syntax for EAPI
assignments.

--
Thanks,
Zac
 
Old 03-08-2012, 03:35 PM
Ciaran McCreesh
 
Default RFD: EAPI specification in ebuilds

On Thu, 08 Mar 2012 08:30:57 -0800
Zac Medico <zmedico@gentoo.org> wrote:
> On 03/08/2012 01:42 AM, Marc Schiffbauer wrote:
> > * Ulrich Mueller schrieb am 08.03.12 um 08:27 Uhr:
> >> 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.
>
> Given that ebuilds already have to conform to a vast number of
> constraints that ordinary bash scripts do not. I think that it's
> perfectly reasonable for ebuilds to have a constrained syntax for
> EAPI assignments.

...and only EAPI assignments? Not for any other metadata variable?

Doesn't that sort of suggest that EAPI shouldn't be a metadata variable?

--
Ciaran McCreesh
 
Old 03-08-2012, 03:47 PM
Mike Gilbert
 
Default RFD: EAPI specification in ebuilds

On Wed, Mar 7, 2012 at 3:41 PM, Ulrich Mueller <ulm@gentoo.org> wrote:
> Again, the proposal comes in two variants:
> 2a) It is combined with a one time change of the file extension, like
> * *.ebuild -> .eb.
> 2b) The usual EAPI assignment statement in the ebuild is still
> * *required, at least for a transition period.
>

Just throwing my opinion in:

I like proposal 2 better than proposal 1. Placing a regex-based
constraint on a bash variable assignment doesn't feel right to me.

I slightly prefer 2a over 2b because it feels cleaner. I'm sure it
will break some tools, but I don't have a good feel for the scope of
that breakage.
 
Old 03-08-2012, 03:50 PM
Zac Medico
 
Default RFD: EAPI specification in ebuilds

On 03/08/2012 08:29 AM, Ciaran McCreesh wrote:

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:


Yeah, I think they're reasonably/roughly equivalent for how we use them
in the current context.



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?


Yes, with the stipulation that we implement a sanity check / feedback
mechanism which guarantees that the probed EAPI is identical with the
result obtained from bash [1].


[1] https://bugs.gentoo.org/show_bug.cgi?id=402167#c18
--
Thanks,
Zac
 
Old 03-08-2012, 03:51 PM
Ulrich Mueller
 
Default RFD: EAPI specification in ebuilds

>>>>> On Thu, 08 Mar 2012, Michael Orlitzky wrote:

> 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

Looks like complete overkill to me, considering the simple task at
hand.

Ulrich
 
Old 03-08-2012, 03:59 PM
Alexandre Rostovtsev
 
Default RFD: EAPI specification in ebuilds

On Thu, 2012-03-08 at 16:29 +0000, Ciaran McCreesh wrote:
> 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?

In light of the fact that all 29758 ebuilds in portage already satisfy
the proposed whitespace, quoting, and indenting constrains on EAPI
assignment, the probability of problems appears to be vanishingly small.
And "vanishingly small" and can be reduced to zero by simply adding a
check to repoman.

Can you come up with a sane scenario under which an ebuild writer would
want to use a different syntax for setting EAPI?

-Alexandre
 
Old 03-08-2012, 04:03 PM
Rich Freeman
 
Default RFD: EAPI specification in ebuilds

On Thu, Mar 8, 2012 at 11:51 AM, Ulrich Mueller <ulm@gentoo.org> wrote:
>>>>>> On Thu, 08 Mar 2012, Michael Orlitzky wrote:
>
>> There's also libbash now:
>
> Looks like complete overkill to me, considering the simple task at
> hand.
>

Plus, wasn't the whole point that we can't guarantee that the bash
installed on a user's system can parse the ebuild until we've checked
the EAPI? If we use libbash doesn't that just keep the same
constraint but on a different package? Is the current stable libbash
guaranteed to be able to parse a bash v12 script?

If you just parse the file with a defined set of rules without regard
to how bash might parse the file, then you can determine the EAPI and
then decide how to source it. For all we know EAPI G will turn
ebuilds into python scripts so trying to read the thing with bash or
libbash will be doomed to failure.

Rich
 
Old 03-08-2012, 04:03 PM
Ciaran McCreesh
 
Default RFD: EAPI specification in ebuilds

On Thu, 08 Mar 2012 11:59:33 -0500
Alexandre Rostovtsev <tetromino@gentoo.org> wrote:
> On Thu, 2012-03-08 at 16:29 +0000, Ciaran McCreesh wrote:
> > 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?
>
> In light of the fact that all 29758 ebuilds in portage already satisfy
> the proposed whitespace, quoting, and indenting constrains on EAPI
> assignment, the probability of problems appears to be vanishingly
> small. And "vanishingly small" and can be reduced to zero by simply
> adding a check to repoman.

Because they were recently changed, presumably...

https://bugs.gentoo.org/show_bug.cgi?id=402167#c36

We had this discussion the last time around too, and people were told
to assign in a particular way. As you can see, it didn't work.

--
Ciaran McCreesh
 
Old 03-08-2012, 04:07 PM
Zac Medico
 
Default RFD: EAPI specification in ebuilds

On 03/08/2012 08:35 AM, Ciaran McCreesh wrote:

On Thu, 08 Mar 2012 08:30:57 -0800
Zac Medico<zmedico@gentoo.org> wrote:

On 03/08/2012 01:42 AM, Marc Schiffbauer wrote:

* Ulrich Mueller schrieb am 08.03.12 um 08:27 Uhr:

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.


Given that ebuilds already have to conform to a vast number of
constraints that ordinary bash scripts do not. I think that it's
perfectly reasonable for ebuilds to have a constrained syntax for
EAPI assignments.


...and only EAPI assignments? Not for any other metadata variable?


It's only needed for the EAPI, since that's the only value defined by
the ebuild that we intend to use to control how the global environment
is initialized prior to sourcing of the ebuild.



Doesn't that sort of suggest that EAPI shouldn't be a metadata variable?


It's a very special metadata variable. Of course, it could also be
implemented in many different ways that do not involve bash variable
assingments. Maybe the differences between the various possible ways
truly make a difference to some people, but to me it's just
hair-splitting [1].


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

On Thu, 08 Mar 2012 09:07:18 -0800
Zac Medico <zmedico@gentoo.org> wrote:
> It's a very special metadata variable. Of course, it could also be
> implemented in many different ways that do not involve bash variable
> assingments. Maybe the differences between the various possible ways
> truly make a difference to some people, but to me it's just
> hair-splitting [1].
>
> [1] http://en.wikipedia.org/wiki/Trivial_objections

Having a different, special rule for something that looks exactly like
lots of other things that do not have that different, special rule is
hardly hair splitting. This rule would have to be documented and have
special code to carefully enforce it. That's a big deal.

Having something break because you add an unrelated comment to the top
of a file is weird.

Having something break because you indent it, where nothing else breaks
if you do the same thing, is weird.

Having something break because you make full use of bash syntax, where
nothing else breaks if you do the same thing, is weird.

There are already a whole pile of subtle traps for ebuild writers and
complications for people learning the system. We should be aiming to
reduce these, not add to them.

--
Ciaran McCreesh
 

Thread Tools




All times are GMT. The time now is 06:28 AM.

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