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
Il martedì 24 febbraio 2009 00:00:26 Markus Meier ha scritto:
> proposals:
>
> custom-cflags: Build with user-specified CFLAGS (unsupported)
> as custom-cxxflags has been added (w/o discussion here)
I asked it some times ago [1].
I hope we can have custom-c{xx,}flags in global useflags soon
[1]
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 Mon, Feb 23, 2009 at 08:45:28PM +0100, Christian Faulhammer wrote:
> > if [[ ${EBZR_REPO_URI} == */* ]]; then
> > repository="${EBZR_REPO_URI}/${EBZR_BRANCH}"
> > elif [[ -n ${EBZR_BRANCH} ]] ; then
> > ...
> > else
> > ...
> > fi
> >
> > If I see this correctly, this appends EBZR_B
Jan Kundrát wrote:
> See the patch.
>
applied
signature.asc
Description: OpenPGP digital signature
On Mon, 2009-02-23 at 22:19 +, Ciaran McCreesh wrote:
> On Mon, 23 Feb 2009 16:15:25 -0600
> Ryan Hill wrote:
> > Can we ban eclasses from setting EAPI? Is there any case where it
> > would be sane?
>
> It's already banned from a QA perspective, but from a package manager
> perspective peopl
2009/2/24 Ferris McCormick
> On Mon, 2009-02-23 at 22:19 +, Ciaran McCreesh wrote:
> > On Mon, 23 Feb 2009 16:15:25 -0600
> > Ryan Hill wrote:
> > > Can we ban eclasses from setting EAPI? Is there any case where it
> > > would be sane?
> >
> > It's already banned from a QA perspective, but
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
On Mon, 23 Feb 2009 20:49:02 -0500
Richard Freeman wrote:
> > and it doesn't let you change name or version rules.
>
> Neither does putting the EAPI in the filename as far as I can tell.
Name or versioning rules are things like allowing new suffixes or
altering the restrictions upon formatting.
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 Sat, 2009-02-21 at 19:44 -0500, Mike Frysinger wrote:
> > > > > > >
> > > > > > > i'll tweak the eclasses to use quoting for now
>
> no one suggested doing any of this crap you're talking about. if you want to
> get all retarded, dont install the masked ebuild. i gave a heads up to
> pe
On Tuesday 24 February 2009 10:52:55 Daniel Gryniewicz wrote:
> On Sat, 2009-02-21 at 19:44 -0500, Mike Frysinger wrote:
> > > > > > > > i'll tweak the eclasses to use quoting for now
> >
> > no one suggested doing any of this crap you're talking about. if you
> > want to get all retarded, dont in
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
Richard Freeman wrote:
> I still don't see why we need to be encoding metadata in filenames.
Correct. GLEP 55 tries to solve a technical implementation issue by
exposing meta data in the filename. Extremely bad form/design, IMHO.
> PERL doesn't care what a file extension is, python doesn't care
Somewhat ironically, had everyone been less stubborn last year when
discussing this topic we could have embedded the EAPI in line X of the
ebuild in 2008 and be using it now; instead of still discussing it.
I don't expect new novel ideas out of this thread. I expect the
council to defer it again
On Tue, 24 Feb 2009 09:15:59 -0700
Joe Peterson wrote:
> Richard Freeman wrote:
> > I still don't see why we need to be encoding metadata in filenames.
>
> Correct. GLEP 55 tries to solve a technical implementation issue by
> exposing meta data in the filename. Extremely bad form/design, IMHO.
On Tue, 24 Feb 2009 08:21:25 -0800
Alec Warner wrote:
> Somewhat ironically, had everyone been less stubborn last year when
> discussing this topic we could have embedded the EAPI in line X of the
> ebuild in 2008 and be using it now; instead of still discussing it.
...and we wouldn't be able to
Richard Freeman wrote:
> The dynamic linker doesn't need to consult the filename to figure out
> how to parse a shared object. It only consults the filename to figure
> out which shared object is needed. That is actually analogous to
> putting the package name/version in the ebuild filename.
On Tue, 24 Feb 2009 09:24:48 -0700
Joe Peterson wrote:
> Right. Plus, if the linker *did* consult the filename, imagine what
> would happen if someone renamed the file (even by accident) and
> changed the version? The parser should not be able to be so easily
> fooled - could cause great confusi
On Tue, Feb 24, 2009 at 8:23 AM, Ciaran McCreesh
wrote:
> On Tue, 24 Feb 2009 08:21:25 -0800
> Alec Warner wrote:
>> Somewhat ironically, had everyone been less stubborn last year when
>> discussing this topic we could have embedded the EAPI in line X of the
>> ebuild in 2008 and be using it now;
Ciaran McCreesh wrote:
> On Tue, 24 Feb 2009 09:24:48 -0700
> Joe Peterson wrote:
>> Right. Plus, if the linker *did* consult the filename, imagine what
>> would happen if someone renamed the file (even by accident) and
>> changed the version? The parser should not be able to be so easily
>> foo
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 08:33:19 -0800
Alec Warner wrote:
> Hey I never said its a perfect solution; but I'm a fan of the 'it
> covers 80%'. Sometimes you can't have your cake and eat it too;
> sometimes requirements get dropped.
We can cover 100% with a solution with less of an impact. There's no
On Tue, Feb 24, 2009 at 8:37 AM, Ciaran McCreesh
wrote:
> On Tue, 24 Feb 2009 08:33:19 -0800
> Alec Warner wrote:
>> Hey I never said its a perfect solution; but I'm a fan of the 'it
>> covers 80%'. Sometimes you can't have your cake and eat it too;
>> sometimes requirements get dropped.
>
> We
On Tue, 24 Feb 2009 09:36:29 -0700
Joe Peterson wrote:
> > You could use the same absurd argument to say that PN and PV
> > shouldn't be in the filename...
>
> No...!
>
> They are needed because:
>
> 1) versions of the *content*, not the *format* are needed for
> uniqueness
So why's PN in ther
Ciaran McCreesh wrote:
>> All good points. I cannot believe there exists no other way to solve
>> this technical issue other than resorting to such a non-Unix-like
>> idea. Obviously all of the software packages cited above endeavor to
>> avoid such nastiness.
>
> Then why don't you come up with
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
On Tue, 24 Feb 2009 09:45:44 -0700
Joe Peterson wrote:
> > Then why don't you come up with a viable solution?
>
> I already have - look back at my posts; very similar to Rich0's idea.
No, I said viable.
> And I tire of the argument that if one doesn't have a perfect solution
> now, we should ad
On Tue, 24 Feb 2009 08:42:44 -0800
Alec Warner wrote:
> On Tue, Feb 24, 2009 at 8:37 AM, Ciaran McCreesh
> wrote:
> > On Tue, 24 Feb 2009 08:33:19 -0800
> > Alec Warner wrote:
> >> Hey I never said its a perfect solution; but I'm a fan of the 'it
> >> covers 80%'. Sometimes you can't have your
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 Sun, Feb 22, 2009 at 11:26:48PM -0800, Donnie Berkholz wrote:
> This is your friendly reminder! Same bat time (typically the 2nd & 4th
> Thursdays at 2000 UTC / 1600 EST), same bat channel (#gentoo-council @
> irc.freenode.net) !
Informal request, but it would be useful to get an idea of the
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
On Tue, Feb 24, 2009 at 6:47 PM, Brian Harring wrote:
>
> At the very least I'm after having the non-pms repos marked in some
> fashion so that alt implementations don't have to assume the portage
> standard (rather then the *agreed to* pms standard) to avoid
> exploding, but that's a rather short
Alec Warner gentoo.org> writes:
> Somewhat ironically, had everyone been less stubborn last year when
> discussing this topic we could have embedded the EAPI in line X of the
> ebuild in 2008 and be using it now; instead of still discussing it.
>
> I don't expect new novel ideas out of this thre
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
Ciaran McCreesh wrote:
> On Tue, 24 Feb 2009 09:36:29 -0700
> Joe Peterson wrote:
>> 2) it makes sense to have these in the filename, but not
>> internal meta-data
>
> For those of us who understand the process, it makes sense to have EAPI
> in the filename too.
Which seems to be an enlightened
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2009.02.24 16:48, Ciaran McCreesh wrote:
[snip]
>
> PN and PV are metadata, same as EAPI.
>
[snip]
> --
> Ciaran McCreesh
>
So we made a mistake with PN and PV and may compound it with EAPI.
How long before we *must* have other pieces of inform
On Tue, 24 Feb 2009 21:17:57 +
Roy Bamford wrote:
> > PN and PV are metadata, same as EAPI.
>
> So we made a mistake with PN and PV and may compound it with EAPI.
> How long before we *must* have other pieces of information in the
> filename?
Uh, never.
> When will the filename get so long
Ciaran McCreesh wrote:
> On Tue, 24 Feb 2009 21:17:57 +
> Except that once we have EAPI in the file extension, we can change
> anything we want in arbitrary ways without having to worry about
> backwards compatibility, so we won't need silly hacks.
Like the file name structure?
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2009.02.24 21:23, Ciaran McCreesh wrote:
> On Tue, 24 Feb 2009 21:17:57 +
> Roy Bamford wrote:
> > > PN and PV are metadata, same as EAPI.
> >
> > So we made a mistake with PN and PV and may compound it with EAPI.
> > How long before we *must*
On Tue, 24 Feb 2009 22:11:47 +
Roy Bamford wrote:
> > Except that once we have EAPI in the file extension, we can change
> > anything we want in arbitrary ways without having to worry about
> > backwards compatibility, so we won't need silly hacks.
>
> Your response amounts to empty assertion
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.
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 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
Ryan Hill wrote:
some other random ideas i've seen tossed around:
- #!/bin/env eapi-parser
- split EAPI into EAPI and some separate counter which would only be
incremented on uncompatible changes to the ebuild format
- change .ebuild to .eb
- waffles (sorry, lunchtime)
Yummy!
--
Luca Barbat
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
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
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
Also one point worth nothing here is that migrating from EAPI in the
file name to having it in a special place in the file can be scripted so
the change should be quite easy to do at a later point in time for the
main repository if wanted.
Regards,
Petteri
signature.asc
Description: OpenPGP dig
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
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
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
> 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
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 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 23:26 Sun 22 Feb , Donnie Berkholz wrote:
> This is your friendly reminder! Same bat time (typically the 2nd & 4th
> Thursdays at 2000 UTC / 1600 EST), same bat channel (#gentoo-council @
> irc.freenode.net) !
>
> If you have something you'd wish for us to chat about, maybe even vote
> o
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
78 matches
Mail list logo
