Re: [gentoo-dev] Gentoo Council Reminder for May 28

[Roy Bamford]

-----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 <neddyseagoon@g.o> 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-----