I have no strong opinion about this.
2) EAPI in file extension
- Allows changing global scope and the internal format of the ebuild
a) .ebuild-eapi
- ignored by current Portage
simple, straightforward but ugly
b) .eapi.ebuild
- current Portage does not work with this
this
On Tue, 24 Feb 2009 19:37:11 +
Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:
On Tue, 24 Feb 2009 20:28:43 +0100
Alexis Ballier aball...@gentoo.org wrote:
On Tue, 24 Feb 2009 18:24:16 +
Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:
On Tue, 24 Feb 2009 18:16:54
Hi!
My preference, most wanted to least wanted:
- inside the ebuild
If it's not too much pain. Yes, that is a very subjective
metric and it's what a large amount of flames has been about.
- in the filename, but not as a tail
eg: foo-2.3.4-r2+9.build
yes, alternate separators might be
On Wed, 25 Feb 2009 00:21:23 +0200
Petteri Räty betelge...@gentoo.org wrote:
Let's try something new. I would like to get opinions from as many
people as possible about GLEP 55 and alternatives listed here in order
to get some idea what the general developer pool thinks.
[...]
I dislike GLEP
On Wed, 2009-02-25 at 00:21 +0200, Petteri Räty wrote:
get opinions [..] to get some idea what the general developer pool thinks.
only allowed to post a single reply to this thread
Thank you for that, I usually don't follow long threads, so apologies if
things have been discussed already.
Donnie Berkholz wrote:
On 23:26 Sun 22 Feb , Donnie Berkholz wrote:
This is your friendly reminder! Same bat time (typically the 2nd 4th
Thursdays at 2000 UTC / 1600 EST), same bat channel (#gentoo-council @
irc.freenode.net) !
If you have something you'd wish for us to chat about,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Petteri Räty wrote:
3) EAPI in locked down place in the ebuild
c) .ebuild in current directory
- needs one year wait
I'm all for 1 or 3c, because we're not in any rush.
I don't see why there's such an immediate need to make as drastic
changes
Petteri Räty betelge...@gentoo.org wrote:
2) EAPI in file extension
- Allows changing global scope and the internal format of the ebuild
a) .ebuild-eapi
- ignored by current Portage
c) .eapi.new extension
- ignored by current Portage
Any of the above are fine with me, there is
* Petteri Räty betelge...@gentoo.org:
Donnie Berkholz wrote:
Open council spot
-
leio is next on the list. He's willing to join the council. A few of us
already voted to confirm him on-list, and we're waiting on the others.
Goal: Vote to confirm him, if necessary.
Le mardi 24 février 2009 à 09:47 -0800, Brian Harring a écrit :
On Sun, Feb 22, 2009 at 11:26:48PM -0800, Donnie Berkholz wrote:
This is your friendly reminder! Same bat time (typically the 2nd 4th
Thursdays at 2000 UTC / 1600 EST), same bat channel (#gentoo-council @
irc.freenode.net) !
On Wed, Feb 25, 2009 at 12:21:23AM +0200, Petteri R??ty wrote:
My notes so far:
1) Status quo
- does not allow changing inherit
- bash version in global scope
- global scope in general is quite locked down
2) EAPI in file extension
- Allows changing global scope and the internal
On Wed, Feb 25, 2009 at 01:42:38PM +0100, Gilles Dartiguelongue wrote:
Le mardi 24 février 2009 à 09:47 -0800, Brian Harring a écrit :
On Sun, Feb 22, 2009 at 11:26:48PM -0800, Donnie Berkholz wrote:
This is your friendly reminder! Same bat time (typically the 2nd 4th
Thursdays at 2000
On Mon, Feb 23, 2009 at 12:56 PM, Donnie Berkholz dberkh...@gentoo.org wrote:
This is your friendly reminder! Same bat time (typically the 2nd 4th
Thursdays at 2000 UTC / 1600 EST), same bat channel (#gentoo-council @
irc.freenode.net) !
If you have something you'd wish for us to chat about,
On Tuesday 24 February 2009, Petteri Räty wrote:
Let's try something new. I would like to get opinions from as many
people as possible about GLEP 55 and alternatives listed here in
order to get some idea what the general developer pool thinks.
Thanks for opening a spot to voice our opinions
On Wed, 25 Feb 2009 07:34:41 +0100
Tiziano Müller dev-z...@gentoo.org wrote:
Well, you could theoretical consider everything in the cache valid
within the current scope, find the eapi within the cache or the ebuild
and then reconsider things.
You can't even do that, because new EAPIs might
On Wed, 25 Feb 2009 09:33:44 +0100
Alexis Ballier aball...@gentoo.org wrote:
That sounds like an implementation detail that you could solve by
using something else than a flat file database for metadata if
open()/read() calls are the slow part.
Metadata's shipped with the tree. It's a PMS
On Wed, 25 Feb 2009 04:04:46 +0100
Luca Barbato lu_z...@gentoo.org wrote:
given that the simplest thing is hacking ebuild.sh and extract eapi
with a simple C program (you can use pcre or ragel if you want)
exactly before the ebuild source:
That you're bringing ebuild.sh into this shows you
Ciaran McCreesh wrote:
On Wed, 25 Feb 2009 04:04:46 +0100
Luca Barbato lu_z...@gentoo.org wrote:
given that the simplest thing is hacking ebuild.sh and extract eapi
with a simple C program (you can use pcre or ragel if you want)
exactly before the ebuild source:
That you're bringing ebuild.sh
On Wed, Feb 25, 2009 at 04:56:04PM +0100, Luca Barbato wrote:
Yes, it will warn noisily. This is unacceptable, since stable users
will have months and months of noise when new rules come along.
unacceptable...
as in it's ugly to see...
No, it's unacceptable because stable users do not need
On Wed, 25 Feb 2009 16:56:04 +0100
Luca Barbato lu_z...@gentoo.org wrote:
That you're bringing ebuild.sh into this shows you still haven't
worked out how the process works. There is no need to use ebuild.sh
(which is a very good thing, because launching bash is
slow) when
Hi,
what do you think about checking for bashism on install_qa_check?
Obviously only for scripts with #!/bin/sh and #!/sbin/runscript as first line.
I think checkbashisms.pl [1] could be a good start point.
[1] http://svn.debian.org/viewsvn/devscripts/trunk/scripts/checkbashisms.pl
--
Timothy
Ciaran McCreesh wrote:
On Wed, 25 Feb 2009 09:33:44 +0100
Alexis Ballier aball...@gentoo.org wrote:
That sounds like an implementation detail that you could solve by
using something else than a flat file database for metadata if
open()/read() calls are the slow part.
Metadata's shipped with
Thomas Anderson wrote:
On Wed, Feb 25, 2009 at 04:56:04PM +0100, Luca Barbato wrote:
Yes, it will warn noisily. This is unacceptable, since stable users
will have months and months of noise when new rules come along.
unacceptable...
as in it's ugly to see...
No, it's unacceptable because
On Wed, 25 Feb 2009 17:17:29 +0100
Luca Barbato lu_z...@gentoo.org wrote:
I'd rather see more people backing their ideas with numbers...
I already told you your numbers are nonsense.
Of course opening the file when you've already opened it isn't going to
make any difference.
--
Ciaran
On Wed, Feb 25, 2009 at 12:21:23AM +0200, Petteri R??ty wrote:
1) Status quo
- does not allow changing inherit
- bash version in global scope
- global scope in general is quite locked down
Yuck, I want per-package eclasses and all those other goodies.
2) EAPI in file extension
-
Ulrich Mueller wrote:
On Wed, 25 Feb 2009, Petteri Räty wrote:
Let's try something new. I would like to get opinions from as many
people as possible about GLEP 55 and alternatives listed here in order
to get some idea what the general developer pool thinks.
I've already commented on this
Petteri Räty wrote:
Let's try something new. I would like to get opinions from as many
people as possible about GLEP 55 and alternatives listed here in order
to get some idea what the general developer pool thinks. Everyone is
only allowed to post a single reply to this thread in order to make
Brian Harring wrote:
4) eapi as a function; instead of EAPI=1, do eapi 1, required as
the first statement (simplest way).
pros:
- global scope changes can occur (inherit mechanism changes
included).
- expanding on the first, auto inherits (pkg level) are possible-
On Wednesday 25 February 2009 11:10:01 Timothy Redaelli wrote:
what do you think about checking for bashism on install_qa_check?
Obviously only for scripts with #!/bin/sh and #!/sbin/runscript as first
line.
I think checkbashisms.pl [1] could be a good start point.
[1]
On Wed, 25 Feb 2009 04:49:51 -0800
Brian Harring ferri...@gmail.com wrote:
4) eapi as a function; instead of EAPI=1, do eapi 1, required as
the first statement (simplest way).
Doesn't solve anything over having it as a variable, and has a messy
upgrade path.
- global scope changes can
On Wed, Feb 25, 2009 at 11:03:07PM +, Ciaran McCreesh wrote:
On Wed, 25 Feb 2009 04:49:51 -0800
Brian Harring ferri...@gmail.com wrote:
4) eapi as a function; instead of EAPI=1, do eapi 1, required as
the first statement (simplest way).
Doesn't solve anything over having it as a
On Wed, 25 Feb 2009 16:02:46 -0800
Brian Harring ferri...@gmail.com wrote:
Bullshit. First invocation of the ebuild, that means it can do
whatever it wants to the environment- literally swapping in the EAPI
environment right then/there. Auto inherits, changing the inherit
mechanism,
On Thu, Feb 26, 2009 at 12:11:04AM +, Ciaran McCreesh wrote:
On Wed, 25 Feb 2009 16:02:46 -0800
Brian Harring ferri...@gmail.com wrote:
Bullshit. First invocation of the ebuild, that means it can do
whatever it wants to the environment- literally swapping in the EAPI
environment
On Wed, 25 Feb 2009 16:24:45 -0800
Brian Harring ferri...@gmail.com wrote:
You can do that on a variable assignment too, with all the same
implications as having it as a function, and a slightly less
horrible upgrade path.
You're contradicting your own statements. Pkg level eclasses (if
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
On Wed, 25 Feb 2009 16:02:46 -0800
Brian Harring ferri...@gmail.com wrote:
snip a few arguments
Ciaran and Brian,
please respect Pettery's request and move your discussion to the GLEP55
thread or to another thread, but
On Wed, 25 Feb 2009 23:43:44 -0100
Jorge Manuel B. S. Vicetto jmbsvice...@gentoo.org wrote:
Ciaran McCreesh wrote:
On Wed, 25 Feb 2009 16:02:46 -0800
Brian Harring ferri...@gmail.com wrote:
snip a few arguments
Ciaran and Brian,
please respect Pettery's request and move your
Petteri Räty wrote:
Let's try something new. I would like to get opinions from as many
people as possible about GLEP 55 and alternatives listed here in order
to get some idea what the general developer pool thinks. Everyone is
only allowed to post a single reply to this thread in order to make
Petteri Räty wrote:
Let's try something new. I would like to get opinions from as many
people as possible about GLEP 55 and alternatives listed here in order
to get some idea what the general developer pool thinks. Everyone is
only allowed to post a single reply to this thread in order to make
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Petteri Räty wrote:
Let's try something new. I would like to get opinions from as many
people as possible about GLEP 55 and alternatives listed here in order
to get some idea what the general developer pool thinks. Everyone is
only allowed to post
fyi my email client doesn't recognize urls in the subject line, don't
know about anyone elses... but it'd be nice to click the link to the
bug, and you know have some clue what this is about without reading
the bug (e.g. a useful subject line). /endrant sorry I can't be of
any further help here.
40 matches
Mail list logo
