1 |
Luca Barbato wrote: |
2 |
> Alistair Bush wrote: |
3 |
>> I just don't think those numbers tell us anything and that should be |
4 |
>> obvious from anyone who has read GLEP 55[1], we ain't really attempting |
5 |
>> to solve a problem that exists within the tree currently (well the bash |
6 |
>> issue does, in a way ). We are trying to solve issues that ware stopping |
7 |
>> the "tree" moving forward. Lets evaluate GLEP 55 in the problems it is |
8 |
>> attempting to solve. |
9 |
> |
10 |
> I'm afraid you missed the whole point... |
11 |
> |
12 |
> - what is in the proposal is a solution looking for a problem: nobody |
13 |
> updated the glep with the required sections, nobody put up a list of |
14 |
> bugs/rfe from bugzilla it helps to solve. Vague "leading to the future |
15 |
> change" declaration aren't what I'd expect. |
16 |
> |
17 |
|
18 |
So im mean't to start committing ebuilds into the tree that expect a |
19 |
certain unimplemented functionality, only to file bugs against portage |
20 |
for it not supporting them? Or can we be smart enough to realise that |
21 |
there are limitation to the current standard and then attempt to fix |
22 |
them before they become a problem. Plus we already know of at least one |
23 |
case where we will encounter a problem in the future, why? because we |
24 |
have already. Not sure if there is a open bug about it tho. |
25 |
|
26 |
This actually eats at me, your basically saying GLEP's should only be |
27 |
reactive. Why don't we all just roll over and die. |
28 |
|
29 |
> - Assuming there is an actual reason to move forward (by digging |
30 |
> bugzilla yourself or deciding to do so as academic exercise) you could |
31 |
> think about the problem and its solutions (my the email starting this |
32 |
> thread on dev) |
33 |
|
34 |
I have already considered the problems, and believe GLEP 55 is the |
35 |
**best** solution to them. Is it perfect, no. But I have yet to see |
36 |
anything better. |
37 |
|
38 |
> |
39 |
> - Given all you need is just to have a way to get the information about |
40 |
> EAPI before you actually parse the ebuild since the eapi defines how you |
41 |
> parse it, you can come up with various solutions, the simplest being |
42 |
> first extract the eapi, being it in a fixed place, and then do the parse. |
43 |
> |
44 |
|
45 |
Yes exactly, you need to know the EAPI before you __parse__ the ebuild. |
46 |
At least we agree that nothing should have to read the contents of the |
47 |
file to determine EAPI (doing so would be parsing now wouldn't it). So |
48 |
seeing that we agree with that, where should we stick the EAPI. |
49 |
mmmmm.... |
50 |
|
51 |
1) How about in a flat txt file: That would become a developers |
52 |
nightmare. |
53 |
2) In an xml file. Package managers would have to support xml. Not |
54 |
the best thing in the world. also could be a nightmare, adding an entry |
55 |
for every ebuild. |
56 |
3) As an xattr. Well this idea is novel. I bet it would make the tree |
57 |
nice and stable too. Lets not forget how annoying it will be for devs. |
58 |
4) Parsing the ebuild. But what are we parsing?, lets not limit |
59 |
ourselves to bash, we might want to change languages completely. If it |
60 |
is bash, what version, what if EAPI is set multiple times, what if its |
61 |
set in an eclass. |
62 |
5) Mmmmm...On the file name sounds like a good idea. especially as an |
63 |
extension. provides information to a package manager, person, |
64 |
script/program without them needing to open anything. identifies the |
65 |
contents just like .txt, .c, .o, .jpeg, etc |
66 |
|
67 |
> - Extracting such information could have different costs depending on |
68 |
> where to place it. |
69 |
|
70 |
I believe it being on the filename would be the least costly, in terms |
71 |
of processor/io at least. |