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? Or can we be smart enough to realise that there are limitation to the current standard and then attempt to fix them before they become a problem. 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. This actually eats at me, your basically saying GLEP's should only be reactive. Why don't we all just roll over and die. > - Assuming there is an actual reason to move forward (by digging > bugzilla yourself or deciding to do so as academic exercise) you could > think about the problem and its solutions (my the email starting this > thread on dev) 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. > > - Given all you need is just to have a way to get the information about > EAPI before you actually parse the ebuild since the eapi defines how you > parse it, you can come up with various solutions, the simplest being > first extract the eapi, being it in a fixed place, and then do the parse. > Yes exactly, you need to know the EAPI before you __parse__ the ebuild. At least we agree that nothing should have to read the contents of the file to determine EAPI (doing so would be parsing now wouldn't it). So seeing that we agree with that, where should we stick the EAPI. mmmmm.... 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. 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 > - 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.
