-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2009.05.27 21:06, Ciaran McCreesh wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Wed, 27 May 2009 20:55:33 +0100 > Roy Bamford <neddyseag...@gentoo.org> wrote: > > That means the EAPI needs to be extracted before the ebuild is > > sourced, which from the figures bandied about on the list may take > > marginaly longer but its a price worth paying for a sound system > > design. Gentoo should not repeat the VHS vs Betamax war. For those > > who do not remember, VHS was the better marketed but inferior > > technical solution that won the standards war for domestic Video > > recorders. > > > > The aims of GLEP 55 are good but the proposed implementaion is bad > > practice, so GLEP 55 should be rejected in its present form. > > You have not made a single technical argument in your entire message. > Please don't add yet more noise to the discussion. > > - -- > Ciaran McCreesh > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.9 (GNU/Linux) > > iEYEARECAAYFAkodnVkACgkQ96zL6DUtXhGerACcC2khWKdGKCaMTi7zE/jYyUUw > bU8AnA5Gg6bDz/JiDIwMB98R5t9dQNLg > =bfse > -----END PGP SIGNATURE----- > Ciaran,
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? 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. 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. 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. <quote> which itself needs the EAPI in the first place. </quote> Well, thats what current designs do, its a design than can be changed. <quote>Otherwise it imposes a serious limitation, namely every ebuild, using any of the future EAPIs, will have to be source'able by old package managers </quote> That is true, unless the .ebuild extension is changed so we get a clean break with the past. It does not mean the EAPI needs to be a part of the file name. The GLEP discusses this and and dismisses it for no sound technical reasons. Until we get to the Abstract solution, the GLEP reads like a sales brouchre, which is what reminded me of VHS vs Betamax. <quote> A solution to this problem has to lift those limitations and the only way to do it is to make the EAPI of an ebuild available to the package managers in a way that doesn't require them to source the ebuild. Another important requirement is for the solution to be backward compatible, which has the pleasant side-effect of making the solution applicable in the Gentoo tree right away. A solution to this problem has to lift those limitations and the only way to do it is to make the EAPI of an ebuild available to the package managers in a way that doesn't require them to source the ebuild. </quote> Thats all true or highly desireable. 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. 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. My view is that there are no good solutions to this problem, if the GLEP were to include all the facts, we might get the 'least worse' solution. 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. - -- Regards, Roy Bamford (NeddySeagoon) a member of gentoo-ops forum-mods treecleaners trustees -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAkods/8ACgkQTE4/y7nJvatT2ACfft1bqSuhLpFM69FjQ8qV5Pfd 6wcAn2cA0kQVbLshaTIGE5gnxtIdYHEG =nSJw -----END PGP SIGNATURE-----
