(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'
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 the
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 idea
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-
>
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 m
On Sat, 28 Feb 2009 19:39:36 +
Robert Bridge 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 that it's already p
Petteri Räty wrote:
> 2) EAPI in file extension
> - Allows changing global scope and the internal format of the ebuild
> a) .ebuild-
> - ignored by current Portage
> b) ..ebuild
> - current Portage does not work with this
> c) ..
> - ignored by current Portage
I have been think
> 2) EAPI in file extension
> - Allows changing global scope and the internal format of the ebuild
> a) .ebuild-
> - 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
pgpfhEMR
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.
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 Tue, Feb 24, 2009 at 5:21 PM, 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 format
On Fri, 27 Feb 2009 00:46:04 +0530
Nirbheek Chauhan 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 not be set to a
On Fri, Feb 27, 2009 at 12:26 AM, Ciaran McCreesh
wrote:
> On Fri, 27 Feb 2009 00:17:36 +0530
> Nirbheek Chauhan 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 va
On Fri, 27 Feb 2009 00:17:36 +0530
Nirbheek Chauhan 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 legal:
EAPI=$
On Thu, Feb 26, 2009 at 11:50 PM, Ciaran McCreesh
wrote:
> On Thu, 26 Feb 2009 18:07:32 +
> Ciaran McCreesh 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 additio
On Thu, 26 Feb 2009 18:07:32 +
Ciaran McCreesh 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, and retroactively impose it u
On Wed, 25 Feb 2009 00:21:23 +0200
Petteri Räty 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 requirement for future E
-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 p
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 it
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 m
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 m
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 comm
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
>
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:
> 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
Petteri Räty wrote:
> 2) EAPI in file extension
> - Allows changing global scope and the internal format of the ebuild
> a) .ebuild-
> - ignored by current Portage
> c) ..
> - ignored by current Portage
Any of the above are fine with me, there is a demonstrated need for
this to intr
-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
chang
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.
Bas
On Wed, 25 Feb 2009 00:21:23 +0200
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 dislike GLEP 55 aesthetically, b
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 b
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-
> - ignored by current Portage
simple, straightforward but ugly
> b) ..ebuild
> - current Portage does not work with this
this only
> 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 [
On Wed, 25 Feb 2009 00:21:23 +0200
Petteri Räty 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 of complexity - as an
> On Tue, Feb 24, 2009 at 2:21 PM, 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 singl
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 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 s
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 it
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 upd
On Wed, 25 Feb 2009 00:21:23 +0200
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 sing
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 through.
42 matches
Mail list logo