-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2009.06.07 10:34, Ulrich Mueller wrote:
> > On Sun, 07 Jun 2009, Steven J Long wrote:
>
> > I'd just like to know what the implications would be for users if
> we
> > kept the .ebuild extension, and a new PMS were rolled out stating
> > that t
Patrick Lauer wrote:
And if you really absolutely have to do that you can change the sync
location on every disruptive change, but (imo) that should be
avoided.
If mirroring and other practical concerns weren't an issue what you're
essentially describing is just moving to a CVS/git/etc reposit
Richard Freeman posted 4a2baaa9.4030...@gentoo.org,
excerpted below, on Sun, 07 Jun 2009 07:55:21 -0400:
> As far as an upgrade path goes - we could provide a one-time tarball
> that will update portage (and its essential dependencies) to a version
> that can get users out of this bind. If a us
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ulrich Mueller wrote:
>> On Sun, 07 Jun 2009, Steven J Long wrote:
>
>> I'd just like to know what the implications would be for users if we
>> kept the .ebuild extension, and a new PMS were rolled out stating
>> that the mangler were allowed to fi
On Sunday 07 June 2009 11:34:12 Ulrich Mueller wrote:
> > On Sun, 07 Jun 2009, Steven J Long wrote:
> >
> > I'd just like to know what the implications would be for users if we
> > kept the .ebuild extension, and a new PMS were rolled out stating
> > that the mangler were allowed to find the EA
Ulrich Mueller wrote:
Let's assume for the moment that we change from ".ebuild" to ".eb".
Then we obviously cannot change all ebuilds in the tree to ".eb",
otherwise old Portage versions would see an empty tree and there would
be no upgrade path.
Or am I missing something?
That is a good poin
> On Sun, 07 Jun 2009, Steven J Long wrote:
> I'd just like to know what the implications would be for users if we
> kept the .ebuild extension, and a new PMS were rolled out stating
> that the mangler were allowed to find the EAPI without sourcing (and
> giving the restrictions) once portage
Roy Bamford wrote:
> I've spent some time reading all of this years emails on GLEP55 and
> added a few lines to version 1.5 which is the last offical version.
>
Thanks for all the hard work.
My apologies for my mistaken comment at the end of the last Council meeting.
Clearly the mangler /does/ nee
Michael Haubenwallner posted
1243610264.27150.293.ca...@sapc154.salomon.at, excerpted below, on Fri,
29 May 2009 17:17:44 +0200:
> Wouldn't it be possible to avoid both the extension change and another
> extended wait period for new incompatible(*) EAPIs, when we do this
> early and silent exit
On Fri, 2009-05-29 at 10:42 +, Duncan wrote:
> Michael Haubenwallner posted on Fri, 29
> May 2009 10:14:46 +0200:
>
> > Ohw, the latter would be necessary here, or '4.ebuild' would not be
> > found.
>
> s/4.ebuild/4.eclass/ I assume.
Indeed.
> Except... since an ebuild must presently be
Michael Haubenwallner posted
1243584886.27150.33.ca...@sapc154.salomon.at, excerpted below, on Fri, 29
May 2009 10:14:46 +0200:
> Ohw, the latter would be necessary here, or '4.ebuild' would not be
> found.
s/4.ebuild/4.eclass/ I assume.
> Btw.: What do non-EAPI-aware PMs do with ebuilds using
On Thu, 2009-05-28 at 19:17 +0200, Michael Haubenwallner wrote:
> inherit eapi 4
>
> Now when the PM is capable of pre-source EAPI detection, it will set
> EAPI before sourcing, eapi.eclass can see EAPI already being set and not
> do the 'exit' in global scope. Or even the PM's inherit-implem
2009/5/18 Steven J Long :
> David Leverton wrote:
>
>> 2009/5/17 Ben de Groot :
>>> I think the way eapi-2 was introduced into the tree wasn't particularly
>>> problematic.
>>
>> I think there might be a misunderstanding here. Ciaran means functions
>> provided by the package manager that ebuilds c
On Mon, 18 May 2009 17:42:19 +0200
Robert Buchholz wrote:
> I'm not following. Why should it be discouraged?
> I was happy with it until now.
Versionator is a lot better than what people were doing before I wrote
it. It's just nowhere near as good as what a package manager provided
solution comb
On Monday 18 May 2009, Jeroen Roovers wrote:
> On Mon, 18 May 2009 16:16:46 +0100
>
> Ciaran McCreesh wrote:
> > Why do you think I wrote the awful hack that is versionator?
>
> Why don't you explain why, historically, you put that in the tree? It
> would help us now if you were to simply record y
On Mon, 18 May 2009 17:28:00 +0200
Jeroen Roovers wrote:
> On Mon, 18 May 2009 16:16:46 +0100
> Ciaran McCreesh wrote:
> > Why do you think I wrote the awful hack that is versionator?
>
> Why don't you explain why, historically, you put that in the tree? It
> would help us now if you were to sim
Ciaran McCreesh wrote:
> On Mon, 18 May 2009 16:07:20 +0100
> Steven J Long wrote:
>> I missed the clamour of developers complaining about this
>> oh-so-burdensome restriction that they've been dealing with for at
>> least 5 years.
>
> Why do you think I wrote the awful hack that is versionator?
David Leverton wrote:
> 2009/5/17 Ben de Groot :
>> I think the way eapi-2 was introduced into the tree wasn't particularly
>> problematic.
>
> I think there might be a misunderstanding here. Ciaran means functions
> provided by the package manager that ebuilds can call during metadata
> generat
On Mon, 18 May 2009 16:16:46 +0100
Ciaran McCreesh wrote:
> Why do you think I wrote the awful hack that is versionator?
Why don't you explain why, historically, you put that in the tree? It
would help us now if you were to simply record your mistakes for
everybody else to easily avoid. It's sti
On Mon, 18 May 2009 16:07:20 +0100
Steven J Long wrote:
> I missed the clamour of developers complaining about this
> oh-so-burdensome restriction that they've been dealing with for at
> least 5 years.
Why do you think I wrote the awful hack that is versionator?
Anything that finally lets us kil
Joe Peterson wrote:
> Ciaran McCreesh wrote:
>>> 3. "Extend versioning rules in an EAPI - for example, addition of the
>>> scm suffix - GLEP54 [1] or allowing more sensible version formats like
>>> 1-rc1, 1-alpha etc. to match upstream more closely."
>>> Apart from GLEP54, I believe our versioning
Just a heads up that I wrote a more detailed description of the
peformance hit that EAPI in the ebuild introduces.
Might come up with some numbers later too.
[1] -
http://dev.gentoo.org/~peper/glep-0055.html#easily-fetchable-eapi-inside-the-ebuild
--
Best Regards,
Piotr Jaroszyński
On Sun, 17 May 2009 19:18:14 +0100
Ciaran McCreesh wrote:
> On Sun, 17 May 2009 12:15:24 -0600
> Ryan Hill wrote:
> > I'd like 2 if we could have multiple same-versioned ebuilds of
> > different EAPI. 3 is good enough for me.
>
> We couldn't. Allowing multiple equal but different ebuilds gets
On Sun, 17 May 2009 12:15:24 -0600
Ryan Hill wrote:
> I'd like 2 if we could have multiple same-versioned ebuilds of
> different EAPI. 3 is good enough for me.
We couldn't. Allowing multiple equal but different ebuilds gets highly
crazy -- EAPIs aren't orderable, so it's not obvious which one th
2009/5/17 Ryan Hill :
> On Sun, 17 May 2009 17:56:06 +0200
> Piotr Jaroszyński wrote:
>
>> Hello,
>>
>> I have just updated GLEP 55 [1], hopefully making it a bit clearer.
>>
>> Just FYI, my order of preference of solutions is:
>>
>> 1. EAPI-suffixed ebuilds (obviously)
>> 2. EAPI in the filename
On Sun, 17 May 2009 17:56:06 +0200
Piotr Jaroszyński wrote:
> Hello,
>
> I have just updated GLEP 55 [1], hopefully making it a bit clearer.
>
> Just FYI, my order of preference of solutions is:
>
> 1. EAPI-suffixed ebuilds (obviously)
> 2. EAPI in the filename with one-time extension change
>
Fernando J. Pereda wrote:
On 10 Jun 2008, at 15:33, Joe Peterson wrote:
Luca Barbato wrote:
Check if exists a line EAPI=*$, if does and the rest of the string
matches an understood eapi, go on sourcing, otherwise ignore/mask it...
And placing it out-of-band (like "# EAPI=...") avoids any so
"Santiago M. Mola" <[EMAIL PROTECTED]> wrote:
> On Thu, Jun 12, 2008 at 4:07 AM, Jim Ramsay <[EMAIL PROTECTED]> wrote:
> > Why not just bump the filename suffix when it is required to
> > support a new EAPI that breaks the sourcing rules of previous EAPIs?
> >
> > Or will backwards-incompatible cha
On 2008-06-10 15:50, Fernando J. Pereda uttered these thoughts:
>
> On 10 Jun 2008, at 15:46, Joe Peterson wrote:
>> Also, I'm not sure reading XML is a problem at all - python has good
>> libs for this already.
>
> Reading XML files is easy, but it makes certain codepaths much much slower.
> Not
Duncan <[EMAIL PROTECTED]> posted [EMAIL PROTECTED],
excerpted below, on Wed, 11 Jun 2008 12:52:24 +:
> Ciaran McCreesh <[EMAIL PROTECTED]> posted
> [EMAIL PROTECTED], excerpted below, on Tue, 10 Jun
> 2008 15:00:18 +0100:
>
>> On Tue, 10 Jun 2008 09:49:04 -0400
>> Richard Freeman <[EMAIL P
On Thu, Jun 12, 2008 at 4:07 AM, Jim Ramsay <[EMAIL PROTECTED]> wrote:
> Why not just bump the filename suffix when it is required to support a
> new EAPI that breaks the sourcing rules of previous EAPIs?
>
> Or will backwards-incompatible changes be happening so frequently that
> the package suffi
On Wed, Jun 11, 2008 at 12:05 PM, Olivier Galibert <[EMAIL PROTECTED]> wrote:
> On Tue, Jun 10, 2008 at 03:14:47PM +0100, Ciaran McCreesh wrote:
>>
>
> *Then* would be the time to change the extension. As long as the
> ebuild is bash-parseable with an appropriate environment, it doesn't
> make se
Olivier Galibert <[EMAIL PROTECTED]> wrote:
> On Tue, Jun 10, 2008 at 03:14:47PM +0100, Ciaran McCreesh wrote:
> >
>
> *Then* would be the time to change the extension. As long as the
> ebuild is bash-parseable with an appropriate environment, it doesn't
> make sense to change the extension beca
Ciaran McCreesh <[EMAIL PROTECTED]> posted
[EMAIL PROTECTED], excerpted below, on Tue, 10 Jun
2008 15:00:18 +0100:
> On Tue, 10 Jun 2008 09:49:04 -0400
> Richard Freeman <[EMAIL PROTECTED]> wrote:
>> 4) Putting EAPI inside the ebuild, but in a manner that does not
>> require sourcing using bash (
On Wed, Jun 11, 2008 at 12:06 PM, Ciaran McCreesh
<[EMAIL PROTECTED]> wrote:
> On Wed, 11 Jun 2008 08:31:45 +0200
> Thomas de Grenier de Latour <[EMAIL PROTECTED]> wrote:
>> On 2008/06/11, Ciaran McCreesh <[EMAIL PROTECTED]> wrote:
>> > You're missing the cases where the cache isn't usable.
>>
>> I
On Tue, Jun 10, 2008 at 03:14:47PM +0100, Ciaran McCreesh wrote:
>
*Then* would be the time to change the extension. As long as the
ebuild is bash-parseable with an appropriate environment, it doesn't
make sense to change the extension because a env-variable set or a
comment are more natural met
On Wed, Jun 11, 2008 at 04:14:58AM +0100, Ciaran McCreesh wrote:
> On Tue, 10 Jun 2008 19:14:11 +0200
> Olivier Galibert <[EMAIL PROTECTED]> wrote:
> > On Tue, Jun 10, 2008 at 03:02:28PM +0100, Ciaran McCreesh wrote:
> > > Except that currently, the ebuild file isn't opened for read. So
> > > it's
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mike Kelly wrote:
| Wrong.
Thanks for that. I'm gonna assume you meant "I think you're wrong".
| Sure, because of how the algorithm works, people could potentially do
| both, but the GLEP makes it pretty clear that they shouldn't.
It doesn't just
On Wed, 11 Jun 2008 08:31:45 +0200
Thomas de Grenier de Latour <[EMAIL PROTECTED]> wrote:
> On 2008/06/11, Ciaran McCreesh <[EMAIL PROTECTED]> wrote:
> > You're missing the cases where the cache isn't usable.
>
> I was not talking about generating cache entries, and neither were
> you. I've replie
On 2008/06/11, Ciaran McCreesh <[EMAIL PROTECTED]> wrote:
> You're missing the cases where the cache isn't usable.
>
I was not talking about generating cache entries, and neither were you.
I've replied to you because you were suggesting that the "EAPI in
ebuilds contents" solution had extra cost
On Wed, 11 Jun 2008 09:52:17 +0530
"Arun Raghavan" <[EMAIL PROTECTED]> wrote:
> On Wed, Jun 11, 2008 at 8:44 AM, Ciaran McCreesh
> <[EMAIL PROTECTED]> wrote:
> [...]
> >> Why would you need the EAPI before the time when you actually want
> >> to interpret the contents?
> >
> > You need the EAPI bef
On Wed, Jun 11, 2008 at 8:44 AM, Ciaran McCreesh
<[EMAIL PROTECTED]> wrote:
[...]
>> Why would you need the EAPI before the time when you actually want to
>> interpret the contents?
>
> You need the EAPI before you use the metadata. But you don't need the
> ebuild to get the metadata in the common
On Tue, 10 Jun 2008 19:14:11 +0200
Olivier Galibert <[EMAIL PROTECTED]> wrote:
> On Tue, Jun 10, 2008 at 03:02:28PM +0100, Ciaran McCreesh wrote:
> > Except that currently, the ebuild file isn't opened for read. So
> > it's not in memory at all.
>
> Why would you need the EAPI before the time when
On Wed, 11 Jun 2008 01:36:01 +0200
Thomas de Grenier de Latour <[EMAIL PROTECTED]> wrote:
> Or you apply to future EAPI's cache formats one of the solutions that
> have been proposed for the ebuild side of the very same "chicken / egg
> problem": for instance, you could use $EAPI as cache filename
Bernd Steinhauser <[EMAIL PROTECTED]> posted
[EMAIL PROTECTED], excerpted below, on Tue, 10 Jun
2008 05:46:47 +0200:
> No, not really. If you have .txt, .txt-2, .text or .footext in a dir,
> you would still realize, that those should be text files.
The first three, yes, by long tradition, footex
On 2008/06/10, Ciaran McCreesh <[EMAIL PROTECTED]> wrote:
> Currently we don't touch the ebuild's content *at all* for metadata
> operations, except where there's no or stale metadata cache (which is
> rare). We can get away with this currently because 0 and 1 have
> identical cache layouts and PM
Richard Freeman wrote:
> On the other hand, this is a big change from the present, and I'm not
> convinced that it will actually be a big improvement over some of the
> other EAPI ideas being floated around. However, it is a
> potentially-neat idea...
Rich, interesting thoughts! But yeah, I a
Santiago M. Mola wrote:
On Tue, Jun 10, 2008 at 10:20 PM, Federico Ferri <[EMAIL PROTECTED]> wrote:
The so-called shebang; very good in my opinion!
Works very well for true shell scripts. why it can't work for ebuilds?
This option was already discussed when GLEP 55 was proposed, and in my
opi
Mike Auty wrote:
The speed issues aren't really a concern, since the GLEP suggests that
the ebuild must be sourced anyway. The GLEP allows for a .ebuild-2 file
to contain EAPI="1".
Wrong. From the GLEP: "note that one should *never* explicitly set both
EAPIs to different values."
Basically
On Tue, Jun 10, 2008 at 10:20 PM, Federico Ferri <[EMAIL PROTECTED]> wrote:
>
> The so-called shebang; very good in my opinion!
>
> Works very well for true shell scripts. why it can't work for ebuilds?
This option was already discussed when GLEP 55 was proposed, and in my
opinion it's totally dis
Joe Peterson ha scritto:
It was mentioned that "comments are to be ignored", but you point out a
perfect and very fundamental example of where this is not true:
#!/usr/bin/env bash
Putting another line close to this one with:
#EAPI=42
or
#!EAPI=42
if you like (conforms more to the shell scr
Olivier Galibert a écrit :
On Tue, Jun 10, 2008 at 12:01:00PM +0200, Rémi Cardona wrote:
Ciaran McCreesh a écrit :
Kills the upgrade path completely. No good.
Lemme sum this up in layman's terms :
1) EAPI _has_ to be known before sourcing an ebuild. There's no way to
avoid that for various r
On Tue, Jun 10, 2008 at 03:02:28PM +0100, Ciaran McCreesh wrote:
> Except that currently, the ebuild file isn't opened for read. So it's
> not in memory at all.
Why would you need the EAPI before the time when you actually want to
interpret the contents?
OG.
--
gentoo-dev@lists.gentoo.org ma
On Tue, Jun 10, 2008 at 12:01:00PM +0200, Rémi Cardona wrote:
> Ciaran McCreesh a écrit :
> >Kills the upgrade path completely. No good.
>
> Lemme sum this up in layman's terms :
>
> 1) EAPI _has_ to be known before sourcing an ebuild. There's no way to
> avoid that for various reasons, all 100%
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
| No, it results in a new open() on a file that's elsewhere on disk, which
| results in two new seeks. You get about fifty seeks per second.
The speed issues aren't really a concern, since the GLEP suggests that
the ebuild must
On Tue, 10 Jun 2008 11:08:21 -0400
Richard Freeman <[EMAIL PROTECTED]> wrote:
> I'm curious as to what operation in particular we're looking at.
> Let's say I type in "paludis --sync":
paludis --sync doesn't use metadata.
> Next, suppose I type in "paludis -pi world":
If it's straight after a --
Ciaran McCreesh wrote:
On Tue, 10 Jun 2008 19:40:22 +0530
"Arun Raghavan" <[EMAIL PROTECTED]> wrote:
On Tue, Jun 10, 2008 at 7:32 PM, Ciaran McCreesh
<[EMAIL PROTECTED]> wrote:
[...]
I don't think that filename-vs-first-line is going to make a big
difference in practical performance.
It's abou
On 10 Jun 2008, at 16:14, Ciaran McCreesh wrote:
On Tue, 10 Jun 2008 19:38:52 +0530
"Arun Raghavan" <[EMAIL PROTECTED]> wrote:
On Tue, Jun 10, 2008 at 7:30 PM, Ciaran McCreesh
<[EMAIL PROTECTED]> wrote:
[...]
- it doubles the number of file reads necessary during resolution.
The first read
Ciaran McCreesh a écrit :
No no. Doing the seek to open a file in a different directory and then
seeking back to your original directory over and over when otherwise
you'd be doing nice linear opens on adjacent inodes in a single
directory is where the performance hit is.
Paludis is pretty much
On Tue, 10 Jun 2008 19:54:33 +0530
"Arun Raghavan" <[EMAIL PROTECTED]> wrote:
> Well, most file systems have a local structure for this data (=> block
> group), so it's not going to be a seek that's very far. Secondly, how
> many ebuilds do you need to read directly to get this data in a
> typical
On Tue, 10 Jun 2008 16:11:49 +0200
Rémi Cardona <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh a écrit :
> > The package manager does not currently source the whole thing with
> > bash to get the EAPI, nor does it open the ebuild file at all for
> > metadata. You're talking doubling the number of fil
On Tue, 10 Jun 2008 19:40:22 +0530
"Arun Raghavan" <[EMAIL PROTECTED]> wrote:
> On Tue, Jun 10, 2008 at 7:32 PM, Ciaran McCreesh
> <[EMAIL PROTECTED]> wrote:
> [...]
> >> I don't think that filename-vs-first-line is going to make a big
> >> difference in practical performance.
> >
> > It's about a
On Tue, Jun 10, 2008 at 7:44 PM, Ciaran McCreesh
<[EMAIL PROTECTED]> wrote:
[...]
>> The first read will cause the file to be cached for subsequent reads
>> anyway, so the performance hit boils down to an additional read() call
>> (which will probably be buffered by your file I/O library anyway, so
Richard Freeman wrote:
> Some object to parsing out the EAPI without sourcing the ebuild (only
> bash can source bash). I disagree with this argument - every time you
> run a shell script it is sourced by something other than bash - the
> kernel has to figure out what script interpreter to use
On Tue, 10 Jun 2008 19:38:52 +0530
"Arun Raghavan" <[EMAIL PROTECTED]> wrote:
> On Tue, Jun 10, 2008 at 7:30 PM, Ciaran McCreesh
> <[EMAIL PROTECTED]> wrote:
> [...]
> > - it doubles the number of file reads necessary during resolution.
>
> The first read will cause the file to be cached for subse
Ciaran McCreesh a écrit :
The package manager does not currently source the whole thing with
bash to get the EAPI, nor does it open the ebuild file at all for
metadata. You're talking doubling the number of file operations here,
and going from extremely good filesystem locality (which means very
Fernando J. Pereda wrote:
On 10 Jun 2008, at 15:48, Luca Barbato wrote:
Fernando J. Pereda wrote:
No, it doesn't make parsing faster. *Had you bothered to profile any
package manager you'd know that.*
Do you have any number to share?
What number are you interested in?
Profiling numbers.
On Tue, Jun 10, 2008 at 7:32 PM, Ciaran McCreesh
<[EMAIL PROTECTED]> wrote:
[...]
>> I don't think that filename-vs-first-line is going to make a big
>> difference in practical performance.
>
> It's about a factor of five difference in cold-cache resolution
> performance for Paludis.
Could you ple
On Tue, Jun 10, 2008 at 7:30 PM, Ciaran McCreesh
<[EMAIL PROTECTED]> wrote:
[...]
> - it doubles the number of file reads necessary during resolution.
The first read will cause the file to be cached for subsequent reads
anyway, so the performance hit boils down to an additional read() call
(which
On Tue, 10 Jun 2008 09:56:18 -0400
Richard Freeman <[EMAIL PROTECTED]> wrote:
> Joe Peterson wrote:
> > No, I have not profiled PMs to try this, but you are saying that
> > reading the first few lines of a file is not faster than sourcing
> > the whole thing with bash? Remember that it could abort
On Tue, 10 Jun 2008 09:49:04 -0400
Richard Freeman <[EMAIL PROTECTED]> wrote:
> 4) Putting EAPI inside the ebuild, but in a manner that does not
> require sourcing using bash (ie comment at top of file).
>
> + it solves 1)
> + it keeps pretty file names
> + syntax/implementation is trivial
> - it
On Tue, 10 Jun 2008 07:49:31 -0600
Joe Peterson <[EMAIL PROTECTED]> wrote:
> > No, it doesn't make parsing faster. Had you bothered to profile
> > any package manager you'd know that.
>
> No, I have not profiled PMs to try this, but you are saying that
> reading the first few lines of a file is no
Joe Peterson wrote:
No, I have not profiled PMs to try this, but you are saying that reading
the first few lines of a file is not faster than sourcing the whole
thing with bash? Remember that it could abort the minute it sees a non
'#' or blank line, which would be after the first few.
Actua
On 10 Jun 2008, at 15:48, Luca Barbato wrote:
Fernando J. Pereda wrote:
No, it doesn't make parsing faster. Had you bothered to profile any
package manager you'd know that.
Do you have any number to share?
What number are you interested in?
- ferdy
--
gentoo-dev@lists.gentoo.org mailing
Rémi Cardona wrote:
Ciaran McCreesh a écrit :
Kills the upgrade path completely. No good.
Lemme sum this up in layman's terms :
1) EAPI _has_ to be known before sourcing an ebuild. There's no way to
avoid that for various reasons, all 100% valid.
2) Putting the EAPI in the filename :
+ i
On 10 Jun 2008, at 15:46, Joe Peterson wrote:
Also, I'm not sure reading XML is a problem at all - python has good
libs for this already.
Reading XML files is easy, but it makes certain codepaths much much
slower. Not a good 'feature'.
- ferdy
--
gentoo-dev@lists.gentoo.org mailing list
Fernando J. Pereda wrote:
> On 10 Jun 2008, at 15:33, Joe Peterson wrote:
>
>> Luca Barbato wrote:
>>> Check if exists a line EAPI=*$, if does and the rest of the string
>>> matches an understood eapi, go on sourcing, otherwise ignore/mask
>>> it...
>> And placing it out-of-band (like "# EAPI=..
Fernando J. Pereda wrote:
No, it doesn't make parsing faster. Had you bothered to profile any
package manager you'd know that.
Do you have any number to share?
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org ma
Rémi Cardona wrote:
> Ciaran McCreesh a écrit :
>> Kills the upgrade path completely. No good.
>
> Lemme sum this up in layman's terms :
>
> 1) EAPI _has_ to be known before sourcing an ebuild. There's no way to
> avoid that for various reasons, all 100% valid.
>
> 2) Putting the EAPI in the fi
On 10 Jun 2008, at 15:33, Joe Peterson wrote:
Luca Barbato wrote:
Check if exists a line EAPI=*$, if does and the rest of the string
matches an understood eapi, go on sourcing, otherwise ignore/mask
it...
And placing it out-of-band (like "# EAPI=...") avoids any sourcing
errors, makes pars
Luca Barbato wrote:
> Check if exists a line EAPI=*$, if does and the rest of the string
> matches an understood eapi, go on sourcing, otherwise ignore/mask it...
And placing it out-of-band (like "# EAPI=...") avoids any sourcing
errors, makes parsing faster, etc.
-Joe
--
Rémi Cardona wrote:
> Ciaran McCreesh a écrit :
>> picard_facepalm.jpg
>
> I don't think any of us are completely thrilled by either proposals, but
> the EAPI-in-a-separate-file does have the potential for more
> flexibility, ie package-wide EAPI.
>
> And it does keep filenames simple enough.
Tiziano Müller wrote:
>>> And then how do we deal with EAPI 3, where the syntax changes again?
>> Portage (or whatever PM) reads the EAPI, determines it is 3, and goes
>> from there. If you change the way you declare EAPI each time, yeah,
>> that's a problem, but I'm not sure why that would ne nec
On 10 Jun 2008, at 12:30, Rémi Cardona wrote:
Ciaran McCreesh a écrit :
picard_facepalm.jpg
I don't think any of us are completely thrilled by either proposals,
but the EAPI-in-a-separate-file does have the potential for more
flexibility, ie package-wide EAPI.
And it does keep filename
Ciaran McCreesh a écrit :
picard_facepalm.jpg
I don't think any of us are completely thrilled by either proposals, but
the EAPI-in-a-separate-file does have the potential for more
flexibility, ie package-wide EAPI.
And it does keep filenames simple enough.
--
Rémi Cardona
LRI, INRIA
[EMAIL
Ciaran McCreesh a écrit :
Kills the upgrade path completely. No good.
Lemme sum this up in layman's terms :
1) EAPI _has_ to be known before sourcing an ebuild. There's no way to
avoid that for various reasons, all 100% valid.
2) Putting the EAPI in the filename :
+ it solves 1)
+ it kee
On Tue, 10 Jun 2008 11:40:35 +0200
Luca Barbato <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote:
> > Kills the upgrade path completely. No good.
>
> Not really, you change the rsync paths and older portage will pick a
> repo that just has the necessary to upgrade to the next portage.
>
> This
Tiziano Müller wrote:
Joe Peterson wrote:
Ciaran McCreesh wrote:
And a file extension is far less obscurely complex than enforcing
arbitrary syntax restrictions upon ebuilds.
I disagree. One is exposed to devs only as ebuild syntax; the other is
exposed in an inappropriate location to everyo
Ciaran McCreesh wrote:
Kills the upgrade path completely. No good.
Not really, you change the rsync paths and older portage will pick a
repo that just has the necessary to upgrade to the next portage.
This kind of things would work better using an scm supporting branches
and tags a bit bett
Tiziano Müller wrote:
Another ugly solution: Having the EAPI on a per-package (like
$portagedir/cat/package-1) or per-tree basis ($portagedir/profiles/eapi)
I like the per tree basis and I already asked about that (since makes
things clearer and older portage can be tricked by rsync.
lu
--
On Tue, 10 Jun 2008 10:33:34 +0200
Tiziano Müller <[EMAIL PROTECTED]> wrote:
> Another ugly solution: Having the EAPI on a per-package (like
> $portagedir/cat/package-1) or per-tree basis
> ($portagedir/profiles/eapi) and start providing our tree as overlays
> of more than one tree (will end up in
Ciaran McCreesh wrote:
> On Mon, 9 Jun 2008 22:35:25 -0700
> Donnie Berkholz <[EMAIL PROTECTED]> wrote:
>> Did anyone already propose specifying this in metadata.xml?
>
> Yup. That's a no-go, since metadata.xml is quite rightly treated as
> being "not suitable for anything the package manager rea
Joe Peterson wrote:
> Ciaran McCreesh wrote:
>> And a file extension is far less obscurely complex than enforcing
>> arbitrary syntax restrictions upon ebuilds.
>
> I disagree. One is exposed to devs only as ebuild syntax; the other is
> exposed in an inappropriate location to everyone looking a
Piotr Jaroszy?ski wrote:
> On Saturday 22 of December 2007 02:41:02 Petteri Räty wrote:
>> Piotr Jaroszy?ski kirjoitti:
>> > This GLEP proposes usage of EAPI-suffixed file extensions for ebuilds
>> > (for example, foo-1.2.3.ebuild-1).
>>
>> It seems many people don't like the idea of having it in
94 matches
Mail list logo
