FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 03-08-2012, 04:28 PM
Michał Górny
 
Default RFD: EAPI specification in ebuilds

On Thu, 08 Mar 2012 10:56:21 -0500
Michael Orlitzky <michael@orlitzky.com> 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
 
Old 03-08-2012, 04:30 PM
Jeroen Roovers
 
Default RFD: EAPI specification in ebuilds

On Thu, 8 Mar 2012 17:14:58 +0000
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> 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
 
Old 03-08-2012, 04:37 PM
Ciaran McCreesh
 
Default RFD: EAPI specification in ebuilds

On Thu, 8 Mar 2012 18:30:47 +0100
Jeroen Roovers <jer@gentoo.org> wrote:
> On Thu, 8 Mar 2012 17:14:58 +0000
> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> 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
 
Old 03-08-2012, 04:48 PM
Michael Orlitzky
 
Default RFD: EAPI specification in ebuilds

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 =)
 
Old 03-08-2012, 04:52 PM
Michał Górny
 
Default RFD: EAPI specification in ebuilds

On Wed, 7 Mar 2012 21:41:02 +0100
Ulrich Mueller <ulm@gentoo.org> 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):
> ^[ ]*EAPI=(['"]?)([A-Za-z0-9._+-]*)1[ ]*(#.*)?$

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
 
Old 03-08-2012, 04:53 PM
Ciaran McCreesh
 
Default RFD: EAPI specification in ebuilds

On Thu, 08 Mar 2012 12:48:51 -0500
Michael Orlitzky <michael@orlitzky.com> 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
 
Old 03-08-2012, 04:56 PM
Ciaran McCreesh
 
Default RFD: EAPI specification in ebuilds

On Thu, 8 Mar 2012 18:52:13 +0100
Michał Górny <mgorny@gentoo.org> wrote:
> > Again, the proposal comes in two variants:
> > 2a) It is combined with a one time change of the file extension,
> > like .ebuild -> .eb.
>
> 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
 
Old 03-08-2012, 05:22 PM
Zac Medico
 
Default RFD: EAPI specification in ebuilds

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

On Wed, 7 Mar 2012 21:41:02 +0100
Ulrich Mueller<ulm@gentoo.org> 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
 
Old 03-08-2012, 05:37 PM
Michael Orlitzky
 
Default RFD: EAPI specification in ebuilds

On 03/08/2012 12:53 PM, Ciaran McCreesh wrote:

On Thu, 08 Mar 2012 12:48:51 -0500
Michael Orlitzky<michael@orlitzky.com> 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?
 
Old 03-08-2012, 05:48 PM
Ciaran McCreesh
 
Default RFD: EAPI specification in ebuilds

On Thu, 08 Mar 2012 13:37:09 -0500
Michael Orlitzky <michael@orlitzky.com> 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
 

Thread Tools




All times are GMT. The time now is 12:09 PM.

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