On 03/09/2012 07:52 AM, Ian Stakenvicius wrote:
> On 09/03/12 10:41 AM, Zac Medico wrote:
>> On 03/09/2012 07:21 AM, Michael Orlitzky wrote:
>>> The advantage that the eapi function has over a comment is that
>>> it's not magic -- it's just normal bash syntax. So we've
>>> addressed that issue at a small performance cost (we're really
>>> only sourcing the ebuild up to 'exit').
>
>> Also consider the case where a user syncs after not having updated
>> for a couple of months, and the tree contains some ebuilds with
>> EAPIs that are not supported by the currently installed package
>> manager.
>
>
> IIRC we get this already, when the EAPI isn't supported by the version
> of portage installed -- upgrading really old systems won't allow an
> emerge of python-2.7 due to a too-new EAPI, and python-2.7 is needed
> to upgrade to the newer portage.

You're talking about a very specific (unfortunate) upgrade path
breakage. We should keep the discussion focused on more generic cases
that apply to future upgrade scenarios, rather than focusing on past
breakages (though it's obvious that we should also try to avoid such
upgrade path breakages in the future).

Assuming that there is still a viable upgrade path, the package manager
needs resolve dependencies and filter ebuilds based on whether or not
their EAPI is supported. There are basically two ways to do the EAPI
filtering:

1) Access the EAPI from the metadata cache. This assumes that the
package manager is able to validate metadata cache entries for EAPIs
that it does not support, which is a somewhat fragile assumption given
the complexities of cache validation, which involves verification of
ebuilds and additional sources of metadata which may include eclasses
and possibly other files in the future.

2) Parse the ebuild from the ebuild using a pre-defined protocol (parse
EAPI assignment, parse comment, or parse file name as in GLEP 55...).

> I don't see how the EAPI check itself failing and thereby excluding an
> ebuild is much different than the specified EAPI excluding it..?
> Either way, the end user is going to have issues if they don't keep
> their portage up to date.

They may or may not have issues. Our goal is to minimize our
vulnerability to these kinds of issues as much as possible. Being able
to obtain the ebuild EAPI without the expense of sourcing it is one
small step toward this goal.
--
Thanks,
Zac

On Fri, 09 Mar 2012 00:35:14 -0500
Michael Orlitzky <michael@orlitzky.com> wrote:

> On 03/09/2012 12:04 AM, Michał Górny wrote:
> >>
> >> This is of course isomorphic to requiring a specific EAPI=4 format,
> >> but does allow you to do stupid things like x=`seq 4 4`; eapi $x;
> >> if you want.
> >
> > What advantage does it give us? We still can't change ebuild syntax
> > in global scope because bash will barf.
> >
>
> Not in EAPI=5, no, but once all PMs are using the eapi function we
> could.
>
> The function can do any crazy thing you want. Right now, we need to
> source the entire ebuild to get at its environment. Before we source
> it for real, we just want to know the value of $EAPI. Since eapi()
> will be the first function called, it can be our interface to this
> variable.

What if bash starts to parse the script completely and barfs at 'syntax
error' before it starts executing stuff?

--
Best regards,
Michał Górny

On Fri, Mar 09, 2012 at 08:15:11AM -0800, Zac Medico wrote:
> They may or may not have issues. Our goal is to minimize our
> vulnerability to these kinds of issues as much as possible. Being able
> to obtain the ebuild EAPI without the expense of sourcing it is one
> small step toward this goal.

EAPI is metadata and is best treated as such. In other words, history
aside, it does not belong inside an ebuild. Making EAPI info part of
the filename does look like a reasonable solution - similar to
seen/replied flags in the filenames in maildir directories. Heck, even
version numbers in an ebuild filename is similar.

I don't understand why there is a strong objection to it.

But anyway, it is Friday night and I am out of here. Have fun.

--
Eray Aslan <eras@gentoo.org>

On 03/09/2012 08:33 AM, Eray Aslan wrote:
> On Fri, Mar 09, 2012 at 08:15:11AM -0800, Zac Medico wrote:
>> They may or may not have issues. Our goal is to minimize our
>> vulnerability to these kinds of issues as much as possible. Being able
>> to obtain the ebuild EAPI without the expense of sourcing it is one
>> small step toward this goal.
>
> EAPI is metadata and is best treated as such. In other words, history
> aside, it does not belong inside an ebuild. Making EAPI info part of
> the filename does look like a reasonable solution - similar to
> seen/replied flags in the filenames in maildir directories. Heck, even
> version numbers in an ebuild filename is similar.
>
> I don't understand why there is a strong objection to it.

I have a mild preference for the "parse EAPI assignment" approach,
simply because it's the least invasive. That said, ultimately it doesn't
make much difference to me whether we parse it from inside the ebuild or
from its file name. From my perspective, arguing between these
approaches boils down to hair-splitting [1].

[1] http://en.wikipedia.org/wiki/Trivial_objections
--
Thanks,
Zac

On 03/09/12 10:58, Zac Medico wrote:
> On 03/09/2012 07:51 AM, Alexis Ballier wrote:
>> On Fri, 09 Mar 2012 07:41:09 -0800
>> Zac Medico <zmedico@gentoo.org> wrote:
>>
>>> On 03/09/2012 07:21 AM, Michael Orlitzky wrote:
>>>> The advantage that the eapi function has over a comment is that
>>>> it's not magic -- it's just normal bash syntax. So we've addressed
>>>> that issue at a small performance cost (we're really only sourcing
>>>> the ebuild up to 'exit').
>>>
>>> Also consider the case where a user syncs after not having updated
>>> for a couple of months, and the tree contains some ebuilds with EAPIs
>>> that are not supported by the currently installed package manager.
>>>
>>> In this case, when resolving dependencies and filtering ebuilds based
>>> on whether or not their EAPI is supported, spawning bash once per
>>> ebuild is much more costly than the alternatives.
>>
>> isnt the whole point of the proposal to get eapi without sourcing ?
>>
>> so that we can use new bash features at local or global scope without
>> risking that people with an old bash get syntax errors trying to get
>> the eapi
>
> Right. Michael has lost sight of the goal and is moving off on a tangent.

The point was to be able to get the EAPI without crashing if the ebuild
uses newer features. If you can get the EAPI without sourcing, that
obviously accomplishes the goal. But there are other goals, too, like
not limiting the syntax of the EAPI assignment. I was just trying to
think up something that addresses them all.

In any case, yeah, it would crash and burn if someone synced his tree
with an ancient version of portage. But so would the comment solution.
If you want to fix that, we either have to rename everything (and hope
we get it right this time) or reconsider GLEP 55.

On 03/09/12 11:29, Michał Górny wrote:
>
> What if bash starts to parse the script completely and barfs at 'syntax
> error' before it starts executing stuff?
>

It doesn't parse the script completely, it executes line-by-line, so we
can bail out early.

This returns 1:

exit 1

QWE*$)@#$%IT@$KTRGV{PO#J$%$M@#$_)TVI!%K@B)$YJMV$%( ))@K#@)

On 03/09/2012 08:49 AM, Michael Orlitzky wrote:
> The point was to be able to get the EAPI without crashing if the ebuild
> uses newer features. If you can get the EAPI without sourcing, that
> obviously accomplishes the goal. But there are other goals, too, like
> not limiting the syntax of the EAPI assignment. I was just trying to
> think up something that addresses them all.

Yeah, but you compromised on what can be considered our primary goal,
which is to obtain the EAPI without sourcing the ebuild.

> In any case, yeah, it would crash and burn if someone synced his tree
> with an ancient version of portage. But so would the comment solution.

Don't forget the possibility of bash syntax extensions triggering a
syntax error [1]. The comment and bash assignment solutions are immune
to that because bash is exceedingly unlikely to break backward
compatibility in the comment and bash assignment syntax.

[1]
http://archives.gentoo.org/gentoo-dev/msg_2c1fbbb32f5bc47756303ca18055bee4.xml
--
Thanks,
Zac

>>>>> On Fri, 09 Mar 2012, Michael Orlitzky wrote:

>> What if bash starts to parse the script completely and barfs at
>> 'syntax error' before it starts executing stuff?

> It doesn't parse the script completely, it executes line-by-line, so
> we can bail out early.

How can you tell that this behaviour won't be changed in a future bash
version?

Ulrich

On 03/09/12 12:11, Ulrich Mueller wrote:
>>>>>> On Fri, 09 Mar 2012, Michael Orlitzky wrote:
>
>>> What if bash starts to parse the script completely and barfs at
>>> 'syntax error' before it starts executing stuff?
>
>> It doesn't parse the script completely, it executes line-by-line, so
>> we can bail out early.
>
> How can you tell that this behaviour won't be changed in a future bash
> version?
>

Who's to say that in the future my computer won't be made out of
delicious ice cream, eliminating the need for EAPIs entirely?

Chances are, this would break thousands of scripts, so we hope they
wouldn't do it. If it does happen, we either deal with it then, or don't
upgrade to that version of bash -- the same as we would do with any
other massive breaking change.

At any rate, I'm now convinced that we all want GLEP 55, but with a
different name.

On 03/09/2012 09:31 AM, Michael Orlitzky wrote:
> On 03/09/12 12:11, Ulrich Mueller wrote:
>>>>>>> On Fri, 09 Mar 2012, Michael Orlitzky wrote:
>>
>>>> What if bash starts to parse the script completely and barfs at
>>>> 'syntax error' before it starts executing stuff?
>>
>>> It doesn't parse the script completely, it executes line-by-line, so
>>> we can bail out early.
>>
>> How can you tell that this behaviour won't be changed in a future bash
>> version?
>>
>
> Who's to say that in the future my computer won't be made out of
> delicious ice cream, eliminating the need for EAPIs entirely?
>
> Chances are, this would break thousands of scripts, so we hope they
> wouldn't do it. If it does happen, we either deal with it then, or don't
> upgrade to that version of bash -- the same as we would do with any
> other massive breaking change.

Ulrich is talking about extensions which require a newer version of
bash. These kinds of extensions are quite common and don't cause
"massive breaking" because people simply have to upgrade bash in order
to use the new extensions, and their old scripts continue to run because
the new extensions don't interfere with backward compatibility.

Your eapi() function proposal is especially fragile in this context
because it assumes that the installed version of bash will be able to
execute a script that may target a newer version of bash. This is a
special case that is typically not a problem, although it is a major
problem under the specific conditions that your eapi() function approach
induces.

Anyway, lets focus on our main goal, which is to decide on a way to
obtain the EAPI _without_ sourcing the ebuild.
--
Thanks,
Zac