(trying to have people understand the idea, not to discuss in this
thread)
On Fri, 2009-03-13 at 06:18 +1300, Alistair Bush wrote:
As long as we want/have to support PMs lacking EAPI detection in
'*.ebuild' to mask ebuilds with unknown EAPI, each approach to add EAPI
to an '*.ebuild' must
Michael Haubenwallner wrote:
Hi,
Reminder (for myself):
As long as we want/have to support PMs lacking EAPI detection in
'*.ebuild' to mask ebuilds with unknown EAPI, each approach to add EAPI
to an '*.ebuild' must be hackish. So we can try to find the least ugly
hack, or we need to change
Hi,
Reminder (for myself):
As long as we want/have to support PMs lacking EAPI detection in
'*.ebuild' to mask ebuilds with unknown EAPI, each approach to add EAPI
to an '*.ebuild' must be hackish. So we can try to find the least ugly
hack, or we need to change the extension.
So just another
Hello all,
Here are my comments, opinions, and a recommendation regarding GLEP
55 and similar proposals. I've put in 1) A) and a) numbering to
differentiate the various lists. Though perhaps long winded, at least
check out the Recommendation below.
The idea of sticking EAPI in metadata.xml was
Thanks Petteri,
1) Status quo
- does not allow changing inherit
- bash version in global scope
- global scope in general is quite locked down
lets move on!
2) EAPI in file extension
- Allows changing global scope and the internal format of the ebuild
a) .ebuild-eapi
-
EAPI inside ebuild is the best solution. If we really have to put it
inside filename, keep it out of extension, like 2) b) suggests.
--
Peter.
2) EAPI in file extension
- Allows changing global scope and the internal format of the ebuild
a) .ebuild-eapi
- ignored by current Portage
This is the solution that solves most problems. Going with something
else is just a way of doing it wrong for the sake of it.
- ferdy
Petteri Räty wrote:
2) EAPI in file extension
- Allows changing global scope and the internal format of the ebuild
a) .ebuild-eapi
- ignored by current Portage
b) .eapi.ebuild
- current Portage does not work with this
c) .eapi.new extension
- ignored by current Portage
On Sat, 28 Feb 2009 19:39:36 +
Robert Bridge rob...@robbieab.com wrote:
I have been thinking about this specific option. I will admit I don't
know if this has already been noted, but would this create the
possibility of multiple ebuilds with the same $C/$P-$PV?
GLEP 55 forbids it.
Note
Kumba wrote:
I was talking to Alec last night in -dev (yes, I'm still alive), and I
tossed out the idea of using metadata.xml instead of mangling the ebuild
filename or even sticking it as the first line in the ebuild (as a
hashbang or something gentoo-specific, for example).
Fleshing out
On Tue, Feb 24, 2009 at 5:21 PM, Petteri Räty betelge...@gentoo.org 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
My 2¢ :
Keep the EAPI inside the ebuild itself. On the first line, on the fifth
line, as an argument with the shebang, as a comment, as a variable, as a
function call, ...
I really don't care what it looks like, as long as it's inside the ebuild.
Cheers,
Rémi
On Wed, 25 Feb 2009 00:21:23 +0200
Petteri Räty betelge...@gentoo.org wrote:
3) EAPI in locked down place in the ebuild
There's a less extreme variant on this that's slightly cleaner, and
with appropriate weaseling is also less messy. Simply add the following
very carefully worded additional
On Thu, 26 Feb 2009 18:07:32 +
Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:
There's a less extreme variant on this that's slightly cleaner, and
with appropriate weaseling is also less messy. Simply add the
following very carefully worded additional requirement for future
EAPIs,
On Thu, Feb 26, 2009 at 11:50 PM, Ciaran McCreesh
ciaran.mccre...@googlemail.com wrote:
On Thu, 26 Feb 2009 18:07:32 +
Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:
There's a less extreme variant on this that's slightly cleaner, and
with appropriate weaseling is also less messy.
On Fri, 27 Feb 2009 00:17:36 +0530
Nirbheek Chauhan nirbh...@gentoo.org wrote:
Is the following a stricter subset of your wording? --
EAPI must be set in an ebuild as the first non-comment line, and
thereafter must not be set to a different value
No. With your wording, the following are
On Fri, Feb 27, 2009 at 12:26 AM, Ciaran McCreesh
ciaran.mccre...@googlemail.com wrote:
On Fri, 27 Feb 2009 00:17:36 +0530
Nirbheek Chauhan nirbh...@gentoo.org wrote:
Is the following a stricter subset of your wording? --
EAPI must be set in an ebuild as the first non-comment line, and
On Fri, 27 Feb 2009 00:46:04 +0530
Nirbheek Chauhan nirbh...@gentoo.org wrote:
Ah, I thought I might be missing something. Then how about:
EAPI must be set in an ebuild as the first non-comment line, such
that bash does not perform any expansions during the assignment, and
thereafter must
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
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.
-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
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 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, 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-
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
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 it
easy to read
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. Everyone is
only
Petteri Räty wrote:
3) EAPI in locked down place in the ebuild
- Allows changing global scope
- EAPI can't be changed in an existing ebuild so the PM can trust
the value in the cache
I don't see how this follows. The PM can compare the mtime on the file
with the time the cache was
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
On Tuesday 24 of February 2009 23:21:23 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
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
On Tue, Feb 24, 2009 at 2:21 PM, 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. Everyone is
only
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 [...]
A multitude of leaves on every branch of the tree. That could be a
multiple of the current tree size - maybe talk to infra about this.
It's also a multitude
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 in December 2007 [1], and
42 matches
Mail list logo
