Ciaran McCreesh wrote:
Because your proposal addresses none of the underlying problems which
GLEP 55 was created to solve.
As said long ago the glep doesn't tell enough:
"The current way of specifying the EAPI in ebuilds is flawed. In order
to get the EAPI the package manager needs to source
Luca Barbato wrote:
Ciaran McCreesh wrote:
Because your proposal addresses none of the underlying problems which
GLEP 55 was created to solve.
let's get some numbers to have an idea of the dimension of the problem.
domino portage # wc -l /dev/shm/eapi_files.list
2854 /dev/shm/eapi_files.list
Luca Barbato wrote:
> Luca Barbato wrote:
>> Ciaran McCreesh wrote:
>>> Because your proposal addresses none of the underlying problems which
>>> GLEP 55 was created to solve.
>
> let's get some numbers to have an idea of the dimension of the problem.
>
I just don't think those numbers tell us a
(Ok this thread grew too long, so I gotta chime in :))
We could start using extended attributes or mandate reiser4 for portage dir or
some other special "in between" (the inside of file and its name) feature..
Sorry for the noise and insane "implementation" suggestion :)..
George
PS
Actually,
Alistair Bush wrote:
I just don't think those numbers tell us anything and that should be
obvious from anyone who has read GLEP 55[1], we ain't really attempting
to solve a problem that exists within the tree currently (well the bash
issue does, in a way ). We are trying to solve issues that war
George Shapovalov wrote:
> (Ok this thread grew too long, so I gotta chime in :))
>
> We could start using extended attributes or mandate reiser4 for portage dir
> or
> some other special "in between" (the inside of file and its name) feature..
No.
1) I wouldn't use reiser4 so that would be the
Luca Barbato wrote:
> Alistair Bush wrote:
>> I just don't think those numbers tell us anything and that should be
>> obvious from anyone who has read GLEP 55[1], we ain't really attempting
>> to solve a problem that exists within the tree currently (well the bash
>> issue does, in a way ). We a
Alistair Bush wrote:
Luca Barbato wrote:
Alistair Bush wrote:
I just don't think those numbers tell us anything and that should be
obvious from anyone who has read GLEP 55[1], we ain't really attempting
to solve a problem that exists within the tree currently (well the bash
issue does, in a w
On Tue, 24 Feb 2009 08:08:23 +0100
Luca Barbato wrote:
> Is there any technical merit in putting eapi in the file extension
> while we could restrict the format the same way in file and have
> about the same, negligible, performance hit? (I used warm cache since
> you need the file anyway so you d
Alistair Bush wrote:
4) Parsing the ebuild. But what are we parsing?, lets not limit
ourselves to bash, we might want to change languages completely. If it
is bash, what version, what if EAPI is set multiple times, what if its
set in an eclass.
How do you do this if you're getting EAPI fr
On Tue, 24 Feb 2009 10:46:30 -0500
Richard Freeman wrote:
> I will certainly concede that putting it inside the ebuild
> potentially breaks compatibility with existing package managers.
> That is certainly a downside to this approach. However, none of the
> other objections that have been raised
Ciaran McCreesh wrote:
On Tue, 24 Feb 2009 08:08:23 +0100
Uh, your benchmarks are nonsense.
Provide your nonsensical ones.
That is not how metadata checks work.
Explain how they work, regen works that way...
By parsing the ebuilds you're talking doubling the number of file reads
required
On Tue, 24 Feb 2009 17:04:28 +0100
Luca Barbato wrote:
> Ciaran McCreesh wrote:
> > On Tue, 24 Feb 2009 08:08:23 +0100
> > Uh, your benchmarks are nonsense.
>
> Provide your nonsensical ones.
You're doubling the number of files that have to be read for an
operation that's almost purely i/o bound
On Tue, Feb 24, 2009 at 9:26 PM, Ciaran McCreesh
wrote:
> ...and it means we can't change name or version rules.
>
And has such a case come to light recently where it was *essential* to
do so? Why solve problems that don't exist?
> ...and it means over doubling the best possible time to work out
On Tue, 24 Feb 2009 21:59:39 +0530
Nirbheek Chauhan wrote:
> On Tue, Feb 24, 2009 at 9:26 PM, Ciaran McCreesh
> wrote:
> > ...and it means we can't change name or version rules.
>
> And has such a case come to light recently where it was *essential* to
> do so? Why solve problems that don't exis
Ciaran McCreesh wrote:
On Tue, 24 Feb 2009 17:04:28 +0100
Luca Barbato wrote:
Ciaran McCreesh wrote:
On Tue, 24 Feb 2009 08:08:23 +0100
Uh, your benchmarks are nonsense.
Provide your nonsensical ones.
You're doubling the number of files that have to be read for an
operation that's almost pu
Ciaran McCreesh wrote:
> On Tue, 24 Feb 2009 10:46:30 -0500
> Richard Freeman wrote:
> > I will certainly concede that putting it inside the ebuild
> > potentially breaks compatibility with existing package managers.
> > That is certainly a downside to this approach. However, none of the
> > oth
On Tue, 24 Feb 2009 12:25:27 -0500
Jim Ramsay wrote:
> > ...and it means we can't change name or version rules.
> >
> > ...and it means over doubling the best possible time to work out a
> > dependency tree in the common case where the metadata cache is
> > valid.
> >
> > ...and it means we can'
On Tue, 24 Feb 2009 18:16:54 +0100
Luca Barbato wrote:
> > You're doubling the number of files that have to be read for an
> > operation that's almost purely i/o bound. On top of that, you're
> > introducing a whole bunch of disk seeks in what's otherwise a nice
> > linear operation.
>
> I see wo
Ciaran McCreesh wrote:
> On Tue, 24 Feb 2009 12:25:27 -0500
> Jim Ramsay wrote:
> > > ...and it means we can't change name or version rules.
> > >
> > > ...and it means over doubling the best possible time to work out a
> > > dependency tree in the common case where the metadata cache is
> > > v
On Tue, 24 Feb 2009 14:08:45 -0500
Jim Ramsay wrote:
> But when you say "worth the complexity", I'm not exactly sure what
> your standards of "worthiness" are.
>
> I don't think the human cognition of a 2-level versioning scheme is
> that tricky, so I assume you must mean complexity in the intern
On Tue, 24 Feb 2009 18:24:16 +
Ciaran McCreesh wrote:
> On Tue, 24 Feb 2009 18:16:54 +0100
> Luca Barbato wrote:
> > > You're doubling the number of files that have to be read for an
> > > operation that's almost purely i/o bound. On top of that, you're
> > > introducing a whole bunch of dis
On Tue, 24 Feb 2009 20:28:43 +0100
Alexis Ballier wrote:
> On Tue, 24 Feb 2009 18:24:16 +
> Ciaran McCreesh wrote:
> > On Tue, 24 Feb 2009 18:16:54 +0100
> > Luca Barbato wrote:
> > > > You're doubling the number of files that have to be read for an
> > > > operation that's almost purely i/o
Ciaran McCreesh wrote:
> People are struggling with the one level scheme we have now. We're
> already having to produce fancy tables and summaries for new EAPIs
> because people can't keep track of when features came along. Two
> levels just means no-one will remember any of it.
I disagree with y
On Tue, 24 Feb 2009 15:07:29 -0500
Jim Ramsay wrote:
> Ciaran McCreesh wrote:
> > People are struggling with the one level scheme we have now. We're
> > already having to produce fancy tables and summaries for new EAPIs
> > because people can't keep track of when features came along. Two
> > leve
Ciaran McCreesh wrote:
..and it means we can't change name or version rules.
Why? Just parse the EAPI out of the file before you interpret the
version and name from the filename. Indeed - you could have a future
EAPI remove the name and version from the filename entirely. If a
package m
On Tue, 24 Feb 2009 15:17:01 -0500
Richard Freeman wrote:
> Why? Just parse the EAPI out of the file before you interpret the
> version and name from the filename. Indeed - you could have a future
> EAPI remove the name and version from the filename entirely. If a
> package manager doesn't u
Ciaran McCreesh wrote:
> On Tue, 24 Feb 2009 15:07:29 -0500
> Jim Ramsay wrote:
> > I think
> > things are very nicely documented in PMS and the devmanual, which
> > are where all EAPI changes should be documented in the future,
> > regardless if you specify the EAPI in the file, the extension, o
On Tue, 24 Feb 2009 15:37:36 -0500
Jim Ramsay wrote:
> > They only ended up nicely documented after people moaned a lot that
> > they were having a hard time keeping track of EAPIs...
>
> You can't possibly be suggesting that everyone will be able to keep an
> ever-increasing number of feature se
Ciaran McCreesh wrote:
> On Tue, 24 Feb 2009 15:37:36 -0500
> Jim Ramsay wrote:
> > > They only ended up nicely documented after people moaned a lot
> > > that they were having a hard time keeping track of EAPIs...
> >
> > You can't possibly be suggesting that everyone will be able to keep
> > a
Ciaran McCreesh wrote:
On Tue, 24 Feb 2009 15:17:01 -0500
Richard Freeman wrote:
Why? Just parse the EAPI out of the file before you interpret the
version and name from the filename. Indeed - you could have a future
EAPI remove the name and version from the filename entirely. If a
package
On Tue, 24 Feb 2009 22:46:17 +0100
Luca Barbato wrote:
> > It means opening a file that would otherwise not be opened at all.
> > And if the EAPI is in the file, you have to fish inside that file
> > to pull it out before you can work out whether the cache entry that
> > might contain the EAPI alr
Ciaran McCreesh wrote:
Not true. You don't know whether the cache is valid until you know what
the EAPI is.
If you are on the user scenario the cache is valid.
If the eapi changes the cache meaning you can always put the new cache
in another place older portage won't look into.
You:
- have
On Tue, 24 Feb 2009 23:48:27 +0100
Luca Barbato wrote:
> Ciaran McCreesh wrote:
> > Not true. You don't know whether the cache is valid until you know
> > what the EAPI is.
>
> If you are on the user scenario the cache is valid.
Uh. Wrong.
> > Can't use the cache until you know what the EAPI is
Ciaran McCreesh wrote:
On Tue, 24 Feb 2009 18:16:54 +0100
Luca Barbato wrote:
You're doubling the number of files that have to be read for an
operation that's almost purely i/o bound. On top of that, you're
introducing a whole bunch of disk seeks in what's otherwise a nice
linear operation.
I
Am Dienstag, den 24.02.2009, 22:58 + schrieb Ciaran McCreesh:
> On Tue, 24 Feb 2009 23:48:27 +0100
> Luca Barbato wrote:
> > Ciaran McCreesh wrote:
> > > Not true. You don't know whether the cache is valid until you know
> > > what the EAPI is.
> >
> > If you are on the user scenario the cach
On Tue, 24 Feb 2009 19:37:11 +
Ciaran McCreesh wrote:
> On Tue, 24 Feb 2009 20:28:43 +0100
> Alexis Ballier wrote:
> > On Tue, 24 Feb 2009 18:24:16 +
> > Ciaran McCreesh wrote:
> > > On Tue, 24 Feb 2009 18:16:54 +0100
> > > Luca Barbato wrote:
> > > > > You're doubling the number of fi
On Wed, 25 Feb 2009 07:34:41 +0100
Tiziano Müller wrote:
> Well, you could theoretical consider everything in the cache valid
> within the current scope, find the eapi within the cache or the ebuild
> and then reconsider things.
You can't even do that, because new EAPIs might change how cache
ent
On Wed, 25 Feb 2009 09:33:44 +0100
Alexis Ballier wrote:
> That sounds like an implementation detail that you could solve by
> using something else than a flat file database for metadata if
> open()/read() calls are the slow part.
Metadata's shipped with the tree. It's a PMS detail.
If we didn't
On Wed, 25 Feb 2009 04:04:46 +0100
Luca Barbato wrote:
> given that the simplest thing is hacking ebuild.sh and extract eapi
> with a simple C program (you can use pcre or ragel if you want)
> exactly before the ebuild source:
That you're bringing ebuild.sh into this shows you still haven't worke
Ciaran McCreesh wrote:
On Wed, 25 Feb 2009 04:04:46 +0100
Luca Barbato wrote:
given that the simplest thing is hacking ebuild.sh and extract eapi
with a simple C program (you can use pcre or ragel if you want)
exactly before the ebuild source:
That you're bringing ebuild.sh into this shows yo
On Wed, Feb 25, 2009 at 04:56:04PM +0100, Luca Barbato wrote:
>> Yes, it will warn noisily. This is unacceptable, since stable users
>> will have months and months of noise when new rules come along.
>
> "unacceptable"...
>
> as in "it's ugly to see"...
>
No, it's unacceptable because stable users
On Wed, 25 Feb 2009 16:56:04 +0100
Luca Barbato wrote:
> > That you're bringing ebuild.sh into this shows you still haven't
> > worked out how the process works. There is no need to use ebuild.sh
> > (which is a very good thing, because launching bash is
> > slow) when there's valid me
Ciaran McCreesh wrote:
On Wed, 25 Feb 2009 09:33:44 +0100
Alexis Ballier wrote:
That sounds like an implementation detail that you could solve by
using something else than a flat file database for metadata if
open()/read() calls are the slow part.
Metadata's shipped with the tree. It's a PMS
Thomas Anderson wrote:
On Wed, Feb 25, 2009 at 04:56:04PM +0100, Luca Barbato wrote:
Yes, it will warn noisily. This is unacceptable, since stable users
will have months and months of noise when new rules come along.
"unacceptable"...
as in "it's ugly to see"...
No, it's unacceptable becaus
On Wed, 25 Feb 2009 17:17:29 +0100
Luca Barbato wrote:
> I'd rather see more people backing their ideas with numbers...
I already told you your numbers are nonsense.
Of course opening the file when you've already opened it isn't going to
make any difference.
--
Ciaran McCreesh
signature.asc
46 matches
Mail list logo
