| 1 |
Alistair Bush wrote: |
| 2 |
> |
| 3 |
> Luca Barbato wrote: |
| 4 |
>> Alistair Bush wrote: |
| 5 |
>>> I just don't think those numbers tell us anything and that should be |
| 6 |
>>> obvious from anyone who has read GLEP 55[1], we ain't really attempting |
| 7 |
>>> to solve a problem that exists within the tree currently (well the bash |
| 8 |
>>> issue does, in a way ). We are trying to solve issues that ware stopping |
| 9 |
>>> the "tree" moving forward. Lets evaluate GLEP 55 in the problems it is |
| 10 |
>>> attempting to solve. |
| 11 |
>> I'm afraid you missed the whole point... |
| 12 |
>> |
| 13 |
>> - what is in the proposal is a solution looking for a problem: nobody |
| 14 |
>> updated the glep with the required sections, nobody put up a list of |
| 15 |
>> bugs/rfe from bugzilla it helps to solve. Vague "leading to the future |
| 16 |
>> change" declaration aren't what I'd expect. |
| 17 |
>> |
| 18 |
> |
| 19 |
> So im mean't to start committing ebuilds into the tree that expect a |
| 20 |
> certain unimplemented functionality, only to file bugs against portage |
| 21 |
> for it not supporting them? |
| 22 |
|
| 23 |
Apparently you missed rfe or that it does mean =\ |
| 24 |
|
| 25 |
> Plus we already know of at least one case where we will encounter a |
| 26 |
> problem in the future, why? because we have already. |
| 27 |
> Not sure if there is a open bug about it tho. |
| 28 |
|
| 29 |
Do you know that "a problem" means nothing, bug #number means something? |
| 30 |
Do you know that improvement and enhancement can be requested on |
| 31 |
bugzilla as well? |
| 32 |
|
| 33 |
> This actually eats at me, your basically saying GLEP's should only be |
| 34 |
> reactive. Why don't we all just roll over and die. |
| 35 |
|
| 36 |
I'm afraid you are getting quite emotional for no reason. |
| 37 |
|
| 38 |
> I have already considered the problems, and believe GLEP 55 is the |
| 39 |
> **best** solution to them. Is it perfect, no. But I have yet to see |
| 40 |
> anything better. |
| 41 |
|
| 42 |
YOU, other did and consider what is proposed on that trash. Mediation is |
| 43 |
needed apparently. What is sure is that the glep proposal is lacking |
| 44 |
lots of details and apparently none of the proponents are even willing |
| 45 |
to try to cope with that. |
| 46 |
|
| 47 |
> Yes exactly, you need to know the EAPI before you __parse__ the ebuild. |
| 48 |
|
| 49 |
You have to extract the eapi before doing the parsing the eapi defines, |
| 50 |
but you can parse the ebuild just to get the eapi and then do something |
| 51 |
or nothing depending on that value... |
| 52 |
|
| 53 |
> 1) How about in a flat txt file: That would become a developers |
| 54 |
> nightmare. |
| 55 |
> 2) In an xml file. Package managers would have to support xml. Not |
| 56 |
> the best thing in the world. also could be a nightmare, adding an entry |
| 57 |
> for every ebuild. |
| 58 |
> 3) As an xattr. Well this idea is novel. I bet it would make the tree |
| 59 |
> nice and stable too. Lets not forget how annoying it will be for devs. |
| 60 |
> 4) Parsing the ebuild. But what are we parsing?, lets not limit |
| 61 |
> ourselves to bash, we might want to change languages completely. If it |
| 62 |
> is bash, what version, what if EAPI is set multiple times, what if its |
| 63 |
> set in an eclass. |
| 64 |
|
| 65 |
"What if" is exactly something you cannot use, it's a slippery slope |
| 66 |
that leads to qbits frozen objects from the outher space or other insane |
| 67 |
stuff that may or may not happen. |
| 68 |
|
| 69 |
> 5) Mmmmm...On the file name sounds like a good idea. especially as an |
| 70 |
> extension. provides information to a package manager, person, |
| 71 |
> script/program without them needing to open anything. identifies the |
| 72 |
> contents just like .txt, .c, .o, .jpeg, etc |
| 73 |
|
| 74 |
So for normal multimedia file I'd have to have "myfile.mov-aac-h264-ass" |
| 75 |
as extension? strange, mplayer is perfectly fine even if it is called |
| 76 |
"myfile" and file(1) usually can tell me what's inside it in term of |
| 77 |
codec and sometimes even it's params. |
| 78 |
|
| 79 |
>> - Extracting such information could have different costs depending on |
| 80 |
>> where to place it. |
| 81 |
> |
| 82 |
> I believe it being on the filename would be the least costly, in terms |
| 83 |
> of processor/io at least. |
| 84 |
|
| 85 |
try yourself, I did and that's what I found regarding the case of cache |
| 86 |
regen (that, as I wrote earlier, is the interesting case) is in one of |
| 87 |
the previous emails as well... |
| 88 |
|
| 89 |
btw it's also quite easy plant both proposals in portage and see what |
| 90 |
happen if you really like, but I preferred give something everybody can |
| 91 |
try in bash. |
| 92 |
|
| 93 |
lu |
| 94 |
|
| 95 |
-- |
| 96 |
|
| 97 |
Luca Barbato |
| 98 |
Gentoo Council Member |
| 99 |
Gentoo/linux Gentoo/PPC |
| 100 |
http://dev.gentoo.org/~lu_zero |
Archives