> On Sun, 18 Mar 2012, Ralph Sennhauser wrote:
> If we want to keep .ebuild but avoid the compat issue another
> variant would be "EAPI in header comment and one-time change of
> ebuild location" or more formal:
> 6 EAPI in header comment and one-time change of ebuild location:
> - add a dir
On Sun, Mar 18, 2012 at 3:23 AM, Ralph Sennhauser wrote:
> The ebuild extensions for GLEP 55
> would likely always be ebuild- as integers are reserved for
> future use by Gentoo.
Looking at GLEP 55 the proposal was ebuild- - not
ebuild-. I don't believe there is any restriction that EAPIs
be int
On Wed, 7 Mar 2012 21:41:02 +0100
Ulrich Mueller 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 chan
On 03/13/2012 07:01 PM, Brian Harring wrote:
> With respect; you're proposing we go gum up version parsing via
> shoving EAPI directly into it. Literally, make what is already a
> complex mess, worse. Apply some KISS to your proposal please. ;)
>
> Just hammering the point home; compatibility
On Mon, Mar 12, 2012 at 09:05:26AM -0700, Zac Medico wrote:
> On 03/12/2012 01:36 AM, Brian Harring wrote:
> > On Sun, Mar 11, 2012 at 09:08:24PM -0700, Zac Medico wrote:
> >> 1) User downloads an overlay that doesn't provide cache. We want the
> >> package manager to give a pretty "EAPI unsupporte
On Mon, Mar 12, 2012 at 1:46 PM, Zac Medico wrote:
> If we want to handle every possible screwup, including stray EAPI
> assignments inside inherited eclasses, we still need to compare the
> probed value to the value that's obtained from bash.
Well, I wasn't intending to suggest that the repoman
On 03/12/2012 10:30 AM, Rich Freeman wrote:
> On Mon, Mar 12, 2012 at 1:01 PM, Zac Medico wrote:
>> It would be very fragile without the sanity check / feedback mechanism
>> that's already been suggested.
>
> Another obvious check is to have repoman run a grep with the regexp
> and give an error
On Mon, Mar 12, 2012 at 1:01 PM, Zac Medico wrote:
> It would be very fragile without the sanity check / feedback mechanism
> that's already been suggested.
Another obvious check is to have repoman run a grep with the regexp
and give an error if there is not exactly one match.
Rich
On 03/12/2012 02:16 AM, Kent Fredric wrote:
> I just find a top-down regexp solution dangerously naive, as its
> infering that the first line that matches the regexp *is* the EAPI
> requirement field, when depending on the actual format used, that may
> not be the case.
>
> If for example, a forma
On 03/12/2012 09:12 AM, Ciaran McCreesh wrote:
> On Mon, 12 Mar 2012 09:05:26 -0700
> Zac Medico wrote:
>> It's just a symptom of people not abiding by the KISS principle.
>
> "Abiding by the KISS principle" is what got us into this mess in the
> first place. EAPI as a metadata variable is too si
On Mon, 12 Mar 2012 09:05:26 -0700
Zac Medico wrote:
> It's just a symptom of people not abiding by the KISS principle.
"Abiding by the KISS principle" is what got us into this mess in the
first place. EAPI as a metadata variable is too simple to allow us to
do what we want to do.
--
Ciaran McC
On 03/12/2012 01:36 AM, Brian Harring wrote:
> On Sun, Mar 11, 2012 at 09:08:24PM -0700, Zac Medico wrote:
>> 1) User downloads an overlay that doesn't provide cache. We want the
>> package manager to give a pretty "EAPI unsupported" message, rather than
>> spit out some bash syntax errors.
>
> Th
On Mon, 12 Mar 2012 01:36:12 -0700
Brian Harring wrote:
> Also note that with the sole exception of g55
...
> and does so at the same robustness as everything sans g55
...
> G55 is the sole exception.
Interesting pattern, huh?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Mon, Mar 12, 2012 at 6:12 AM, Kent Fredric wrote:
>
> There's the obvious case of compiled-binaries where that might not be
> possible, but thats definately strawman stuff and I wouldn't support
> that sort of nonsense anyway. Compiled binaries for ebuilds can gtfo.
>
Why do I feel like a simi
On 12 March 2012 22:48, Ulrich Mueller wrote:
>> On Mon, 12 Mar 2012, Kent Fredric wrote:
> There's little danger if we require the EAPI specification to be in
> the first line of the ebuild. Of course the regexp should be general
> enough to account for a non-bash comment syntax.
>
There's t
> On Mon, 12 Mar 2012, Kent Fredric wrote:
> I just find a top-down regexp solution dangerously naive, as its
> infering that the first line that matches the regexp *is* the EAPI
> requirement field, when depending on the actual format used, that
> may not be the case.
There's little danger i
On 12 March 2012 22:09, Michał Górny wrote:
>> or as .
>
> No, definitely not. That's not the XML style.
Sure, but these examples are just examples after all. And XML is only
being used for an example use case, but there are many more
structured formats than XML.
Some of us are mostly just wor
On Mon, 12 Mar 2012 21:39:52 +1300
Kent Fredric wrote:
> On 12 March 2012 21:27, Michał Górny wrote:
> > And we could just use a good regex for that instead.
> >
> > Something like: [eE][aA][pP][iI] [a-z0-9-+]+
> >
> > and just require users for this to be the first thing declared in
> > an ebu
On Mon, 12 Mar 2012 08:30:19 +
Ciaran McCreesh wrote:
> On Mon, 12 Mar 2012 09:27:11 +0100
> Michał Górny wrote:
> > 15-xml
> >
> > and
> >
> > - eapi: 15-yaml
>
> You're carefully concocting your examples to make it look like it
> should work.
Or I am just printing the first thing that
On 12 March 2012 21:27, Michał Górny wrote:
> And we could just use a good regex for that instead.
>
> Something like: [eE][aA][pP][iI] [a-z0-9-+]+
>
> and just require users for this to be the first thing declared in
> an ebuild. Of course, this could make problems with stuff like:
>
> # EAPI 4
On Sun, Mar 11, 2012 at 09:08:24PM -0700, Zac Medico wrote:
> On 03/11/2012 06:55 PM, Brian Harring wrote:
> > On Sat, Mar 10, 2012 at 08:06:50AM -0800, Zac Medico wrote:
> >> Yeah. Another way of putting it is that the requirement to spawn a bash
> >> process and source the ebuild adds a ridiculou
On Mon, 12 Mar 2012 09:27:11 +0100
Michał Górny wrote:
> 15-xml
>
> and
>
> - eapi: 15-yaml
You're carefully concocting your examples to make it look like it
should work. If you go the XML route, though, the EAPI would either be
in a DTD or as .
Part of the point of all of this is that we shou
On Mon, 12 Mar 2012 00:08:46 -0700
Zac Medico wrote:
> On 03/11/2012 11:50 PM, Kent Fredric wrote:
> > #!/usr/bin/env eapi-xml-5
> >
> > would send the current file ( foo.ebuild ) to the process
> > "eapi-xml-5" ( as defined by the current $PATH setting )
>
> All we need is a way for the packag
On 12 March 2012 20:08, Zac Medico wrote:
> On 03/11/2012 11:50 PM, Kent Fredric wrote:
>> #!/usr/bin/env eapi-xml-5
>>
>> would send the current file ( foo.ebuild ) to the process "eapi-xml-5"
>> ( as defined by the current $PATH setting )
>
> All we need is a way for the package manager to probe
On 03/11/2012 11:50 PM, Kent Fredric wrote:
> #!/usr/bin/env eapi-xml-5
>
> would send the current file ( foo.ebuild ) to the process "eapi-xml-5"
> ( as defined by the current $PATH setting )
All we need is a way for the package manager to probe the EAPI. Spawning
a process to do that is just ov
On 12 March 2012 15:24, Alec Warner wrote:
> I will stab the next person who suggests 'xml-like ebuilds.'
State-fully coded ebuilds, while perhaps not to your liking, for some
code-types can be incredibly useful.
For example, 9/10 perl-module ebuilds don't need any code at all in
the ebuild its
On 12 March 2012 15:20, Rich Freeman wrote:
> On Sun, Mar 11, 2012 at 10:03 PM, Brian Harring wrote:
>> Pragmatic reality, the eapi function actually would work fine. As
>> pointed out elsewhere, bash parses as it goes- which isn't going to
>> change.
>
> Unless the ebuild isn't written in bash.
On 03/11/2012 06:55 PM, Brian Harring wrote:
> On Sat, Mar 10, 2012 at 08:06:50AM -0800, Zac Medico wrote:
>> Yeah. Another way of putting it is that the requirement to spawn a bash
>> process and source the ebuild adds a ridiculous amount of unnecessary
>> complexity, in violation of the KISS prin
On 03/11/2012 07:03 PM, Brian Harring wrote:
> Pragmatic reality, the eapi function actually would work fine. As
> pointed out elsewhere, bash parses as it goes- which isn't going to
> change.
>
> If someone invokes 'eapi happy-meal' and it's not supported,
> the sourcing is stopped immediatel
On Sun, Mar 11, 2012 at 7:20 PM, Rich Freeman wrote:
> On Sun, Mar 11, 2012 at 10:03 PM, Brian Harring wrote:
>> Pragmatic reality, the eapi function actually would work fine. As
>> pointed out elsewhere, bash parses as it goes- which isn't going to
>> change.
>
> Unless the ebuild isn't written
On Sun, Mar 11, 2012 at 10:03 PM, Brian Harring wrote:
> Pragmatic reality, the eapi function actually would work fine. As
> pointed out elsewhere, bash parses as it goes- which isn't going to
> change.
Unless the ebuild isn't written in bash...
How do you source the ebuild if you don't know wh
On Fri, Mar 09, 2012 at 09:47:50AM -0800, Zac Medico wrote:
> 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
> 'synta
On Sat, Mar 10, 2012 at 08:06:50AM -0800, Zac Medico wrote:
> On 03/09/2012 11:20 AM, Ciaran McCreesh wrote:
> > On Fri, 09 Mar 2012 11:49:44 -0500
> > Michael Orlitzky wrote:
> isnt the whole point of the proposal to get eapi without sourcing ?
>
> so that we can use new bash featu
On Fri, Mar 09, 2012 at 06:52:40PM +0100, Micha?? G??rny wrote:
> On Fri, 09 Mar 2012 12:31:24 -0500
> 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 a
On 03/09/2012 11:20 AM, Ciaran McCreesh wrote:
> On Fri, 09 Mar 2012 11:49:44 -0500
> Michael Orlitzky wrote:
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 ol
On Sat, 10 Mar 2012 14:06:49 +1300
Kent Fredric wrote:
> > HOMEPAGE Package's homepage. If you are unable to locate an
> > official one, try to provide a link to freshmeat.net or a similar
> > package tracking site. Never refer to a variable name in the string;
> > include only raw text.
>
On 9 March 2012 06:30, Jeroen Roovers wrote:
> On Thu, 8 Mar 2012 17:14:58 +
> Ciaran McCreesh wrote:
>
>> 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
On 03/09/12 13:56, Zac Medico wrote:
> On 03/09/2012 10:33 AM, Michael Orlitzky wrote:
>> On 03/09/12 13:02, James Broadhead wrote:
>>> On 9 March 2012 17:31, Michael Orlitzky wrote:
At any rate, I'm now convinced that we all want GLEP 55, but with a
different name.
>>>
>>> I think that
On Fri, 09 Mar 2012 10:56:03 -0800
Zac Medico wrote:
> Every software product has an end of life. I think if a system hasn't
> been updated in the last 2 years or so, then it's fair to assume that
> it will never be updated. So, all relevant versions of portage should
> simply show a warning messa
On Fri, 09 Mar 2012 11:49:44 -0500
Michael Orlitzky wrote:
> >> 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 eap
On Fri, Mar 9, 2012 at 12:47 PM, Zac Medico wrote:
> Anyway, lets focus on our main goal, which is to decide on a way to
> obtain the EAPI _without_ sourcing the ebuild.
Agreed. Plus, an approach that either uses the filename or something
like a comment line is also going to be much more flexibl
On 03/09/2012 10:33 AM, Michael Orlitzky wrote:
> On 03/09/12 13:02, James Broadhead wrote:
>> On 9 March 2012 17:31, Michael Orlitzky wrote:
>>> At any rate, I'm now convinced that we all want GLEP 55, but with a
>>> different name.
>>
>> I think that moving the data to the filename is probably a
On 03/09/12 13:02, James Broadhead wrote:
> On 9 March 2012 17:31, Michael Orlitzky wrote:
>> At any rate, I'm now convinced that we all want GLEP 55, but with a
>> different name.
>
> I think that moving the data to the filename is probably a better
> approach than semi- or repeat parsing, but I
On 03/09/2012 10:24 AM, Alexis Ballier wrote:
> On Fri, 9 Mar 2012 18:02:51 +
> James Broadhead wrote:
>
>> On 9 March 2012 17:31, Michael Orlitzky wrote:
>>> At any rate, I'm now convinced that we all want GLEP 55, but with a
>>> different name.
>>
>> I think that moving the data to the fil
On Fri, 9 Mar 2012 18:02:51 +
James Broadhead wrote:
> On 9 March 2012 17:31, Michael Orlitzky wrote:
> > At any rate, I'm now convinced that we all want GLEP 55, but with a
> > different name.
>
> I think that moving the data to the filename is probably a better
> approach than semi- or re
On 03/09/12 12:47, Zac Medico wrote:
>
> 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 script
On 9 March 2012 17:31, Michael Orlitzky wrote:
> At any rate, I'm now convinced that we all want GLEP 55, but with a
> different name.
I think that moving the data to the filename is probably a better
approach than semi- or repeat parsing, but I prefer preserving the
.ebuild extension, and think
On Fri, 09 Mar 2012 12:31:24 -0500
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?
> >
> >> I
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 s
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 c
> 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 beh
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 EA
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@$
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 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 ju
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 sourc
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.
E
On Fri, 09 Mar 2012 00:35:14 -0500
Michael Orlitzky 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 do
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
On 03/09/2012 07:51 AM, Alexis Ballier wrote:
> On Fri, 09 Mar 2012 07:41:09 -0800
> 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
>>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
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 smal
On Fri, 09 Mar 2012 07:41:09 -0800
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 reall
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
On 03/09/12 10:05, Zac Medico wrote:
>>
>> Surely we can source one or two lines of the ebuild safely, like the
>> example shows?
>
> Why would we though, when sourcing is a relatively costly operation, and
> there are much more efficient ways to get the EAPI?
There do not seem to be any that peo
On 03/09/2012 06:42 AM, Michael Orlitzky wrote:
> On 03/09/12 00:51, Zac Medico wrote:
>> On 03/08/2012 09:35 PM, Michael Orlitzky wrote:
>>> The function can do any crazy thing you want.
>>
>> We don't need a function. We need to know the EAPI before we source the
>> ebuild, and a function doesn't
On 03/09/12 00:51, Zac Medico wrote:
> On 03/08/2012 09:35 PM, Michael Orlitzky wrote:
>> The function can do any crazy thing you want.
>
> We don't need a function. We need to know the EAPI before we source the
> ebuild, and a function doesn't give us that.
Surely we can source one or two lines
* Zac Medico schrieb am 08.03.12 um 17:30 Uhr:
> 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.
> >>
On 03/08/2012 09:35 PM, Michael Orlitzky wrote:
> The function can do any crazy thing you want.
We don't need a function. We need to know the EAPI before we source the
ebuild, and a function doesn't give us that.
--
Thanks,
Zac
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 b
On Thu, 08 Mar 2012 16:35:14 -0500
Michael Orlitzky wrote:
> On 03/08/2012 01:48 PM, Ciaran McCreesh wrote:
> >
> >> If they're code, they're code, and we need to execute them somehow.
> >
> > The notion of "execute them somehow" that's used doesn't fit in with
> > the #! interpreter model. You a
On Wed, Mar 07, 2012 at 09:41:02PM +0100, Ulrich Mueller wrote
> 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
On Thu, Mar 8, 2012 at 1:35 PM, Michael Orlitzky wrote:
> On 03/08/2012 01:48 PM, Ciaran McCreesh wrote:
>>
>>
>>> If they're code, they're code, and we need to execute them somehow.
>>
>>
>> The notion of "execute them somehow" that's used doesn't fit in with
>> the #! interpreter model. You aren
On 03/08/2012 01:48 PM, Ciaran McCreesh wrote:
If they're code, they're code, and we need to execute them somehow.
The notion of "execute them somehow" that's used doesn't fit in with
the #! interpreter model. You aren't executing ebuilds via an
interpreter. You're performing an action that i
On Thu, 8 Mar 2012 19:31:16 +
Ciaran McCreesh wrote:
> On Thu, 8 Mar 2012 20:17:41 +0100
> Ulrich Mueller wrote:
> > In one of them, removal of the old assignment statement had simply
> > been forgotten [1]. For the other two, the EAPI had been assigned by
> > an eclass [2], which we conside
On Thu, 8 Mar 2012 20:04:55 +0100
Ulrich Mueller wrote:
> > Err... so what happens if 'new parsing' detects EAPI 4 and 'old
> > parsing' detects EAPI 5?
>
> This cannot happen for a legal ebuild:
> - If the ebuild is EAPI 4, then sourcing it ("old parsing") must
> detect EAPI 4.
the problem he
On Thu, 8 Mar 2012 20:17:41 +0100
Ulrich Mueller wrote:
> In one of them, removal of the old assignment statement had simply
> been forgotten [1]. For the other two, the EAPI had been assigned by
> an eclass [2], which we consider illegal anyway.
...and yet people do it. That and the violations o
> On Thu, 8 Mar 2012, Ciaran McCreesh wrote:
> On Thu, 08 Mar 2012 11:59:33 -0500
> Alexandre Rostovtsev wrote:
>> 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 pro
> On Thu, 8 Mar 2012, Michał Górny wrote:
>> *** Proposal 1: "Parse the EAPI assignment statement" ***
>>
>> [...]
>>
>> 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
On Thu, 08 Mar 2012 13:37:09 -0500
Michael Orlitzky wrote:
> > It probably should. Although in the early days the model for ebuilds
> > was that they were scripts that were "executed", nowadays there's so
> > much support required that it's better to think of ebuilds as being
> > data. If you did
On 03/08/2012 12:53 PM, Ciaran McCreesh wrote:
On Thu, 08 Mar 2012 12:48:51 -0500
Michael Orlitzky wrote:
On 03/08/2012 12:28 PM, Michał Górny wrote:
And something will need to provide that /usr/bin/eapi4 thing. And
that introduces new problems:
I'm just parroting someone else's suggestion;
On 03/08/2012 09:52 AM, Michał Górny wrote:
On Wed, 7 Mar 2012 21:41:02 +0100
Ulrich Mueller wrote:
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).
Err... so what happens if 'new parsing' detects EAPI 4 a
On Thu, 8 Mar 2012 18:52:13 +0100
Michał Górny wrote:
> > Again, the proposal comes in two variants:
> > 2a) It is combined with a one time change of the file extension,
> > like .ebuild -> .eb.
>
> And we're going to retroactively migrate the tree or have random file
> suffixes intermixed? Not t
On Thu, 08 Mar 2012 12:48:51 -0500
Michael Orlitzky wrote:
> On 03/08/2012 12:28 PM, Michał Górny wrote:
> > And something will need to provide that /usr/bin/eapi4 thing. And
> > that introduces new problems:
>
> I'm just parroting someone else's suggestion; I don't really know
> enough about the
On Wed, 7 Mar 2012 21:41:02 +0100
Ulrich Mueller wrote:
> *** Proposal 1: "Parse the EAPI assignment statement" ***
>
> [...]
>
> 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 li
On 03/08/2012 12:28 PM, Michał Górny wrote:
And something will need to provide that /usr/bin/eapi4 thing. And that
introduces new problems:
I'm just parroting someone else's suggestion; I don't really know enough
about the details to answer these properly. Not that that will stop me.
1) h
On Thu, 8 Mar 2012 18:30:47 +0100
Jeroen Roovers wrote:
> On Thu, 8 Mar 2012 17:14:58 +
> Ciaran McCreesh wrote:
> > 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
On Thu, 8 Mar 2012 17:14:58 +
Ciaran McCreesh wrote:
> 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 caref
On Thu, 08 Mar 2012 10:56:21 -0500
Michael Orlitzky wrote:
> 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 cour
On Thu, 08 Mar 2012 09:07:18 -0800
Zac Medico 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 so
On 03/08/2012 08:35 AM, Ciaran McCreesh wrote:
On Thu, 08 Mar 2012 08:30:57 -0800
Zac Medico 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, nob
On Thu, 08 Mar 2012 11:59:33 -0500
Alexandre Rostovtsev wrote:
> On Thu, 2012-03-08 at 16:29 +, 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 loo
On Thu, Mar 8, 2012 at 11:51 AM, Ulrich Mueller 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 o
On Thu, 2012-03-08 at 16:29 +, 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 probl
> 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 th
On 03/08/2012 08:29 AM, Ciaran McCreesh wrote:
On Thu, 08 Mar 2012 08:21:53 -0800
Zac Medico 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
restricti
On Wed, Mar 7, 2012 at 3:41 PM, Ulrich Mueller 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
On Thu, 08 Mar 2012 08:30:57 -0800
Zac Medico 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
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
On Thu, 08 Mar 2012 08:21:53 -0800
Zac Medico 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
On 03/08/2012 08:11 AM, David Leverton wrote:
On Mar 8, 2012 3:29 PM, "Zac Medico" 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 va
On Mar 8, 2012 3:29 PM, "Zac Medico" 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 synt
1 - 100 of 117 matches
Mail list logo
