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
> > us
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
>
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,
> othe
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
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 t
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 ide
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.
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 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 '\' cat/pkg-ver
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 a
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 suc
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
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] ma
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 do
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
"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 ebuild
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, an
> 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 shoul
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
> (
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 t
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 so
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 s
> 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
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 lead
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
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 pa
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
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 requiri
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, 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
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
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 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 *shou
33 matches
Mail list logo