Re: [gentoo-dev] Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
Ciaran McCreesh ha scritto:
On Thu, 27 Dec 2007 18:03:27 +
Roy Marples [EMAIL PROTECTED] wrote:
Using your analogy you should then recognise that there is a strong
dislike for pink and should seek a new colour that allows the building
of said extensions.
And what colour would that be? We've already ruled out purple, brown
and yellow, and no-one has yet found any other colour of paint.
sorry if this has already suggested.
my idea is to use shebang; the advantage in using shebang is that file
doesn't need to be sourced or parsed by complex algorithms in order to
extract the necessary information.
an example:
#!/usr/bin/ebuild eapi=1
# Copyright 1999-2007 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
DESCRIPTION=My EAPI-1 ebuild
HOMEPAGE=http://www.gentoo.org/;
SRC_URI=
LICENSE=GPL-2
...
shebang's synopsis would look something like:
#!interpreter [key=value] [key=value] [...]
pros:
1) it's standard. shell scripts use it. why ebuilds shouldn't?
2) it's easy to parse:
eval `head -n1 $ebuild | cut -d\ -f2-`; echo $eapi
3) in the future, for any other situation analogous to this, you could
add another key=value to the ebuild's shebang
4) easily checked by repoman
cons:
?
just my two Eurocents.
since now you can bite me ;-)
--
#include stdio.h
main(){printf(%x,4275974592);}
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
On Sun, 30 Dec 2007 00:16:22 +0100 Federico Ferri [EMAIL PROTECTED] wrote: sorry if this has already suggested. It has. It solves nothing. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
On Sat, 2007-12-29 at 23:20 +, Ciaran McCreesh wrote: On Sun, 30 Dec 2007 00:16:22 +0100 Federico Ferri [EMAIL PROTECTED] wrote: sorry if this has already suggested. It has. It solves nothing. If it solves nothing you should at least post a link to the post you made explaining so, instead of the user posting Why? and another silly debate starting. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
On Tue, 2007-12-25 at 04:16 -0500, Ciaran McCreesh wrote: On 12/25/07, Roy Marples [EMAIL PROTECTED] wrote: Ok. So do you use an EAPI 0 environment to do the sourcing, or an EAPI 1 environment, or what? If it's that such a big deal, then simply ensure that Thankyou for reading and understanding the GLEP before jumping in and commenting. I understand that metadata in a file name is pure and simple hackery that has no place here and the GLEP is a flimsy attempt to justify it. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
Roy Marples wrote: I understand that metadata in a file name is pure and simple hackery that has no place here and the GLEP is a flimsy attempt to justify it. Do you count version as metadata? Cheers, -jkt -- cd /local/pub more beer /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
Roy Marples wrote: On Tue, 2007-12-25 at 04:16 -0500, Ciaran McCreesh wrote: On 12/25/07, Roy Marples [EMAIL PROTECTED] wrote: Ok. So do you use an EAPI 0 environment to do the sourcing, or an EAPI 1 environment, or what? If it's that such a big deal, then simply ensure that Thankyou for reading and understanding the GLEP before jumping in and commenting. I understand that metadata in a file name is pure and simple hackery that has no place here and the GLEP is a flimsy attempt to justify it. Thanks Roy Roy++ -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
On Thu, 2007-12-27 at 16:39 +0100, Jan Kundrát wrote: Roy Marples wrote: I understand that metadata in a file name is pure and simple hackery that has no place here and the GLEP is a flimsy attempt to justify it. Do you count version as metadata? No. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
Jan Kundrát a écrit :
Roy Marples wrote:
I understand that metadata in a file name is pure and simple hackery
that has no place here and the GLEP is a flimsy attempt to justify it.
Do you count version as metadata?
I'll bite :)
Version numbers aren't metadata because they uniquely identify the
ebuild/package.
EAPI on the other hand brings no such information to identify the
package. Furthermore, the GLEP proposes that no 2 ebuilds with the exact
same version may exist regardless of different EAPIs.
In the end, ${CATEGORY}/${PF} is like the key in a RDB table. The EAPI
is just extra info.
I'll just wrap this up by saying that I don't have an opinion on whether
putting the EAPI inside the ebuild or outside is better for the complex
operations involved in portage. I'll leave that to the more informed devs :)
Cheers,
Rémi
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
On Thu, 2007-12-27 at 16:32 +, Ciaran McCreesh wrote: On Thu, 27 Dec 2007 15:04:52 + Roy Marples [EMAIL PROTECTED] wrote: I understand that metadata in a file name is pure and simple hackery that has no place here and the GLEP is a flimsy attempt to justify it. Alright, so where would you stick EAPI such that all the requirements that've previously been described are met? I neither know, nor care. I just feel very strongly that the current proposal is wrong, and no requirements that you or others may have can possibly outweigh that. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
On Thu, 27 Dec 2007 15:04:52 + Roy Marples [EMAIL PROTECTED] wrote: I understand that metadata in a file name is pure and simple hackery that has no place here and the GLEP is a flimsy attempt to justify it. Alright, so where would you stick EAPI such that all the requirements that've previously been described are met? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
On Thu, 2007-12-27 at 16:50 +, Ciaran McCreesh wrote: On Thu, 27 Dec 2007 16:45:06 + Roy Marples [EMAIL PROTECTED] wrote: Alright, so where would you stick EAPI such that all the requirements that've previously been described are met? I neither know, nor care. I just feel very strongly that the current proposal is wrong, and no requirements that you or others may have can possibly outweigh that. So you have no technical objections, no alternatives, no understanding of why it's necessary and no actual reason to call it 'wrong'. Hard to have technical objections to the contents of a string :) Actual reasons were stated in the first email I posted in this thread to which to replied. I care not for alternatives, nor understanding as it's not my domain of expertise or knowledge. But I can smell a blatant hack that is just wrong to the bone like a lot of other people here. Just because you have a the only solution to a problem does not make it right by default. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
On Thu, 27 Dec 2007 16:45:06 + Roy Marples [EMAIL PROTECTED] wrote: Alright, so where would you stick EAPI such that all the requirements that've previously been described are met? I neither know, nor care. I just feel very strongly that the current proposal is wrong, and no requirements that you or others may have can possibly outweigh that. So you have no technical objections, no alternatives, no understanding of why it's necessary and no actual reason to call it 'wrong'. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
On Thu, 27 Dec 2007 17:27:05 + Roy Marples [EMAIL PROTECTED] wrote: But I can smell a blatant hack that is just wrong to the bone like a lot of other people here. Clearly not... As you say, you don't care to understand any of this. You're just jumping in because you think you know what a file extension is and are thus qualified to comment. Unfortunately, the file extension is largely irrelevant -- it's merely the end result, and it's everything that leads up to that that's the important part. Or to put it another way, you're objecting to painting the house pink rather than green because you don't like pink (because your last house was green too), ignoring that it's been demonstrated that when painted green, it's impossible to add a conservatory and central heating because the green paint will catch fire and kill everyone. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
On Thu, 27 Dec 2007 18:03:27 + Roy Marples [EMAIL PROTECTED] wrote: On Thu, 2007-12-27 at 17:43 +, Ciaran McCreesh wrote: Or to put it another way, you're objecting to painting the house pink rather than green because you don't like pink (because your last house was green too), ignoring that it's been demonstrated that when painted green, it's impossible to add a conservatory and central heating because the green paint will catch fire and kill everyone. Using your analogy you should then recognise that there is a strong dislike for pink and should seek a new colour that allows the building of said extensions. And what colour would that be? We've already ruled out purple, brown and yellow, and no-one has yet found any other colour of paint. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
On Thu, 2007-12-27 at 17:43 +, Ciaran McCreesh wrote: Or to put it another way, you're objecting to painting the house pink rather than green because you don't like pink (because your last house was green too), ignoring that it's been demonstrated that when painted green, it's impossible to add a conservatory and central heating because the green paint will catch fire and kill everyone. Using your analogy you should then recognise that there is a strong dislike for pink and should seek a new colour that allows the building of said extensions. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
On Thu, 2007-12-27 at 18:11 +, Ciaran McCreesh wrote: On Thu, 27 Dec 2007 18:03:27 + Roy Marples [EMAIL PROTECTED] wrote: On Thu, 2007-12-27 at 17:43 +, Ciaran McCreesh wrote: Or to put it another way, you're objecting to painting the house pink rather than green because you don't like pink (because your last house was green too), ignoring that it's been demonstrated that when painted green, it's impossible to add a conservatory and central heating because the green paint will catch fire and kill everyone. Using your analogy you should then recognise that there is a strong dislike for pink and should seek a new colour that allows the building of said extensions. And what colour would that be? We've already ruled out purple, brown and yellow, and no-one has yet found any other colour of paint. If there are no other colours then maybe you shouldn't install extensions that only work with pink to the detriment of all other colours of the spectrum. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
On Thu, 2007-12-27 at 18:11 +, Ciaran McCreesh wrote: On Thu, 27 Dec 2007 18:03:27 + Roy Marples [EMAIL PROTECTED] wrote: On Thu, 2007-12-27 at 17:43 +, Ciaran McCreesh wrote: Or to put it another way, you're objecting to painting the house pink rather than green because you don't like pink (because your last house was green too), ignoring that it's been demonstrated that when painted green, it's impossible to add a conservatory and central heating because the green paint will catch fire and kill everyone. Using your analogy you should then recognise that there is a strong dislike for pink and should seek a new colour that allows the building of said extensions. And what colour would that be? We've already ruled out purple, brown and yellow, and no-one has yet found any other colour of paint. Any chance we can back on, you know, the actual topic, rather than these useless analogies? Thanks, -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
On Tue, 2007-12-25 at 02:43 -0500, Ciaran McCreesh wrote:
On Dec 25, 2007 2:38 AM, Roy Marples [EMAIL PROTECTED] wrote:
On Tue, 2007-12-25 at 02:26 -0500, Ciaran McCreesh wrote:
On Dec 24, 2007 7:53 AM, Roy Marples [EMAIL PROTECTED] wrote:
So to obtain EAPI from .ebuild you would always do
EAPI=`. /path/to/ebuild.ebuild; echo ${EAPI}`
Doesn't work with current ebuilds, nor future ebuilds. No points!
Works fine as long as the functions the ebuild has in global scope
exist. Which would assuming that the ebuild was sourced in a portage
environment.
Ok. So do you use an EAPI 0 environment to do the sourcing, or an EAPI
1 environment, or what?
If it's that such a big deal, then simply ensure that
1) no functions are allowed in global scope
or
2) eapi is a function and not a variable
Thanks
Roy
PS - Merry Christmas everyone - I'm off to enjoy mine with my family
now. I suggest everyone else does the same :)
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
On 12/25/07, Roy Marples [EMAIL PROTECTED] wrote: Ok. So do you use an EAPI 0 environment to do the sourcing, or an EAPI 1 environment, or what? If it's that such a big deal, then simply ensure that Thankyou for reading and understanding the GLEP before jumping in and commenting. -- Ciaran McCreesh -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
Ciaran McCreesh wrote: On Mon, 24 Dec 2007 06:03:12 + Steve Long [EMAIL PROTECTED] wrote: * Set the EAPI inside the ebuild in a way that makes it easy to fetch it This is ok as atm only EAPI=1 is in the tree, so there is no backward compatibility issue. It's both a backwards and a forwards compatibility issue. Yeah, so forwards into the future where it's impossible to maintain this format (er..) there'll be another type of ebuild for your purported long-term solution. * Have a new ebuild/eclass extension .eapi-$EAPI This is for ebuilds for other package managers; it is envisaged by some that this will become the new ebuild format since it enables quick access to the EAPI without accessing the file contents. snip trivia about backend database formats And eclasses are an entirely separate issue. They need to be dealt with differently, ideally starting with EAPI 2. But they come under the scope of this discussion, since this is about the long-term future of *every* EAPI. So let's discuss them. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
Just picked this particular email to reply with my thoughts on this
thread.
On Mon, 2007-12-24 at 10:52 +, Steve Long wrote:
But they come under the scope of this discussion, since this is about the
long-term future of *every* EAPI. So let's discuss them
Impossible. History has proven again and again that you cannot predict
every aspect of the future. But then I'm sure you know this ;)
File name suffixes historically describe the content structure of a
file.
.png means the content is a picture and it's structure is Portable
Network Graphic.
.ebuild means the content is instructions on how to install something
and it's structure is bash.
So to obtain EAPI from .ebuild you would always do
EAPI=`. /path/to/ebuild.ebuild; echo ${EAPI}`
Now say you wanted to move ebuilds into xml you would do
EAPI=`xmlcmd_to_extract_node_value /root/eapi /path/to/ebuild.xml
In closing, EAPI describes features available, not content nor
structure.
Thanks
Roy
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
On Dec 24, 2007 7:53 AM, Roy Marples [EMAIL PROTECTED] wrote:
So to obtain EAPI from .ebuild you would always do
EAPI=`. /path/to/ebuild.ebuild; echo ${EAPI}`
Doesn't work with current ebuilds, nor future ebuilds. No points!
--
Ciaran McCreesh
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
On Tue, 2007-12-25 at 02:26 -0500, Ciaran McCreesh wrote:
On Dec 24, 2007 7:53 AM, Roy Marples [EMAIL PROTECTED] wrote:
So to obtain EAPI from .ebuild you would always do
EAPI=`. /path/to/ebuild.ebuild; echo ${EAPI}`
Doesn't work with current ebuilds, nor future ebuilds. No points!
Works fine as long as the functions the ebuild has in global scope
exist. Which would assuming that the ebuild was sourced in a portage
environment.
Thanks
Roy
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
On Dec 25, 2007 2:38 AM, Roy Marples [EMAIL PROTECTED] wrote:
On Tue, 2007-12-25 at 02:26 -0500, Ciaran McCreesh wrote:
On Dec 24, 2007 7:53 AM, Roy Marples [EMAIL PROTECTED] wrote:
So to obtain EAPI from .ebuild you would always do
EAPI=`. /path/to/ebuild.ebuild; echo ${EAPI}`
Doesn't work with current ebuilds, nor future ebuilds. No points!
Works fine as long as the functions the ebuild has in global scope
exist. Which would assuming that the ebuild was sourced in a portage
environment.
Ok. So do you use an EAPI 0 environment to do the sourcing, or an EAPI
1 environment, or what? What happens when EAPI 2 changes the behaviour
of inherit? What happens when EAPI 2 introduces a new global scope
function that sources a new kind of eclass that current package
managers don't support?
--
Ciaran McCreesh
--
[EMAIL PROTECTED] mailing list
