Ciaran McCreesh <ciaran.mccreesh <at> googlemail.com> writes: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Wed, 27 May 2009 22:43:21 +0100 > Roy Bamford <neddyseagoon <at> gentoo.org> wrote: > > You chose to ignore "Adding metadata to the filename is not required > > and is bad system design practice." > > > > I assume you agree with that as you chose to snip it, not to refute > > it with a technical argument? > > That's a blind assertion, not a technical argument, in the same way > that "feeding cows is not necessary, and giving food to cows is bad > farming practice" is. The GLEP clearly demonstrates its necessity.
The only thing that GLEP55 "clearly demonstrates" is something has to be done, such that the EAPI of the ebuild can be determined before the package manager actually sources the ebuild. NOT once within GLEP55 or in all the ml posts over all the *MONTHS* has there been unequivocal proof that encoding metadata into the filename of an ebuild is a necessity, so please stop playing that tune it is getting boring > > > GLEP 55 is a poor piece of technical writing. The title > > <quote> > > Title: Use EAPI-suffixed ebuilds (.ebuild-EAPI) > > </quote> > > should be an area to be impvoved not a possible solution that has not > > even been discussed (in the document) yet. > > GLEP titles are required to be short. Even with title length restrictions the title can easily be improved. At present it tells the skim reader NOTHING except it is todo with encoding EAPI into the filename. "Means to determine EAPI of ebuild" 7 less characters AND actually provides some description of what this GLEP is going to cover not some BS "WTF" title. Present title is crap, simple as that. > > > The abstract tells readers more about a proposed solution. > > <quote> > > This GLEP proposes usage of EAPI-suffixed file extensions for ebuilds > > (for example, foo-1.2.3.ebuild-1). > > </quote> > > and readers still don't know the problem that it tries to address. > > Because that's down in the 'Problem' section. Your argument appears to > be that no individual paragraph covers every last bit of material in > the GLEP. > No it is not. That is not an abstract, that is jumping straight in with the proposed solution. That is not what an abstraction/summary is for. There is no (formal) length restriction on the abstraction section so it should be taken advantage of. The abstract/summary is to allow those that have a quick look into the paper (after looking at a relevant title...) to tell if it relevant to their interest and whether they should read any further. OR in a big discussion, where a paper is referred to as a logging number, people can quickly ascertain what it is discussing - very important ifmany papers are referenced in a discussion If you have any formal proposal writing experience you would know that As a formal paper this is a joke and I would be embarrassed to be associated with it, luckily I am not. > > The statement of the problem is not entirely correct either ... > > <quote>The current way of specifying the EAPI in ebuilds is flawed. > > In order to get the EAPI the package manager needs to source the > > ebuild, > > </quote> > > Nope, in order to get the EAPI, the PM needs to parse the ebuild, it > > need not source it. Thats a statement of the current design. > > Uhm. No. With the current rules, the package manager cannot parse the > ebuild. It has to use a full bash source. So ... maybe the rules are wrong and they also need to be changed for the complete solution to be realised. Parse the ebuild, determine the EAPI, configure PackageManager, source ebuild. Problem solved. QED. I wonder what portage does at the moment... Definition of problem is flawed within GLEP55 > > > <quote> > > which itself needs the EAPI in the first place. > > </quote> > > Well, thats what current designs do, its a design than can be changed. > > ...which is what GLEP 55 is about, yes. > > > Until we get to the Abstract solution, the GLEP reads like a sales > > brouchre, which is what reminded me of VHS vs Betamax. > > Have you ever read a technical paper? They start off with a brief > introduction that doesn't contain details, then move on to the details > later on. > WHAT! 1) The title of this GLEP is all about the solution 2) the Abstraction is all about the solution THEN finally we get the actual problem This GLEP starts off with DETAILS!!! precise details Again this, as a technical paper is shocking!. And if you have read any technical paper or written any that actually got anywhere you would be able to see that. > > The > > <quote> > > Hurts performance: yes > > </quote> > > needs to be quantifed and included in the GLEP, so that readers can > > make an impartial objective assessment of the alternatives on offer > > and hopefully support the best technical solution. That need not be > > the fastest. > > It's a simple statement of fact. if it *fact* provide results, provide details of how the results were obtained, provide details so others may reproduce independently, if they want. Such things should be in the paper. Otherwise it is just a baseless statement and its presence in a technical discussion is amateurish ANY technical paper that wants to be taken seriously provides details on how tests were performed, how tests were collected. > > > A GLEP is not a sales document for any particular design solution. > > Well, this one is in its present form and it needs to be fixed. > > Have you read any GLEPs? Or indeed any other technical papers? It's a > rare technical paper that advocates an enhancement without stating the > benefits of that enhancement. > > > In short, I support the aims of GLEP 55 but not (yet) the proposed > > solution as the GLEP has not made any quantitive technical arguments > > for it being the best solution. There is already plenty of posts on > > this list suggesting it isn't. > > The only solutions that have been proposed that solve the entire > problem are the extension ones, and between .ebuild-X and .eapi-X.eb is > mere bikeshedding that won't get decided except by an arbitrary vote. > Umm no. A number of solutions have been put forward to solve the problem described in GLEP55, "means to determine the EAPI of an ebuild pre-sourcing" encoding the EAPI into the filename does not provide any additional benefits over encoding it in a pre-defined position within the files data + one-off extension change. Infact it has already been stated: "Adding metadata to the filename is not required and is bad system design practice" So unless there is some other aspect of the problem that hasn't been described in GLEP55, I fail to see any technical reason why encoding into the filename is the only solution Now if there is an actual technical reason, a reason that isn't present in GLEP55, then it is further proof that GLEPP55 is not suitable for the task and needs to be rejected in its present form
