Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Zac Medico]

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

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Michael Orlitzky]

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. 
Here's a stupid but hopefully clear example:


  $ cat test.ebuild
  eapi 4
  HOMEPAGE="http://www.example.com/";
  echo "test.ebuild, current EAPI=${EAPI}"


  $ cat test-sourcer.sh
  #!/bin/bash

  function eapi() {
  if [ "$TELL_ME_YOUR_EAPI" == 1 ]; then
  exit $1
  fi
  export EAPI=$1
  }

  export TELL_ME_YOUR_EAPI=1
  `eval 'source test.ebuild'`
  echo "Found EAPI: $?"

  export TELL_ME_YOUR_EAPI=0
  source test.ebuild


This sources it once, which short-circuits at the eapi() call returning 
'4'. Then we source it a second time with EAPI=4, and see that it makes 
it past the call to eapi() where any incompatible features would be.


  $ ./test-sourcer.sh
  Found EAPI: 4
  test.ebuild, current EAPI=4

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Michał Górny]

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 aren't executing ebuilds via an
> > interpreter. You're performing an action that involves using the
> > data and code in an ebuild multiple times and in multiple different
> > ways, and that may also involve doing the same to an installed
> > package that is being replaced.
> >
> 
> I do understand that; but the fact that the data are computed in an
> ugly turing-complete language complicates things.
> 
> Did someone already propose replacing EAPI=foo with a function call
> akin to inherit?
> 
>eapi 4
>inherit whatever
>...
> 
> the call to eapi() would then set $EAPI accordingly. If the ebuild is 
> being executed directly, it could exit $EAPI; otherwise, it would 
> continue normally. That would give us an interface to the variable,
> and we wouldn't need to know the EAPI ahead of time to do it as long
> as it's the first function called in the ebuild.
> 
> 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.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Walter Dnes]

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 statement must match the following regular expression (extended
>   regexp syntax):
>   ^[ \t]*EAPI=(['"]?)([A-Za-z0-9._+-]*)\1[ \t]*(#.*)?$
> 
> 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 second point could be rendered moot with a little sanity checking
like so...

#!/bin/bash
counter=`grep -c "^EAPI=" ${1}`
if [ ${counter} -eq 0 ]; then
#  
   exit
elif [ ${counter} -gt 1 ]; then
   echo "***ERROR*** only 1 line allowed beginning with EAPI="
   exit
else
#  
   exit
fi

  This treats the EAPI statement as a declaration, and doesn't care
where it shows up in the file.  I'm assuming no leading blanks in front
of "EAPI".

-- 
Walter Dnes 

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Alec Warner]

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't executing ebuilds via an
>> interpreter. You're performing an action that involves using the data
>> and code in an ebuild multiple times and in multiple different ways,
>> and that may also involve doing the same to an installed package that
>> is being replaced.
>>
>
> I do understand that; but the fact that the data are computed in an ugly
> turing-complete language complicates things.
>
> Did someone already propose replacing EAPI=foo with a function call akin to
> inherit?

the eapi function doesn't exist in earlier eapis, so you end up doing
the rename thing. Otherwise old package managers barf on the new
syntax. I still think going with a comment is better than this.

>
>  eapi 4
>  inherit whatever
>  ...
>
> the call to eapi() would then set $EAPI accordingly. If the ebuild is being
> executed directly, it could exit $EAPI; otherwise, it would continue
> normally. That would give us an interface to the variable, and we wouldn't
> need to know the EAPI ahead of time to do it as long as it's the first
> function called in the ebuild.
>
> 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.
>

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Michael Orlitzky]

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 involves using the data
and code in an ebuild multiple times and in multiple different ways,
and that may also involve doing the same to an installed package that
is being replaced.



I do understand that; but the fact that the data are computed in an ugly 
turing-complete language complicates things.


Did someone already propose replacing EAPI=foo with a function call akin 
to inherit?


  eapi 4
  inherit whatever
  ...

the call to eapi() would then set $EAPI accordingly. If the ebuild is 
being executed directly, it could exit $EAPI; otherwise, it would 
continue normally. That would give us an interface to the variable, and 
we wouldn't need to know the EAPI ahead of time to do it as long as it's 
the first function called in the ebuild.


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.

Re: [gentoo-dev] eselect repository moved to git

[Ulrich Mueller]

> On Thu, 8 Mar 2012, Michał Górny wrote:

> Did you just do the ultimately ugly thing of having two repos in one,
> as two completely diverged branches?

I'm certainly not a git expert. But the git project itself does such
things in their repo, so I believe it cannot be completely wrong.

Ulrich

Re: [gentoo-dev] eselect repository moved to git

[Michał Górny]

On Thu, 8 Mar 2012 21:37:21 +0100
Ulrich Mueller  wrote:

> This is a heads up that the eselect repository has moved to
> git.overlays.gentoo.org.
> 
> If you maintain your modules there, you'll find all external modules
> in the "extern" branch, whereas eselect proper is in master.

Did you just do the ultimately ugly thing of having two repos in one,
as two completely diverged branches?

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

[gentoo-dev] eselect repository moved to git

[Ulrich Mueller]

This is a heads up that the eselect repository has moved to
git.overlays.gentoo.org.

If you maintain your modules there, you'll find all external modules
in the "extern" branch, whereas eselect proper is in master.

Note that the version assignment used in most modules will no longer
work with git:

   SVN_DATE='$Date$'
   VERSION=$(svn_date_to_version "${SVN_DATE}" )

So please make sure that you update the VERSION variable before making
your next release.

Ulrich

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Alexis Ballier]

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 consider illegal anyway.
> 
> ...and yet people do it. That and the violations of the HOMEPAGE rule
> tell you a lot about what happens when something is made syntactically
> valid but supposedly not legal.
> 

... and this is where repoman helps.
broken deps are syntactically valid but not legal either.

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Alexis Ballier]

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 here may be when "old parsing" will wrongly parse a
malformed EAPI 42 assignment (so that new parsing doesnt detect an
EAPI and assumes its 0) as EAPI 4.
this is a purely hypothetical scenario that will be easily detected if
it ever happens, though :)

anyway, "new parsing" != "old parsing" should trigger a repoman
warning for old EAPIs.

A.

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Ciaran McCreesh]

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 of the HOMEPAGE rule
tell you a lot about what happens when something is made syntactically
valid but supposedly not legal.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Ulrich Mueller]

> 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 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.

Sorry, but this is nonsense (or rather FUD). Indeed we had 3 ebuilds
(0.01%) in the Portage tree where parsing resulted in an EAPI
different from the one in metadata.

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.

Ulrich


[1] 

[2] 

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Ulrich Mueller]

> 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 of the ebuild (N=10 and N=30
>> have been suggested).
>> - The statement must match the following regular expression (extended
>> regexp syntax):
>> ^[ \t]*EAPI=(['"]?)([A-Za-z0-9._+-]*)\1[ \t]*(#.*)?$

> I'd make the regexp less strict -- at least allow whitespace around '='.
> If the intent is to not rely on a specific bash version for a global
> scope, why should we limit it to the (current) bash syntax?

This could certainly be done ...

> And it may be also a good idea to not rely on a specific line format,
> so e.g. 'dnl EAPI=4' will work as well.

... but loosening it too much looks a little dangerous, because it
would probably match comments and could produce unintended matches.

If we allow for a general syntax, we should restrict it to the first
line of the ebuild. But that is proposal 2 then.

>> 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 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.
- If the ebuild is EAPI 5, then "new parsing" must detect EAPI 5.

> Or more exactly, how does it know when an older EAPI is used if it
> is supposed to not use the value it uses to detect EAPI?

If new parsing detects EAPI 5 or later, then use this value (and do a
sanity check after the ebuild has been sourced). Otherwise, discard
the value determined by new parsing and detect the EAPI in the
traditional way by sourcing the ebuild.

Ulrich

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Ciaran McCreesh]

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 have a /usr/bin/eapi5, it would have to be
> > implemented as something that invoked the package manager, not as a
> > direct interpreter.
> 
> Fair enough, but aren't you arguing the opposite point with Zac? If
> ebuilds are data, fine, we write EAPI=4 somewhere and be done with
> it. Anything not having that format is out-of-spec.

The problem is that right now there's no way to determine the format of
the data until you already know the format of the data. We hack around
this by not allowing "drastic" format changes, where "drastic" includes
"using things in newer versions of bash" and "not adding new global
scope commands".

The question under discussion is whether we a) keep "what format the
data is in" as being part of the data, but impose some strange and
arbitrary conditions on it, b) make a one-time change to have some kind
of 'header' inside the file describing its format that isn't really part
of the data itself, or c) admit that GLEP 55 already solved the problem
and we might as well just fix the issue properly once and for all, even
if GLEP 55's author is considered by some to be one of Satan's little
minions.

> 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 involves using the data
and code in an ebuild multiple times and in multiple different ways,
and that may also involve doing the same to an installed package that
is being replaced.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Michael Orlitzky]

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; I don't really know
enough about the details to answer these properly. Not that that will
stop me.


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 have a /usr/bin/eapi5, it would have to be implemented
as something that invoked the package manager, not as a direct
interpreter.


Fair enough, but aren't you arguing the opposite point with Zac? If 
ebuilds are data, fine, we write EAPI=4 somewhere and be done with it. 
Anything not having that format is out-of-spec.


If they're code, they're code, and we need to execute them somehow. And 
the reason for the proposal in the first place was that the way we do it 
now ain't so great, eh?

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Zac Medico]

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 and 'old
parsing' detects EAPI 5? Or more exactly, how does it know when
an older EAPI is used if it is supposed to not use the value it uses to
detect EAPI?


We can simply detect this case and treat it as an error. The purpose of 
the "discarded for earlier EAPIs" part is to allow more variance for 
older EAPIs, and treating this case as an error will probably affect 
zero or a negligible number of older ebuilds in practice.

--
Thanks,
Zac

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Ciaran McCreesh]

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 to mention we're either keeping two different
> variants for a longer while, or disregarding backwards compatibility
> with older package managers for no actual benefit.

No, you'd just switch extensions for EAPI 5 onwards, and keep the old
rules for EAPI 4. Same idea and impact as GLEP 55, except without as
much future proofing.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Ciaran McCreesh]

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 details to answer these properly. Not that that will
> stop me.

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 have a /usr/bin/eapi5, it would have to be implemented
as something that invoked the package manager, not as a direct
interpreter.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Michał Górny]

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 lines of the ebuild (N=10 and N=30
>   have been suggested).
> - The statement must match the following regular expression (extended
>   regexp syntax):
>   ^[ \t]*EAPI=(['"]?)([A-Za-z0-9._+-]*)\1[ \t]*(#.*)?$

I'd make the regexp less strict -- at least allow whitespace around '='.
If the intent is to not rely on a specific bash version for a global
scope, why should we limit it to the (current) bash syntax?

And it may be also a good idea to not rely on a specific line format,
so e.g. 'dnl EAPI=4' will work as well.

> 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 and 'old
parsing' detects EAPI 5? Or more exactly, how does it know when
an older EAPI is used if it is supposed to not use the value it uses to
detect EAPI?

> *** 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.

What if we ever decide to use a language which would would have another
requirements for first line?

> 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 to mention we're either keeping two different
variants for a longer while, or disregarding backwards compatibility
with older package managers for no actual benefit.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Michael Orlitzky]

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) how are we going to support multiple package managers? will we need
to install eapi4 thing as a smart wrapper choosing the right PM?

2) what about Prefix? #!/usr/bin/env eapi4 then, or proactive updating
of shebangs in synced ebuilds? and then regenerating the whole cache
(guess how long does it take to update it),


Wouldn't #!/use/bin/env eapi4 handle both (1) and (2)? You might have to 
eselect package-manager or something first if you want to use two PMs at 
once.




3) what should happen if user executes ebuild? the ebuild should merge
itself? with dependencies or without?


If a user marks the ebuild executable and does ./foo-x.y.ebuild, the 
eapi4 wrapper can decide what to do. Nothing at all, print larry the 
cow, or crash (what we do now) are all fine with me =)

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Ciaran McCreesh]

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 rule would have to be
> > documented and have special code to carefully enforce it. That's a
> > big deal.
> 
> Exactly like HOMEPAGE is a big deal?
> 
> 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.
> 
> http://devmanual.gentoo.org/ebuild-writing/variables/index.html

That's a QA thing, not a spec thing, and it's there because some
old-school developers don't know how to use their package manager
properly, and want to copy-paste a string from an ebuild into their
browser.

It's a silly rule. And if you take a count of how many ebuilds and
eclasses break that rule, you'll see exactly why such rules are a
problem.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Jeroen Roovers]

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 carefully enforce it. That's a big deal.

Exactly like HOMEPAGE is a big deal?

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.

http://devmanual.gentoo.org/ebuild-writing/variables/index.html


   jer

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Michał Górny]

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 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.

And something will need to provide that /usr/bin/eapi4 thing. And that
introduces new problems:

1) how are we going to support multiple package managers? will we need
to install eapi4 thing as a smart wrapper choosing the right PM?

2) what about Prefix? #!/usr/bin/env eapi4 then, or proactive updating
of shebangs in synced ebuilds? and then regenerating the whole cache
(guess how long does it take to update it),

3) what should happen if user executes ebuild? the ebuild should merge
itself? with dependencies or without?

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Ciaran McCreesh]

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 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


signature.asc
Description: PGP signature

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Zac Medico]

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, 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

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Ciaran McCreesh]

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 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


signature.asc
Description: PGP signature

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Rich Freeman]

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 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

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Alexandre Rostovtsev]

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 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

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Ulrich Mueller]

> 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

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Zac Medico]

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
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

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Mike Gilbert]

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 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.

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Ciaran McCreesh]

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.
> >> _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


signature.asc
Description: PGP signature

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Zac Medico]

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

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Ciaran McCreesh]

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 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


signature.asc
Description: PGP signature

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Zac Medico]

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 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

[gentoo-dev] Ebb (eb) was: Re: RFD: EAPI specification in ebuilds

[Todd Goodman]

* Jeroen Roovers  [120307 21:25]:
> On Wed, 07 Mar 2012 17:36:05 -0500
> Alexandre Rostovtsev  wrote:
> 
> > FYI, any Russian speaker is *guaranteed* to read the name ".eb" as a
> > very common obscenity.
> 
> In Dutch it means the low tide, and as a verb, it means "becoming low"
> or "decreasing" as in the tide or some other fluid.
> 
> In English it means something very similar as in the Dutch verb, only
> without the tidal reference. Other Germanic languages will probably
> have their own variants.

It has the same meaning in English as well.  The tide can ebb.
Also, there are ebb tides (and neap tides as well.)

Todd

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[David Leverton]

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 syntax was used to assign it

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Michael Orlitzky]

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?

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Michael Orlitzky]

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.

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Zac Medico]

On 03/08/2012 12:13 AM, Alec Warner wrote:
> On Wed, Mar 7, 2012 at 11:27 PM, Ulrich Mueller  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

[gentoo-dev] RFC: virtual/shadow

[Paweł Hajdan, Jr.]

I'd like to add  to the tree.
It is an alternative implementation of shadow utilities (passwd, su,
login, etc) based on ideas from Openwall's tcb.

Earlier I tried upstreaming the Openwall's shadow patches, and you can
see a log of those efforts at


In the end shadow-4.1.5 has some experimental support for tcb, but

1) It's incomplete (I didn't manage to upstream all Openwall's patches).
2) It's ugly (even more "special cases" in the already #ifdef-heavy
codebase).
3) It requires sys-auth/tcb, which doesn't work with vanilla glibc (I'm
maintaining tcb in Gentoo and have special patch for that, reviewed by
upstream), and is broken with recent glibc
().

And now we have  which is a
small alternative implementation, possibly going even further (the file
system layout is a bit different than with tcb).

I'd like to add virtual/shadow-0, with the following dependencies:

DEPEND=""
RDEPEND="|| ( >=sys-apps/shadow-4.1 sys-apps/hardened-shadow )"

hardened-shadow package is not yet in the tree, I'm going to be its
maintainer (base-system or anyone else is welcome to join), and the
ebuild is going to be very simple.

And then convert profiles to the new virtual (the relevant files; below
are all occurrences of sys-apps/shadow):

$ grep 'sys-apps/shadow' -r /usr/portage/profiles/
/usr/portage/profiles/ChangeLog-2011:  Added sys-apps/shadow to
packages.build as we need it on stage1.
/usr/portage/profiles/prefix/packages:-*>=sys-apps/shadow-4.1
/usr/portage/profiles/prefix/package.provided:sys-apps/shadow-0
/usr/portage/profiles/base/packages:*>=sys-apps/shadow-4.1
/usr/portage/profiles/uclibc/packages.build:sys-apps/shadow
/usr/portage/profiles/default/bsd/ChangeLog:  Add -*>=sys-apps/shadow-4.1
/usr/portage/profiles/default/bsd/package.mask:sys-apps/shadow
/usr/portage/profiles/default/bsd/packages:-*>=sys-apps/shadow-4.1
/usr/portage/profiles/default/linux/packages.build:sys-apps/shadow
/usr/portage/profiles/use.local.desc:sys-apps/shadow:audit - Enable
support for sys-process/audit
/usr/portage/profiles/use.local.desc:sys-apps/shadow:tcb - Enable
support for sys-auth/tcb

And any reverse dependencies (after testing):



What do you think?



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-dev-announce] Submit project ideas NOW for Google Summer of Code 2012

[Anthony G. Basile]

On 03/08/2012 02:28 AM, Richard Yao wrote:

I am not a developer yet, but I would like to suggest some idea possibilities:

Minix port of Gentoo
Illumos port of Gentoo
LLVM/Clang System Compiler Support
ICC System Compiler Support (probably easier than LLVM/Clang)
Port of Gentoo/FreeBSD to amd64 (or other architectures)
Gentoo/FreeBSD KVM port (we don't have to let upstream have all of the fun)
Gentoo Prefix --as-needed support on one or more architectures that
currently lack it
Gentoo Prefix Cygwin support
Gentoo Prefix Minix support
We (Patrick and I) tried to get someone interested in an OpenBSD 
(re)port of Gentoo, but students lots interest.  Maksbotan got involved 
but we soon hit deep snags.  There were not something we couldn't 
handle, but they were time consuming.  For the hell of it, I started 
porting Gentoo to minix a few days ago when 3.2.0 came out.  Same story, 
and as soon as the issues got deep, I asked myself, do I have time for 
this?!


Then I asked, who would use this?  I'm not sure about the OpenBSD port 
but with Minix there is some possibility because Minix is in need of 
userland.  *Shrug*


--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 8040 5A4D 8709 21B1 1A88  33CE 979C AF40 D045 5535
GnuPG ID  : D0455535

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Michał Górny]

On Wed, 7 Mar 2012 20:12:25 -0800
Alec Warner  wrote:

> On Wed, Mar 7, 2012 at 12:41 PM, 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 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):
> >  ^[ \t]*EAPI=(['"]?)([A-Za-z0-9._+-]*)\1[ \t]*(#.*)?$
> >
> > 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


signature.asc
Description: PGP signature

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Michał Górny]

On Wed, 07 Mar 2012 17:14:13 -0500
Michael Orlitzky  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


signature.asc
Description: PGP signature

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Marc Schiffbauer]

* 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


pgpiOirLF4AWG.pgp
Description: PGP signature

Re: [gentoo-dev] Re: [gentoo-dev-announce] Submit project ideas NOW for Google Summer of Code 2012

[Alec Warner]

On Wed, Mar 7, 2012 at 11:28 PM, Richard Yao  wrote:
> I am not a developer yet, but I would like to suggest some idea possibilities:
>
> Minix port of Gentoo
> Illumos port of Gentoo
> LLVM/Clang System Compiler Support
> ICC System Compiler Support (probably easier than LLVM/Clang)
> Port of Gentoo/FreeBSD to amd64 (or other architectures)
> Gentoo/FreeBSD KVM port (we don't have to let upstream have all of the fun)
> Gentoo Prefix --as-needed support on one or more architectures that
> currently lack it
> Gentoo Prefix Cygwin support
> Gentoo Prefix Minix support

I'm a little wary of 'ports' as I am unsure myself how much actual
software writing is required.

>
> I might be too inexperienced to serve as a mentor this summer,
> provided that the recruitment process finishes in time. I would
> appreciate it if anyone interested in being a mentor for any of these
> ideas adopted them.

You don't need to be a Gentoo Developer to be a mentor.

>
> On Thu, Mar 8, 2012 at 2:03 AM, Robin H. Johnson  wrote:
>> On Wed, Mar 07, 2012 at 11:38:47PM -0600, Donnie Berkholz wrote:
>>> . If you
>>> have project ideas, this is the place to put them. It's critical to also
>>> include potential mentors and prerequisite skills so students know which
>>> ideas make sense and where to learn more about them.
>> For any devs with ideas from the previous years that didn't get chosen,
>> the old page is here:
>> http://www.gentoo.org/proj/en/userrel/soc/ideas.xml
>>
>> I'm not going to be putting my Upstart idea forward again, due to lack
>> of time, and I don't think it's quite suited. Somebody else might want
>> to look at the potential of porting OpenRC's oldnet into systemd
>> however...
>>
>> --
>> Robin Hugh Johnson
>> Gentoo Linux: Developer, Trustee & Infrastructure Lead
>> E-Mail     : robb...@gentoo.org
>> GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
>>
>

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Alec Warner]

On Wed, Mar 7, 2012 at 11:27 PM, Ulrich Mueller  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
>