On 18-12-2007 00:39:38 +, Ciaran McCreesh wrote:
An EAPI is not limited to a numeric name. We could call the next EAPI
cabbage if we wanted to. There're already various experimental EAPIs
that don't use pure numbers (for example, paludis-1).
(Sometimes I think the next EAPI *should* be
Piotr Jaroszyński [EMAIL PROTECTED] posted
[EMAIL PROTECTED], excerpted below, on Mon, 17 Dec 2007
23:20:01 +0100:
Let's call the EAPI included in the ebuild filename the pre-source EAPI,
and the EAPI set inside the ebuild the post-source EAPI. Given these
two, the final EAPI used by the
On Tue, 18 Dec 2007 10:36:30 +0100
Fabian Groffen [EMAIL PROTECTED] wrote:
On 18-12-2007 00:39:38 +, Ciaran McCreesh wrote:
An EAPI is not limited to a numeric name. We could call the next
EAPI cabbage if we wanted to. There're already various
experimental EAPIs that don't use pure
On Tue, 18 Dec 2007 09:53:50 + (UTC)
Duncan [EMAIL PROTECTED] wrote:
Put directly, what is stopping us from actually allowing DIFFERENT
pre- source and post-source EAPI values?
That's effectively what happens when a package manager sources a
current EAPI=1 in a variable ebuild.
Here's the
Ulrich Mueller wrote:
It seems to me that this will inconvenience the users, in order to
solve a technical problem of the package manager.
Absolutely, +1. This does indeed sound like a technical issue; how
would requiring a dev to manually mirror the EAPI in the filename
extension provide any
On Tue, Dec 18, 2007 at 06:57:33AM -0700, Joe Peterson wrote:
Ulrich Mueller wrote:
It seems to me that this will inconvenience the users, in order to
solve a technical problem of the package manager.
Absolutely, +1. This does indeed sound like a technical issue; how
would requiring a
On Mon, 17 Dec 2007 18:46:12 -0700
Joe Peterson [EMAIL PROTECTED] wrote:
What about storing a copy of the EAPI in the Manifest file - when
ebuild ... digest is done? That way, it will always match the one
authoritative post-source EAPI setting, since changing the ebuild
will require a new
On Mon, 17 Dec 2007 23:20:01 +0100
Piotr Jaroszyński [EMAIL PROTECTED] wrote:
Hello,
attaching the GLEP.
most current version:
http://dev.gentoo.org/~peper/glep-0055.html
http://dev.gentoo.org/~peper/glep-0055.txt
There is one significant problem not covered in the GLEP: If a package
Thomas de Grenier de Latour wrote:
On 2007/12/18, Ciaran McCreesh [EMAIL PROTECTED] wrote:
On Mon, 17 Dec 2007 17:10:46 -0700
Joe Peterson [EMAIL PROTECTED] wrote:
I probably missed some of the stuff leading up to this GLEP, but
what is the problem with having the EAPI in the file and
On Tue, Dec 18, 2007 at 05:05:13PM +, Steve Long wrote:
Thomas de Grenier de Latour wrote:
On 2007/12/18, Ciaran McCreesh [EMAIL PROTECTED] wrote:
On Mon, 17 Dec 2007 17:10:46 -0700
Joe Peterson [EMAIL PROTECTED] wrote:
I probably missed some of the stuff leading up to this
On Tue, 18 Dec 2007, Fernando J Pereda wrote:
It seems to me that this will inconvenience the users, in order to
solve a technical problem of the package manager.
Absolutely, +1. This does indeed sound like a technical issue; how
would requiring a dev to manually mirror the EAPI in the
On Dec 18, 2007 6:37 PM, Ulrich Mueller [EMAIL PROTECTED] wrote:
On Tue, 18 Dec 2007, Fernando J Pereda wrote:
It seems to me that this will inconvenience the users, in order to
solve a technical problem of the package manager.
Absolutely, +1. This does indeed sound like a technical
On Tue, Dec 18, 2007 at 06:37:11PM +0100, Ulrich Mueller wrote:
On Tue, 18 Dec 2007, Fernando J Pereda wrote:
It seems to me that this will inconvenience the users, in order to
solve a technical problem of the package manager.
Absolutely, +1. This does indeed sound like a technical
Santiago M. Mola wrote:
One example was mentioned in this thread before: You cannot use
find -name '*.ebuild' anymore.
So people could use a bit more elaborated expression to find them.
Things like this shouldn't be a reason for not applying
EAPI/GLEPs/PM-behaviour changes. If this GLEP is
On Tuesday 18 of December 2007 18:37:11 Ulrich Mueller wrote:
One example was mentioned in this thread before: You cannot use
find -name '*.ebuild' anymore.
This should really be one of the last things to consider.
And as we have now learned that EAPI strings are not limited to digits
(see
On Tue, 18 Dec 2007, Piotr Jaroszynski wrote:
One example was mentioned in this thread before: You cannot use
find -name '*.ebuild' anymore.
This should really be one of the last things to consider.
On the contrary. If you want to force users to change their habits,
then it should be one of
On Tuesday, 18. December 2007 19:20:58 Joe Peterson wrote:
I also do not see why there are not other more elegant, transparent,
and automatic ways to determine EAPI without sourcing.
How much easier can it be? The extension scheme is simple and would do the
job nicely.
brainstorming, and
Fernando J. Pereda [EMAIL PROTECTED] posted
[EMAIL PROTECTED], excerpted below, on Tue, 18 Dec 2007
18:56:32 +0100:
And as we have now learned that EAPI strings are not limited to digits
(see ciaranm's message) and may even contain blanks (see grobian's
message), we would have ebuilds with
On Tue, Dec 18, 2007 at 07:45:44PM +, Duncan wrote:
Fernando J. Pereda [EMAIL PROTECTED] posted
[EMAIL PROTECTED], excerpted below, on Tue, 18 Dec 2007
18:56:32 +0100:
And as we have now learned that EAPI strings are not limited to digits
(see ciaranm's message) and may even contain
On Tuesday 18 of December 2007 19:51:54 Ulrich Mueller wrote:
This should really be one of the last things to consider.
On the contrary. If you want to force users to change their habits,
then it should be one of the first things to consider if this is
really necessary.
Simple users don't
On 18-12-2007 21:08:54 +0100, Piotr Jaroszyński wrote:
And as we have now learned that EAPI strings are not limited to digits
(see ciaranm's message) and may even contain blanks (see grobian's
message), we would have ebuilds with very strange filenames.
I think you misunderstood
On Tuesday 18 of December 2007 20:45:44 Duncan wrote:
How about when we have a dozen or so EAPIs active, several of which apply
to a specific ebuild?
Where is this idea of mixing EAPIs coming from? It really doesn't make much
sense.
--
Best Regards,
Piotr Jaroszyński
--
[EMAIL PROTECTED]
On 18-12-2007 10:03:56 +, Ciaran McCreesh wrote:
However, because features need not to include previous ones (why
would they?), in the Prefix branch of Portage I implemented EAPI to
be a space separated list. I merely did this because EAPI=1 ebuilds
needed to be tagged as such in an
On 2007/12/18, Bo Ørsted Andresen [EMAIL PROTECTED] wrote:
On Tuesday 18 December 2007 01:36:51 Thomas de Grenier de Latour
wrote:
Why can't it be in the file but readable without sourcing? For
instance, it could be mandatory that EAPI=X, if present, must be
the first non-blank and
On 2007/12/18, Ciaran McCreesh [EMAIL PROTECTED] wrote:
Well, users shouldn't really be doing anything with .ebuild files...
As a user, i often end reading part of some ebuilds to get a clue about
what the generic foo USE flag does in a particular package (qgrep -A3
-B2 -Nx '\foo\' cat/pkg-ver
On Tuesday 18 of December 2007 22:08:52 Thomas de Grenier de Latour wrote:
extensions for that. A single one is enough: just call files which
use the rule i've proposed foo.gbuild instead of foo.ebuild,
or .ebuild-ng.
--
Best Regards,
Piotr Jaroszyński
--
[EMAIL PROTECTED] mailing list
On Tuesday, 18. December 2007 22:32:03 Piotr Jaroszyński wrote:
or .ebuild-ng.
/me votes for .ebuild-TOS. ;)
--
Best regards, Wulf Sorry, couldn't resist. Krueger :)
signature.asc
Description: This is a digitally signed message part.
Piotr Jaroszyński [EMAIL PROTECTED] posted
[EMAIL PROTECTED], excerpted below, on Tue, 18 Dec 2007
21:11:20 +0100:
On Tuesday 18 of December 2007 20:45:44 Duncan wrote:
How about when we have a dozen or so EAPIs active, several of which
apply to a specific ebuild?
Where is this idea of
On Tue, 18 Dec 2007 21:38:08 +0100
Fabian Groffen [EMAIL PROTECTED] wrote:
Just to have it spelt out, what you suggest here is that EAPI has a
single value, a word or a number, that refers to a set of features
and rules, if I understand correctly.
With this way of using EAPI I fail to see
On Tue, 18 Dec 2007 23:50:22 + (UTC)
Duncan [EMAIL PROTECTED] wrote:
Piotr Jaroszyński [EMAIL PROTECTED] posted
[EMAIL PROTECTED], excerpted below, on Tue, 18 Dec
2007 21:11:20 +0100:
On Tuesday 18 of December 2007 20:45:44 Duncan wrote:
How about when we have a dozen or so EAPIs
On Tue, 18 Dec 2007 22:08:52 +0100
Thomas de Grenier de Latour [EMAIL PROTECTED] wrote:
There's no need to introduce a potential infinity of new files
extensions for that. A single one is enough: just call files which
use the rule i've proposed foo.gbuild instead of foo.ebuild, and
you're
On Tue, 18 Dec 2007 16:45:01 +0100
Marius Mauch [EMAIL PROTECTED] wrote:
There is one significant problem not covered in the GLEP: If a package
contains an ebuild with a suffixed extension then all developers ever
working on that _package_ must use tools that can handle such ebuilds,
otherwise
On 2007/12/19, Ciaran McCreesh [EMAIL PROTECTED] wrote:
On Tue, 18 Dec 2007 22:08:52 +0100
Thomas de Grenier de Latour [EMAIL PROTECTED] wrote:
There's no need to introduce a potential infinity of new files
extensions for that. A single one is enough: just call files which
use the rule
33 matches
Mail list logo
