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 way ). We are trying to solve issues that ware stopping
the "tree" moving forward. Lets evaluate GLEP 55 in the problems it is
attempting to solve.
I'm afraid you missed the whole point...
- what is in the proposal is a solution looking for a problem: nobody
updated the glep with the required sections, nobody put up a list of
bugs/rfe from bugzilla it helps to solve. Vague "leading to the future
change" declaration aren't what I'd expect.
So im mean't to start committing ebuilds into the tree that expect a
certain unimplemented functionality, only to file bugs against portage
for it not supporting them?
Apparently you missed rfe or that it does mean =\
Plus we already know of at least one case where we will encounter a
problem in the future, why? because we have already.
Not sure if there is a open bug about it tho.
Do you know that "a problem" means nothing, bug #number means something?
Do you know that improvement and enhancement can be requested on
bugzilla as well?
This actually eats at me, your basically saying GLEP's should only be
reactive. Why don't we all just roll over and die.
I'm afraid you are getting quite emotional for no reason.
I have already considered the problems, and believe GLEP 55 is the
**best** solution to them. Is it perfect, no. But I have yet to see
anything better.
YOU, other did and consider what is proposed on that trash. Mediation is
needed apparently. What is sure is that the glep proposal is lacking
lots of details and apparently none of the proponents are even willing
to try to cope with that.
Yes exactly, you need to know the EAPI before you __parse__ the ebuild.
You have to extract the eapi before doing the parsing the eapi defines,
but you can parse the ebuild just to get the eapi and then do something
or nothing depending on that value...
1) How about in a flat txt file: That would become a developers
nightmare.
2) In an xml file. Package managers would have to support xml. Not
the best thing in the world. also could be a nightmare, adding an entry
for every ebuild.
3) As an xattr. Well this idea is novel. I bet it would make the tree
nice and stable too. Lets not forget how annoying it will be for devs.
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.
"What if" is exactly something you cannot use, it's a slippery slope
that leads to qbits frozen objects from the outher space or other insane
stuff that may or may not happen.
5) Mmmmm...On the file name sounds like a good idea. especially as an
extension. provides information to a package manager, person,
script/program without them needing to open anything. identifies the
contents just like .txt, .c, .o, .jpeg, etc
So for normal multimedia file I'd have to have "myfile.mov-aac-h264-ass"
as extension? strange, mplayer is perfectly fine even if it is called
"myfile" and file(1) usually can tell me what's inside it in term of
codec and sometimes even it's params.
- Extracting such information could have different costs depending on
where to place it.
I believe it being on the filename would be the least costly, in terms
of processor/io at least.
try yourself, I did and that's what I found regarding the case of cache
regen (that, as I wrote earlier, is the interesting case) is in one of
the previous emails as well...
btw it's also quite easy plant both proposals in portage and see what
happen if you really like, but I preferred give something everybody can
try in bash.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
