[gentoo-dev] Gentoo Council Reminder for May 28

[gentoo-dev] Gentoo Council Reminder for May 28

[Tiziano Müller]

[-- Attachment #1: Type: text/plain, Size: 2723 bytes --]

This is your friendly reminder! Same bat time (typically the 2nd & 4th
Thursdays at 2000 UTC / 1600 EST), same bat channel (#gentoo-council @
irc.freenode.net) !

If you have something you'd wish for us to chat about, maybe even vote
on, let us know! Simply reply to this e-mail for the whole Gentoo dev
list to see.

For more info on the Gentoo Council, feel free to browse our homepage:
http://www.gentoo.org/proj/en/council/


Following is the preliminary meeting agenda. First we'll have to fill
the empty spot. After a short upgrade on EAPI-3 implementation we will
discuss the removal of old eclasses, followed by our old friend GLEP 55.
If we still have time we can dive into the topic of general EAPI
development.


Approval/voting of new council member replacing Donnie Berkholz
---------------------------------------------------------------

Unfortunately Donnie resigned as a member of the council (for
details please read his mail on the g-council ml). Next in line
are ulm and ssuominen.


EAPI 3: Short discussion of the progress
----------------------------------------

zmedico will provide an update on the progress of the implementation. Short
discussion of problems and implementation decisions if needed.


Removing old eclasses
---------------------

Goal: Decide whether developers are allowed to remove eclasses. Problem:
Upgrading using portage with a version before 2.1.4 will fail since portage
always used eclasses from the tree instead of the ones from environment.bz2,
even though the environment fail has been generated. Portage 2.1.4 got stabled
over a year ago.


Handling EAPI versioning in a forwards-compatible way
-----------------------------------------------------

Goal: Discuss whether one of the alternatives given in GLEP 55 is appropriate
to solve the problem. Decide which one should be chosen.


Define EAPI development/deployment cycles
-----------------------------------------

Goal: Start discussion about EAPI development/deployment. For example:
Collect problems of eapi introductions in the past, like reverting
ebuilds to former eapis to get them stable, not waiting for the pm
support a certain eapi before requesting stable keywords for ebuilds
using the new eapi, .... Collect problems of EAPI development like
feature-freeze, late feature removals (due to implementation problems).
Eventually develop a lightweight EAPI development model.


Cheers,
Tiziano

-- 
Tiziano Müller
Gentoo Linux Developer, Council Member
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-zero@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Ferris McCormick]

[-- Attachment #1: Type: text/plain, Size: 4242 bytes --]

On Tue, 2009-05-26 at 20:57 +0200, Tiziano Müller wrote:
> This is your friendly reminder! Same bat time (typically the 2nd & 4th
> Thursdays at 2000 UTC / 1600 EST), same bat channel (#gentoo-council @
> irc.freenode.net) !
> 
> If you have something you'd wish for us to chat about, maybe even vote
> on, let us know! Simply reply to this e-mail for the whole Gentoo dev
> list to see.
> 
> For more info on the Gentoo Council, feel free to browse our homepage:
> http://www.gentoo.org/proj/en/council/
> 
> 
> Following is the preliminary meeting agenda. First we'll have to fill
> the empty spot. After a short upgrade on EAPI-3 implementation we will
> discuss the removal of old eclasses, followed by our old friend GLEP 55.
> If we still have time we can dive into the topic of general EAPI
> development.
> 

Because Piotr recently amended GLEP55 to provide some further
clarification and justification as well as to present a few alternatives
addressing some objections people have expressed, it seems to me that
the GLEP55 discussion should now go something like this:

1.  Approve the concept in principle (I think Piotr's examples
sufficiently show the need for something along the lines set out in the
revised GLEP);

2.  Choose one of the proposed solutions.  For what it's worth, I favor
the new extension (package.ebuild --> package.eb), and then I think
something like ${PN}-${PVR}.eapi-${EAPI}.eb (or equivalent) is probably
best.  Here, ${PVR} is perhaps in a new version format.

  a.  No introduced overhead;
  b.  Current PMs will not even see it;
  c.  I think there is an advantage for the users and developers to be
able to see the required eapi immediately without having to read all
the .eb (or .ebuild if you choose .ebuild-<EAPI>) files.

3.  Approve the GLEP.

I would do the first quickly in order to cut off all the continual noise
on gentoo-dev@, and I really think the revised GLEP makes the case for
it well enough.  After that, it should no longer be a religious issue,
and I optimistically would not expect step 2 to take long at all.

I note that the .eapi-${EAPI} part could well be optional, in which case
GLEP54 falls naturally into the new scheme as something like
${PN}-${PVR}-scm.eb


> 
> Approval/voting of new council member replacing Donnie Berkholz
> ---------------------------------------------------------------
> 
> Unfortunately Donnie resigned as a member of the council (for
> details please read his mail on the g-council ml). Next in line
> are ulm and ssuominen.
> 
> 
> EAPI 3: Short discussion of the progress
> ----------------------------------------
> 
> zmedico will provide an update on the progress of the implementation. Short
> discussion of problems and implementation decisions if needed.
> 
> 
> Removing old eclasses
> ---------------------
> 
> Goal: Decide whether developers are allowed to remove eclasses. Problem:
> Upgrading using portage with a version before 2.1.4 will fail since portage
> always used eclasses from the tree instead of the ones from environment.bz2,
> even though the environment fail has been generated. Portage 2.1.4 got stabled
> over a year ago.
> 
> 
> Handling EAPI versioning in a forwards-compatible way
> -----------------------------------------------------
> 
> Goal: Discuss whether one of the alternatives given in GLEP 55 is appropriate
> to solve the problem. Decide which one should be chosen.
> 
> 
> Define EAPI development/deployment cycles
> -----------------------------------------
> 
> Goal: Start discussion about EAPI development/deployment. For example:
> Collect problems of eapi introductions in the past, like reverting
> ebuilds to former eapis to get them stable, not waiting for the pm
> support a certain eapi before requesting stable keywords for ebuilds
> using the new eapi, .... Collect problems of EAPI development like
> feature-freeze, late feature removals (due to implementation problems).
> Eventually develop a lightweight EAPI development model.
> 
> 
> Cheers,
> Tiziano
Regards,
Ferris
-- 
Ferris McCormick (P44646, MI) <fmccor@gentoo.org>
Developer, Gentoo Linux (Sparc, Userrel, Trustees)

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Ulrich Mueller]

>>>>> On Wed, 27 May 2009, Ferris McCormick wrote:

> I note that the .eapi-${EAPI} part could well be optional, in which
> case GLEP54 falls naturally into the new scheme as something like
> ${PN}-${PVR}-scm.eb

Sorry, but this is not what GLEP 54 proposes.

GLEP 54 proposes to make "-scm" part of PV. And my concerns about the
hyphen in PV still haven't been answered.

Ulrich

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

[Roy Bamford]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2009.05.27 13:46, Ferris McCormick wrote:
> On Tue, 2009-05-26 at 20:57 +0200, Tiziano Müller wrote:
> > This is your friendly reminder! Same bat time (typically the 2nd &
> 4th
> > Thursdays at 2000 UTC / 1600 EST), same bat channel (#gentoo-
> council
> @
> > irc.freenode.net) !
> > 
> > If you have something you'd wish for us to chat about, maybe even
> vote
> > on, let us know! Simply reply to this e-mail for the whole Gentoo
> dev
> > list to see.
> > 
> > For more info on the Gentoo Council, feel free to browse our
> homepage:
> > http://www.gentoo.org/proj/en/council/
> > 
> > 
> > Following is the preliminary meeting agenda. First we'll have to
> fill
> > the empty spot. After a short upgrade on EAPI-3 implementation we
> will
> > discuss the removal of old eclasses, followed by our old friend 
> GLEP
> 55.
> > If we still have time we can dive into the topic of general EAPI
> > development.
> > 
> 
> Because Piotr recently amended GLEP55 to provide some further
> clarification and justification as well as to present a few
> alternatives
> addressing some objections people have expressed, it seems to me that
> the GLEP55 discussion should now go something like this:
> 
> 1.  Approve the concept in principle (I think Piotr's examples
> sufficiently show the need for something along the lines set out in
> the
> revised GLEP);
> 
[snip]
> > Cheers,
> > Tiziano
> Regards,
> Ferris
> -- 
> Ferris McCormick (P44646, MI) <fmccor@gentoo.org>
> Developer, Gentoo Linux (Sparc, Userrel, Trustees)
> 
GLEP 55 still confuses the problem and the solution.
Adding metadata to the filename is not required and is bad system 
design practice. Its also the first step on the slippery slope to 
adding more metadata in the future.

Changing the .ebuild extension, to blind existing PMs to new format 
ebuilds, is probably a good thing as it means we can have both 
formats in the tree at the same time and not wait a long time (year 
plus) for users to be on a new package manager.

This allows the EAPI to be included within the ebuild where it belongs.

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.  

- -- 
Regards,

Roy Bamford
(NeddySeagoon) a member of
gentoo-ops
forum-mods
treecleaners
trustees
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkodmr8ACgkQTE4/y7nJvat44gCfWz/XUkodXfh4VuEM6uPrF04/
SzcAoKJKXfKUac/AVZ3/y6ez1XzoG33+
=yVGU
-----END PGP SIGNATURE-----

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

[Ciaran McCreesh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 27 May 2009 20:55:33 +0100
Roy Bamford <neddyseagoon@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-----

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

[Joe Peterson]

Roy Bamford wrote:
> GLEP 55 still confuses the problem and the solution.
> Adding metadata to the filename is not required and is bad system 
> design practice. Its also the first step on the slippery slope to 
> adding more metadata in the future.

++

> Changing the .ebuild extension, to blind existing PMs to new format 
> ebuilds, is probably a good thing as it means we can have both 
> formats in the tree at the same time and not wait a long time (year 
> plus) for users to be on a new package manager.

Also, ++

> This allows the EAPI to be included within the ebuild where it belongs.
> 
> 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. 

:)  Yep.  And bad design decisions can haunt is for a long time.  My
preference is the one-time .ebuild->.eb change, and putting the EAPI on
the first line, like a #!shebang.  Very easy to extract, and good design.

						-Joe

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@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-----

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

[Ciaran McCreesh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 27 May 2009 22:43:21 +0100
Roy Bamford <neddyseagoon@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.

> 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.

> 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.

> 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.

> <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.

> 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.

> 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.

- -- 
Ciaran McCreesh
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkodtiAACgkQ96zL6DUtXhEPKACeMX9DiIW62tCo/uHy74L7erxH
334AoIHqEb9SJ1QKzaosm1q1U4e7YlbZ
=jasp
-----END PGP SIGNATURE-----

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

[Patrick Lauer]

On Wednesday 27 May 2009 22:57:25 Joe Peterson wrote:

> > 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.
> >
> :)  Yep.  And bad design decisions can haunt is for a long time. 

Actually, once we add the current-glep55 changes we have no way of sanely 
undoing them if we should realize that they don't work out for us ...

... unless we do horrible things like forbidding it, which would cause the 
same errors we are trying to hide now.

So unless we have a plan for mid-term future changes I don't see why we would 
want the current GLEP55 - it's a one-way change in the current state.


> My preference is the one-time .ebuild->.eb change, and putting the EAPI on
> the first line, like a #!shebang.  Very easy to extract, and good design.

My preference is freezing the rsync tree, storing all referenced distfiles on 
at least one mirror, then change the rsync path.
That way all "old" users get the last sane upgrade position and all newer 
changes only hit users that upgraded far enough. Means you can slip in any 
ebuild format changes without needing to do any changes to the current file 
and directory layout. 

Do that every EAPI bump and worst case you have 200M per switch on the rsync 
mirrors and 15G extra storage on a mirror (which is a tolerable expense for 
infra if it saves us hacking things up backwards to hide errors that shouldn't 
be there)

wkr,

Patrick

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

[Piotr Jaroszyński]

2009/5/27 Patrick Lauer <patrick@gentoo.org>:
> On Wednesday 27 May 2009 22:57:25 Joe Peterson wrote:
>
>> > 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.
>> >
>> :)  Yep.  And bad design decisions can haunt is for a long time.
>
> Actually, once we add the current-glep55 changes we have no way of sanely
> undoing them if we should realize that they don't work out for us ...
>
> ... unless we do horrible things like forbidding it, which would cause the
> same errors we are trying to hide now.
>
> So unless we have a plan for mid-term future changes I don't see why we would
> want the current GLEP55 - it's a one-way change in the current state.

How is it one-way exactly? You can do pretty much anything you want in
a new EAPI (that's the point).

>> My preference is the one-time .ebuild->.eb change, and putting the EAPI on
>> the first line, like a #!shebang.  Very easy to extract, and good design.
>
> My preference is freezing the rsync tree, storing all referenced distfiles on
> at least one mirror, then change the rsync path.
> That way all "old" users get the last sane upgrade position (...)

And bugs and security vulnerabilities too. Or do you propose
maintaining multiple trees at the same time? I think one of the main
points of EAPI was to avoid doing exactly that.

-- 
Best Regards,
Piotr Jaroszyński

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

[Patrick Lauer]

On Thursday 28 May 2009 00:12:56 Piotr Jaroszyński wrote:
> 2009/5/27 Patrick Lauer <patrick@gentoo.org>:
> > On Wednesday 27 May 2009 22:57:25 Joe Peterson wrote:
> >> > 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.
> >> >
> >> :)  Yep.  And bad design decisions can haunt is for a long time.
> >
> > Actually, once we add the current-glep55 changes we have no way of sanely
> > undoing them if we should realize that they don't work out for us ...
> >
> > ... unless we do horrible things like forbidding it, which would cause
> > the same errors we are trying to hide now.
> >
> > So unless we have a plan for mid-term future changes I don't see why we
> > would want the current GLEP55 - it's a one-way change in the current
> > state.
>
> How is it one-way exactly? You can do pretty much anything you want in
> a new EAPI (that's the point).

You cannot undo it.

In other words, you'll have to allow stupid filenames until the end of times 
even if you are quite positively sure that it is, right now, a bad idea.
>
> >> My preference is the one-time .ebuild->.eb change, and putting the EAPI
> >> on the first line, like a #!shebang.  Very easy to extract, and good
> >> design.
> >
> > My preference is freezing the rsync tree, storing all referenced
> > distfiles on at least one mirror, then change the rsync path.
> > That way all "old" users get the last sane upgrade position (...)
>
> And bugs and security vulnerabilities too. Or do you propose
> maintaining multiple trees at the same time? I think one of the main
> points of EAPI was to avoid doing exactly that.

Not at all. Just an upgrade snapshot so you can get "old" users into a known 
state, then let them upgrade at least the package manager to a point where 
they can use the rest. That snapshot should be seen as a transient helper, not 
as a "release" ...

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

[Piotr Jaroszyński]

2009/5/28 Patrick Lauer <patrick@gentoo.org>:
> On Thursday 28 May 2009 00:12:56 Piotr Jaroszyński wrote:
>> 2009/5/27 Patrick Lauer <patrick@gentoo.org>:
>> > On Wednesday 27 May 2009 22:57:25 Joe Peterson wrote:
>> >> > 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.
>> >> >
>> >> :)  Yep.  And bad design decisions can haunt is for a long time.
>> >
>> > Actually, once we add the current-glep55 changes we have no way of sanely
>> > undoing them if we should realize that they don't work out for us ...
>> >
>> > ... unless we do horrible things like forbidding it, which would cause
>> > the same errors we are trying to hide now.
>> >
>> > So unless we have a plan for mid-term future changes I don't see why we
>> > would want the current GLEP55 - it's a one-way change in the current
>> > state.
>>
>> How is it one-way exactly? You can do pretty much anything you want in
>> a new EAPI (that's the point).
>
> You cannot undo it.
>
> In other words, you'll have to allow stupid filenames until the end of times
> even if you are quite positively sure that it is, right now, a bad idea.

What do you mean by "allow" exactly? You can put whatever filenames in
the tree currently and package managers ignore them, just as they
would ignore *.ebuild-$eapi where $eapi is unsupported. So should g55
be accepted, implemented and then undone you would "lose" only
*.ebuild-{EAPIs introduced before undoing}.

>> >> My preference is the one-time .ebuild->.eb change, and putting the EAPI
>> >> on the first line, like a #!shebang.  Very easy to extract, and good
>> >> design.
>> >
>> > My preference is freezing the rsync tree, storing all referenced
>> > distfiles on at least one mirror, then change the rsync path.
>> > That way all "old" users get the last sane upgrade position (...)
>>
>> And bugs and security vulnerabilities too. Or do you propose
>> maintaining multiple trees at the same time? I think one of the main
>> points of EAPI was to avoid doing exactly that.
>
> Not at all. Just an upgrade snapshot so you can get "old" users into a known
> state, then let them upgrade at least the package manager to a point where
> they can use the rest. That snapshot should be seen as a transient helper, not
> as a "release" ...

So a user n snapshots behind would have to go through various upgrade
paths n times. And if she failed to do it all at once her system would
be left with known bugs and vulnerabilities. Sounds a bit messy to me,
especially as it can be easily avoided (with improved EAPIs - i.e.
g55).

-- 
Best Regards,
Piotr Jaroszyński

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

[Mark Bateman]

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

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 4847 bytes --]

On Wed, 27 May 2009 23:26:25 +0000 (UTC)
Mark Bateman <couldbe@soon.com> wrote:
> 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

Not once has there been an equally good alternative proposed.

> > 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. 

Doesn't cover the intent of the enhancement. The intent of the
enhancement is to use EAPI suffixed ebuilds.

> > 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

Yes, and the quick summary of the GLEP is that EAPI suffixed file
extensions should be used for ebuilds.

> 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. 

You're being overly harsh on Piotr there. GLEPs aren't supposed to be
written to peer review journal standards -- they're supposed to be
technical material that can be understood by the appropriate audience
and used to propose an enhancement, not something that has to stand in
archives for a thousand years.

> > 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.

Congratulations. That is what this whole thing is about, and GLEP 55
presents the best way of doing that changing.

> Parse the ebuild, determine the EAPI, 
> configure PackageManager, source ebuild. Problem solved.  QED.
> 
> I wonder what portage does at the moment...

It uses bash to do the sourcing, as it has to. And the GLEP covers why
the file extension method is better than parsing to get EAPI.

> Definition of problem is flawed within GLEP55 

No, the definition of the problem is entirely accurate and correct.

> > 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

The title describes the desired enhancement, yes.

> 2) the Abstraction is all about the solution

The abstract describes the desired enhancement in more detail, yes.

> THEN finally we get the actual problem 

The main proposal then expands upon the background and reasoning behind
the enhancement, yes.

> > 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.

It's true by definition. It's not something that's only true as a
result of an implementation; implementations can be improved, but
penalties from definition can't be fixed.

> 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.

This is covered by GLEP 55.

> Infact it has already been stated: 
> "Adding metadata to the filename is not required and is bad system 
> design practice"

Stating something doesn't make it true. You could just as easily argue
that having PV in the filename is bad.

> 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

The reason is that there is no equally good alternative.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

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

[Jeroen Roovers]

On Thu, 28 May 2009 00:45:18 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Wed, 27 May 2009 23:26:25 +0000 (UTC)
> Mark Bateman <couldbe@soon.com> wrote:
> > NOT once within GLEP55 [...]

> Not once has there been an equally good alternative proposed.

None needed, seems to be the major voice.


     jer

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 569 bytes --]

On Thu, 28 May 2009 01:48:34 +0200
Jeroen Roovers <jer@gentoo.org> wrote:
> On Thu, 28 May 2009 00:45:18 +0100
> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > On Wed, 27 May 2009 23:26:25 +0000 (UTC)
> > Mark Bateman <couldbe@soon.com> wrote:
> > > NOT once within GLEP55 [...]
> 
> > Not once has there been an equally good alternative proposed.
> 
> None needed, seems to be the major voice.

So it's your opinion that Gentoo should go with an in every way inferior
solution that doesn't solve the problem as well?

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

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

[Jeroen Roovers]

On Thu, 28 May 2009 00:54:40 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> > None needed, seems to be the major voice.
> 
> So it's your opinion that Gentoo should go with an in every way
> inferior solution that doesn't solve the problem as well?

I was merely overstating the obvious.


     jer

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

[Tiziano Müller]

[-- Attachment #1: Type: text/plain, Size: 6699 bytes --]

Am Mittwoch, den 27.05.2009, 22:43 +0100 schrieb 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@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.

I did some analysis on that. The result is that the the performance
penalty of not having the EAPI not in the filename depends on various
factors. But it is for sure that there is a performance penalty.

And here is why (I'm only looking at the non-degenerated case with valid
metadata, ignoring overlays which some consider a corner case (I don't
understand that argument, but that's another thing)):

When the package manager looks at a package, it first reads the
package's ebuild directory and gets the mtimes. It does the same for the
cache entries and validates the caches (there is more stuff in here,
like checking eclasses and so on).
Then the following happens based on the "solution" we choose:
eapi-in-filename: the package manager starts from the highest version
with a supported eapi (the others are inexistant with the used glob).
For that ebuild it reads the cache entry and decides whether or not it
can be used. If not, it proceeds to the next version, if yes, it's done.
eapi-in-ebuild: the package manager reads all cache entries and sorts
out those with an EAPI it doesn't support. The rest gets ordered and the
same procedure as above applies.

So, one of the main differences is: "reading one cache file" (if running
unstable you can asssume you support the highest version, thus reading
only one cache file) vs. "reading all cache files".

I did some performance measurements based on that. I have 1507 installed
packages with 5541 different versions/revisions.

Reading from hot cache:
1507 files: ~50ms
5541 files: ~170ms

Reading from cold cache:
1507 files: ~2.8s
5541 files: ~6s

I made a lot of assumptions here (neglecting seek between ebuild-dir and
metadata-dir, other processes using the drive, 80 ebuilds from overlays
where the ebuild would have to be read, etc.). But estimating from the
numbers above I'd say that a "emerge -uD world"/"paludis -i world" will
be at least twice as slow, which I think is not acceptable.

And I also don't understand your point of stating it's "bad design". I
mean: when coding you should "not optimize prematurely", but with
eapi-in-ebuild it is against the other principle of "not pessimize
prematurely" (Sutter/Alexandrescu: C++ Coding Standards).



-- 
Tiziano Müller
Gentoo Linux Developer, Council Member
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-zero@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] How not to discuss

[Patrick Lauer]

This is becoming a rather lengthy email ping pong, but as people seem to be 
unable to discuss things I had to highlight a few issues there. 

Short version:

- Try to avoid subjective statements. Statements like "C++ feels better" don't 
add anything to the discussion and are objectively wrong for me, so they have 
no place in a technical discussion

- Repeating things doesn't make them more true. If someone disagrees use 
technical arguments, microbenchmarks or whatever else is needed to show that 
the argument is wrong (or at least severely flawed) instead of ignoring it.

- Start with the problem, not the solution. If you cannot define the problem 
then there's a good chance your solution isn't. Don't ignore facts if they'd 
show that your solution is a sad puppy that should get euthanised.

- Keep your cool. If you are right there's no need to immediately fire back an 
email. Take your time, disassemble the arguments (or lack thereof) the other 
side provides instead of playing semantic game or trying to use logical 
fallacies to make you sound more better.

Posting on this mailinglist is a privilege, not a right. Be careful not to 
lose it.




On Thursday 28 May 2009 01:45:18 Ciaran McCreesh wrote:
> On Wed, 27 May 2009 23:26:25 +0000 (UTC)
>
> Mark Bateman <couldbe@soon.com> wrote:
> > 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
>
> Not once has there been an equally good alternative proposed.

That's subjective, and let me be the first one to disagree. GLEP55 in its 
current form (rev. 1.5 at the moment, we need to state the revision so we know 
what we are actually talking about because it mutates ...) is definitely not 
the best solution if you  (even momentarily) allow other solutions to exist.


> > > GLEP titles are required to be short.
Yes, that is a reasonable demand. It is completely independent of the demand 
that the title describes the _problem_ and not your solution. Please try to 
improve your reading comprehension to the point where we can discuss instead 
of having several independent monologues.

> > 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.
>
> Doesn't cover the intent of the enhancement. The intent of the
> enhancement is to use EAPI suffixed ebuilds.

No, the intent is to find a better way to determine the EAPI. One proposed 
solution is the use of a suffix. Please stop trying to distract people in 
semantic games, it is dishonest.

>
> > > 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.

This is an important point - define the problem first, then discuss solutions. 
Otherwise you end up in circular reasoning that we need to do something so 
that something is done (which is quite fun and maybe even a tautology, but has 
no information content and can thus be classified as "white noise")
> >
> > 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
>
> Yes, and the quick summary of the GLEP is that EAPI suffixed file
> extensions should be used for ebuilds.

No, that is the solution favoured by one group of people. All other solutions 
are ignored by rephrasing the problem to be the solution and the solution to 
be the obvious solution to itself.

> You're being overly harsh on Piotr there. GLEPs aren't supposed to be
> written to peer review journal standards -- they're supposed to be
> technical material that can be understood by the appropriate audience
> and used to propose an enhancement, not something that has to stand in
> archives for a thousand years.
And still one would expect a minimal coherence - stating the problem (not 
there), discussing alternatives (incomplete and phrased in a way to make them 
look extra bad) and maybe a comparison (mostly missing).

Maybe even the impact of the solution, possible issues etc. 
You know, what we have been discussing on this mailinglist ... 

> > > 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.

Which points at a simple solution that gets mostly ignored: Since we already 
state EAPI explicitly we can restrict ourselves to parsing it (with a regexp, 
maybe) instead of having to source the ebuild. Which has to happen anyway as 
soon as you need metadata ...

> Congratulations. That is what this whole thing is about, and GLEP 55
> presents the best way of doing that changing.

No, GLEP55 is the hackish way of sweeping it under the rug. Feel free to 
implement it in an experimental overlay and report back what your experiences 
are in, say, 3 months ...

> > Parse the ebuild, determine the EAPI,
> > configure PackageManager, source ebuild. Problem solved.  QED.
> >
> > I wonder what portage does at the moment...
Mostly look at the metadata cache, but for this discussion we have to pretend 
that caching can't work instead of improving it.

> It uses bash to do the sourcing, as it has to. And the GLEP covers why
> the file extension method is better than parsing to get EAPI.

Subjective. See above. Repetition is repetitious.

> > Definition of problem is flawed within GLEP55
>
> No, the definition of the problem is entirely accurate and correct.

... wait, you defined the problem now? I thought GLEP55 was all about the 
solution. Or are you deliberately trying a switch-and-bate ?

>
> > > 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
>
> The title describes the desired enhancement, yes.
... which completely ignores stating the problem.

> > 2) the Abstraction is all about the solution
>
> The abstract describes the desired enhancement in more detail, yes.
... enhancing what to achieve what why?

> > THEN finally we get the actual problem
>
> The main proposal then expands upon the background and reasoning behind
> the enhancement, yes.
Oh, you gotta read it backwards. That's awesome. No wait, the other thing. 
Stupid!

> > > 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.
>
> It's true by definition. 
Tautologies are fun, but irrelevant to discussing technical issues. 

> It's not something that's only true as a
> result of an implementation; implementations can be improved, but
> penalties from definition can't be fixed.
Hmm. I'm not quite sure how to parse that. Does that mean that we need to 
abstractly discuss various options (which would go against your interpretation 
of the process), or does that mean that the idea of glep55 is flawed (which 
would be a rather interesting concession coming from you)?

>
> > 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.
I think we'd need to discuss the advantages and disadvantages of both 
approaches to be sure about that.

> This is covered by GLEP 55.
No, not at all.

> > Infact it has already been stated:
> > "Adding metadata to the filename is not required and is bad system
> > design practice"
>
> Stating something doesn't make it true. You could just as easily argue
> that having PV in the filename is bad.
Ignoring it doesn't make it go away. Reasonable discussion would be the best 
thing to do now ... are you willing to do that instead of running in circles 
and barking the same dog-matic statements?

>
> > 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
>
> The reason is that there is no equally good alternative.

The reason is that GLEP55 is no reasonable alternative to the rest.

See, stating things is easy. Now let's get this iceberg back on collision 
course with the titanic and resume a technical discussion please ...

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

[Patrick Lauer]

On Thursday 28 May 2009 01:10:50 Piotr Jaroszyński wrote:

> >>
> >> How is it one-way exactly? You can do pretty much anything you want in
> >> a new EAPI (that's the point).
> >
> > You cannot undo it.
> >
> > In other words, you'll have to allow stupid filenames until the end of
> > times even if you are quite positively sure that it is, right now, a bad
> > idea.
>
> What do you mean by "allow" exactly? You can put whatever filenames in
> the tree currently and package managers ignore them, just as they
> would ignore *.ebuild-$eapi where $eapi is unsupported. So should g55
> be accepted, implemented and then undone you would "lose" only
> *.ebuild-{EAPIs introduced before undoing}.

If you add an unsupported filetype randomly you'll find a few very unhappy 
people reverting your commit and suggesting that you never do it again. And 
repoman will tell you not to do such things (assuming that you do use it)

Once you GLEP55 it is very difficult to get rid of any problems it might cause 
without triggering the kind of apocalyptic breakage that it is supposed to 
avoid. So we should be reasonably certain that it is in fact the best solution 
and we want to live with it for a long time.

But, as people are discussing some interesting new (and some old) concepts 
that might change things around quite a bit maybe we should wait until we know 
where we are going before we start changing things we'd revert immediately.

> > Not at all. Just an upgrade snapshot so you can get "old" users into a
> > known state, then let them upgrade at least the package manager to a
> > point where they can use the rest. That snapshot should be seen as a
> > transient helper, not as a "release" ...
>
> So a user n snapshots behind would have to go through various upgrade
> paths n times. And if she failed to do it all at once her system would
> be left with known bugs and vulnerabilities. Sounds a bit messy to me,
> especially as it can be easily avoided (with improved EAPIs - i.e.
> g55).
It's actually less messy than the current breakage. Just spend a few days in 
#gentoo and watch people try to upgrade after >1y ... glep55 does nothing at 
all to help with that, snapshots at least give a consistent state to converge 
to. E.g. the bash-portage blocker (easily avoided with a snapshot), the "EAPI1 
unsupported" blocker (same) etc. etc.

Most issues happen because we do not provide an upgrade path, and GLEP55-style 
changes only motivate more rapid changes that will not make it easier for 
users to upgrade. It only has the potential to make life easier for those of 
use living on the bleeding edge and allows to add package formats to the tree 
that no official package manager supports (do we want that? I vote for no)

Added bonus - as soon as you have a snapshot supporting EAPI="wintermute" you 
can migrate _all_ packages to it without having to keep Python and gcc and 
stuff as eapi0. Which means we lose some rather naughty restrictions that are 
in place now (and can easily deprecate older EAPIs too, which is good in terms 
of complexity)
Oh, and you can change the defaults around too because you _know_ that this 
snapshot and higher can handle this change. 

I could go on pointing out nice features, but since this isn't a sales 
brochure I'll just leave it at that and hope someone actually reads this mail 
before instareplying.

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

[Patrick Lauer]

On Thursday 28 May 2009 07:46:36 Tiziano Müller wrote:

> And here is why (I'm only looking at the non-degenerated case with valid
> metadata, ignoring overlays which some consider a corner case (I don't
> understand that argument, but that's another thing)):

overlays tend to come without metadata. Just enabling the KDE overlay changed 
the time for "emerge -upNDv world" from ~30 seconds cold cache to ~120 
seconds. Running emerge --metadata gets the performance back to pretty much 
the old levels.

> When the package manager looks at a package, it first reads the
> package's ebuild directory and gets the mtimes. It does the same for the
> cache entries and validates the caches (there is more stuff in here,
> like checking eclasses and so on).
Eclasses are negligible because you only have to look at them once for the 
whole caclulation. You can cache the mtime for the duration of your operation.

> Then the following happens based on the "solution" we choose:
> eapi-in-filename: the package manager starts from the highest version
> with a supported eapi (the others are inexistant with the used glob).
> For that ebuild it reads the cache entry and decides whether or not it
> can be used. 
In this case you amusingly do NOT want to cache the eapi in the cache, so you 
can even defer sourcing the ebuild until you actually need the metadata.
(You don't want to cache it because you need to check the file mtime anyway, 
and then you read the filename anyway. No need to look for it in another place 
then :) )

> If not, it proceeds to the next version, if yes, it's done.
> eapi-in-ebuild: the package manager reads all cache entries and sorts
> out those with an EAPI it doesn't support. The rest gets ordered and the
> same procedure as above applies.
>
> So, one of the main differences is: "reading one cache file" (if running
> unstable you can asssume you support the highest version, thus reading
> only one cache file) vs. "reading all cache files".
That assumes a dumb cache format. 
Why don't we make the cache more efficient so you read one file per package / 
category / ... ?

>
> I did some performance measurements based on that. I have 1507 installed
> packages with 5541 different versions/revisions.
>
> Reading from hot cache:
> 1507 files: ~50ms
> 5541 files: ~170ms
>
> Reading from cold cache:
> 1507 files: ~2.8s
> 5541 files: ~6s
And now you need to pull metadata for dependency calculation. How big is the 
impact of that?

>
> I made a lot of assumptions here (neglecting seek between ebuild-dir and
> metadata-dir, other processes using the drive, 80 ebuilds from overlays
> where the ebuild would have to be read, etc.). But estimating from the
> numbers above I'd say that a "emerge -uD world"/"paludis -i world" will
> be at least twice as slow, which I think is not acceptable.
I find that quite acceptable. As long as we're using such a bad layout the 
performance is secondary.

To fix the performance you'd "only" have to guarantee that the repo is 
unchanged (readonly), so you can add lots of simple caches/indexes - no need 
to source any ebuild for metadata again, one cachefile for eapi if you want 
... I bet you find lots of small improvements that that would yield. Much more 
impressive than managing to avoid a few open() here and there ...


> And I also don't understand your point of stating it's "bad design".
Bad design is like smelly feet. It's hard not to notice ...

> I mean: when coding you should "not optimize prematurely", but with
> eapi-in-ebuild it is against the other principle of "not pessimize
> prematurely" (Sutter/Alexandrescu: C++ Coding Standards).
If you quote that try the full quote:

"We should forget about small efficiencies, say about 97% of the time: 
premature optimization is the root of all evil."

In other words, we should not try to make that path faster when we can avoid 
hitting it at all with a small design revision.

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

[Tiziano Müller]

[-- Attachment #1: Type: text/plain, Size: 4949 bytes --]

Am Donnerstag, den 28.05.2009, 09:23 +0200 schrieb Patrick Lauer:
> On Thursday 28 May 2009 07:46:36 Tiziano Müller wrote:
> 
> > And here is why (I'm only looking at the non-degenerated case with valid
> > metadata, ignoring overlays which some consider a corner case (I don't
> > understand that argument, but that's another thing)):
> 
> overlays tend to come without metadata. Just enabling the KDE overlay changed 
> the time for "emerge -upNDv world" from ~30 seconds cold cache to ~120 
> seconds. Running emerge --metadata gets the performance back to pretty much 
> the old levels.
> 
> > When the package manager looks at a package, it first reads the
> > package's ebuild directory and gets the mtimes. It does the same for the
> > cache entries and validates the caches (there is more stuff in here,
> > like checking eclasses and so on).
> Eclasses are negligible because you only have to look at them once for the 
> whole caclulation. You can cache the mtime for the duration of your operation.
> 
> > Then the following happens based on the "solution" we choose:
> > eapi-in-filename: the package manager starts from the highest version
> > with a supported eapi (the others are inexistant with the used glob).
> > For that ebuild it reads the cache entry and decides whether or not it
> > can be used. 
> In this case you amusingly do NOT want to cache the eapi in the cache, so you 
> can even defer sourcing the ebuild until you actually need the metadata.
by "whether or not it can be used" I meant "keyword-like", surely not
eapi-like since you already know it at that point.

> (You don't want to cache it because you need to check the file mtime anyway, 
> and then you read the filename anyway. No need to look for it in another place 
> then :) )
> > If not, it proceeds to the next version, if yes, it's done.
> > eapi-in-ebuild: the package manager reads all cache entries and sorts
> > out those with an EAPI it doesn't support. The rest gets ordered and the
> > same procedure as above applies.
> >
> > So, one of the main differences is: "reading one cache file" (if running
> > unstable you can asssume you support the highest version, thus reading
> > only one cache file) vs. "reading all cache files".
> That assumes a dumb cache format. 
> Why don't we make the cache more efficient so you read one file per package / 
> category / ... ?
> 
> >
> > I did some performance measurements based on that. I have 1507 installed
> > packages with 5541 different versions/revisions.
> >
> > Reading from hot cache:
> > 1507 files: ~50ms
> > 5541 files: ~170ms
> >
> > Reading from cold cache:
> > 1507 files: ~2.8s
> > 5541 files: ~6s
> And now you need to pull metadata for dependency calculation. How big is the 
> impact of that?
The 1507 files are the complete dep-tree cache entries for the highest
version, where the 5541 files are all the cache entries for all packages
in dep-tree.
I did say that I simplified the case a lot, didn't I? :)

> 
> >
> > I made a lot of assumptions here (neglecting seek between ebuild-dir and
> > metadata-dir, other processes using the drive, 80 ebuilds from overlays
> > where the ebuild would have to be read, etc.). But estimating from the
> > numbers above I'd say that a "emerge -uD world"/"paludis -i world" will
> > be at least twice as slow, which I think is not acceptable.
> I find that quite acceptable. As long as we're using such a bad layout the 
> performance is secondary.
... and I don't :)

> 
> To fix the performance you'd "only" have to guarantee that the repo is 
> unchanged (readonly), so you can add lots of simple caches/indexes - no need 
> to source any ebuild for metadata again, one cachefile for eapi if you want 
> ... I bet you find lots of small improvements that that would yield. Much more 
> impressive than managing to avoid a few open() here and there ...
> 
> 
> > And I also don't understand your point of stating it's "bad design".
> Bad design is like smelly feet. It's hard not to notice ...
> 
> > I mean: when coding you should "not optimize prematurely", but with
> > eapi-in-ebuild it is against the other principle of "not pessimize
> > prematurely" (Sutter/Alexandrescu: C++ Coding Standards).
> If you quote that try the full quote:
> 
> "We should forget about small efficiencies, say about 97% of the time: 
> premature optimization is the root of all evil."
> 
> In other words, we should not try to make that path faster when we can avoid 
> hitting it at all with a small design revision.
> 
Which you still failed (after one year or so) to provide a nice cleanly
written document for.

-- 
Tiziano Müller
Gentoo Linux Developer, Council Member
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-zero@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Ferris McCormick]

[-- Attachment #1: Type: text/plain, Size: 3774 bytes --]

On Wed, 2009-05-27 at 12:46 +0000, Ferris McCormick wrote:
> On Tue, 2009-05-26 at 20:57 +0200, Tiziano Müller wrote:
> > This is your friendly reminder! Same bat time (typically the 2nd & 4th
> > Thursdays at 2000 UTC / 1600 EST), same bat channel (#gentoo-council @
> > irc.freenode.net) !
> > 
> > If you have something you'd wish for us to chat about, maybe even vote
> > on, let us know! Simply reply to this e-mail for the whole Gentoo dev
> > list to see.
> > 
> > For more info on the Gentoo Council, feel free to browse our homepage:
> > http://www.gentoo.org/proj/en/council/
> > 
> > 
> > Following is the preliminary meeting agenda. First we'll have to fill
> > the empty spot. After a short upgrade on EAPI-3 implementation we will
> > discuss the removal of old eclasses, followed by our old friend GLEP 55.
> > If we still have time we can dive into the topic of general EAPI
> > development.
> > 
> 
> Because Piotr recently amended GLEP55 to provide some further
> clarification and justification as well as to present a few alternatives
> addressing some objections people have expressed, it seems to me that
> the GLEP55 discussion should now go something like this:
> 
> 1.  Approve the concept in principle (I think Piotr's examples
> sufficiently show the need for something along the lines set out in the
> revised GLEP);
> 
--- SNIP ---

I did not intend to set off another religious war with this.  I was
merely expressing my own opinion in response to the request from
Council.  But it seems every time GLEP55 is mentioned, there is a
cascade of emotional responses, but I don't see anything in GLEP55 worth
any sort of emotional response, so consider this directed at council.
If anyone has technical issues with it, please either make them as such
and leave out the personal attacks.

1.  For some reason, there were comments about the writing style used in
GLEP55.  Personally, I find it clear enough, and would expect that it
would be revised once Council settles on whether to adopt the proposed
solution or one of its alternatives. (That's why it's marked as a
draft.) In my opinion, as it stands it clearly shows the necessity for
it or its equivalent (one of the alternatives it mentions);

2.  I said that no matter what we do, I think we need a new extension;

3.  Personally, I prefer .eb (with eapi defined elsewhere)
to .ebuild-<eapi>, but I view that as more a matter of taste than a
major technical matter;

4.  Personally, I prefer ${PN}-${PVR}.eapi-<eapi>.eb (or a syntactic
equivalent); again, that is a matter of taste and performance;

5.  As an alternative, I have no problems with ${PN}-${PVR}.eb and using
#!eapi <eapi> as the first line of the .eb[uild] file.  In that case, I
suppose you could even follow through and source a program called
'eapi', but that's a PM implementation issue outside the scope of the
GLEP.  The argument against this is performance hit, I guess, and on
that I am not qualified to comment.

6.  My remarks about -scm were merely meant to show that once you
introduce the .eb extension, you can implement GLEP54 transparently in
whatever manner excites you.

As I said at the beginning, these are my personal preferences addressed
to Council in response to their request.  If others have preferences
which differ, please take them up with me (I am open to persuasion), and
please leave the emotion out of it.  But I think GLEP55 adequately makes
the case for it or one of the alternatives it mentions, so don't bother
arguing with me on that matter.  It's Council you need to convince, not
me.

Regards,
Ferris
-- 
Ferris McCormick (P44646, MI) <fmccor@gentoo.org>
Developer, Gentoo Linux (Sparc, Userrel, Trustees)

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Roy Bamford]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2009.05.28 06:46, Tiziano Müller wrote:
[snip]
> I did some analysis on that. The result is that the the performance
> penalty of not having the EAPI not in the filename depends on various
> factors. But it is for sure that there is a performance penalty.
It needs to be quantified in the GLEP.
Nobody wants to trawl this list looking for it.

> 
[snip the process - its an implementaion detail]
> So, one of the main differences is: "reading one cache file" (if
> running
> unstable you can asssume you support the highest version, thus 
> reading
> only one cache file) vs. "reading all cache files".
> 
> I did some performance measurements based on that. I have 1507
> installed
> packages with 5541 different versions/revisions.
> 
> Reading from hot cache:
> 1507 files: ~50ms
> 5541 files: ~170ms
> 
> Reading from cold cache:
> 1507 files: ~2.8s
> 5541 files: ~6s
As I understand this, it may add six seconds to an emerge world while 
the dep tree is calculated. Lets say it takes an hour to do emerge 
world, the time has increased from 3600 seconds to 3606 seconds or a 
trivial 0.1666667%

We are clearly concentrating our efforts in wrong area, trying to 
reduce the six seconds.
> 
> I made a lot of assumptions here (neglecting seek between ebuild-dir
> and
> metadata-dir, other processes using the drive, 80 ebuilds from
> overlays
> where the ebuild would have to be read, etc.). But estimating from 
> the
> numbers above I'd say that a "emerge -uD world"/"paludis -i world"
> will
> be at least twice as slow, which I think is not acceptable.

You mean 0.3% (or less) of the emerge world time?

> 
> And I also don't understand your point of stating it's "bad design". 
> I mean: when coding you should "not optimize prematurely", but with
> eapi-in-ebuild it is against the other principle of "not pessimize
> prematurely" (Sutter/Alexandrescu: C++ Coding Standards).

Coding Standards (whatever language) are not relevant. My point comes 
from Systems Design, before your write the Systems Requirement Document 
and the System Implementation Plan and even the Top Level Design 
document. ... thats a long time before you write any code. 

I am against *all* and any metadata in the filename. Today, GLEP 55 
proposes the add the EAIP, tomorrow, there will be something else,
the day after another thing ... and all because allowing EAPI set the 
precedent.

You also make the error of assuming that with eapi-in-ebuild the 
currently suggested approaches to extracting the EAPI from the ebuild 
are the best and remain unchanged. Thats unlikely, as not a lot of work 
has been done it yet.
> 
> 
> -- 
> Tiziano Müller
> Gentoo Linux Developer, Council Member
> Areas of responsibility:
>   Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
> E-Mail   : dev-zero@gentoo.org
> GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30
> 

- -- 
Regards,

Roy Bamford
(NeddySeagoon) a member of
gentoo-ops
forum-mods
treecleaners
trustees
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkoe0DYACgkQTE4/y7nJvasUGwCglincQpLkCw7C09Z4zNTY1PL1
s1gAoK7NTbOl5tdGOngtufe81ocwNRXp
=Ru66
-----END PGP SIGNATURE-----

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

[Ciaran McCreesh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 28 May 2009 18:56:00 +0100
Roy Bamford <neddyseagoon@gentoo.org> wrote:
> As I understand this, it may add six seconds to an emerge world while 
> the dep tree is calculated. Lets say it takes an hour to do emerge 
> world, the time has increased from 3600 seconds to 3606 seconds or a 
> trivial 0.1666667%

Interactive time is important. If it were adding those extra seconds to
the build, no-one would care. But it's not. It's adding them to when
the user's sitting at the screen waiting for results.

> You mean 0.3% (or less) of the emerge world time?

No, he means 50% of pretend time when you're sitting there waiting to
see what's going to happen.

> I am against *all* and any metadata in the filename. Today, GLEP 55 
> proposes the add the EAIP, tomorrow, there will be something else,
> the day after another thing ... and all because allowing EAPI set the 
> precedent.

No there won't be. There is no slippery slope. Also, PV and PN are
already in the filename.

> You also make the error of assuming that with eapi-in-ebuild the 
> currently suggested approaches to extracting the EAPI from the ebuild 
> are the best and remain unchanged. Thats unlikely, as not a lot of
> work has been done it yet.

It is the best. If we're requiring EAPI before trying to parse PV, all
the EAPIs have to be known to do any ordering.

- -- 
Ciaran McCreesh
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkoe0iQACgkQ96zL6DUtXhEUrQCgoFztweuK3QRU2Ff0b0r6Otri
D8sAoLSF9hv+4k5xG+k69s8z8NanNN+I
=yO/c
-----END PGP SIGNATURE-----

Re: [gentoo-dev] How not to discuss

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 6248 bytes --]

On Thu, 28 May 2009 08:28:12 +0200
Patrick Lauer <patrick@gentoo.org> wrote:
> - Try to avoid subjective statements. Statements like "C++ feels
> better" don't add anything to the discussion and are objectively
> wrong for me, so they have no place in a technical discussion

You mean like "EAPI in the filename feels bad"? I agree, that has no
place in a technical discussion.

> > Not once has there been an equally good alternative proposed.
> 
> That's subjective, and let me be the first one to disagree.

No, it's entirely objective. GLEP 55 clearly shows how the filename
based options are objectively better than anything else.

> > > > GLEP titles are required to be short.
> Yes, that is a reasonable demand. It is completely independent of the
> demand that the title describes the _problem_ and not your solution.

The title describes the proposed enhancement.

> > Doesn't cover the intent of the enhancement. The intent of the
> > enhancement is to use EAPI suffixed ebuilds.
> 
> No, the intent is to find a better way to determine the EAPI. One
> proposed solution is the use of a suffix. Please stop trying to
> distract people in semantic games, it is dishonest.

No, the intent of the enhancement is to switch to EAPI in the filename.

> This is an important point - define the problem first, then discuss
> solutions.

The problem is defined as the first part of the main body of the GLEP.

> > Yes, and the quick summary of the GLEP is that EAPI suffixed file
> > extensions should be used for ebuilds.
> 
> No, that is the solution favoured by one group of people.

...and it is the proposed enhancement.

> > You're being overly harsh on Piotr there. GLEPs aren't supposed to
> > be written to peer review journal standards -- they're supposed to
> > be technical material that can be understood by the appropriate
> > audience and used to propose an enhancement, not something that has
> > to stand in archives for a thousand years.
> And still one would expect a minimal coherence - stating the problem
> (not there), discussing alternatives (incomplete and phrased in a way
> to make them look extra bad) and maybe a comparison (mostly missing).

Please re-read the GLEP. All the things you claim aren't there are.

> Which points at a simple solution that gets mostly ignored: Since we
> already state EAPI explicitly we can restrict ourselves to parsing it
> (with a regexp, maybe) instead of having to source the ebuild. Which
> has to happen anyway as soon as you need metadata ...

Uhm. No. It's needed as soon as you need metadata if there's no cache.
Biiiiig difference. If we were sourcing for metadata regardless, it'd
be unusably slow.

> > Congratulations. That is what this whole thing is about, and GLEP 55
> > presents the best way of doing that changing.
> 
> No, GLEP55 is the hackish way of sweeping it under the rug. Feel free
> to implement it in an experimental overlay and report back what your
> experiences are in, say, 3 months ...

kdebuild-1 demonstrated the viability of the technique.

> > > Definition of problem is flawed within GLEP55
> >
> > No, the definition of the problem is entirely accurate and correct.
> 
> ... wait, you defined the problem now? I thought GLEP55 was all about
> the solution. Or are you deliberately trying a switch-and-bate ?

Did you read GLEP 55?

> > The title describes the desired enhancement, yes.
> ... which completely ignores stating the problem.

... because there's a length limit. The title is not a substitute for
reading the GLEP.

> > > 2) the Abstraction is all about the solution
> >
> > The abstract describes the desired enhancement in more detail, yes.
> ... enhancing what to achieve what why?

The abstract is not a substitute for reading the GLEP.

> > > THEN finally we get the actual problem
> >
> > The main proposal then expands upon the background and reasoning
> > behind the enhancement, yes.
> Oh, you gotta read it backwards. That's awesome. No wait, the other
> thing. Stupid!

You read the introductory material, then if you want details you read
the rest. Simple.

> > It's not something that's only true as a
> > result of an implementation; implementations can be improved, but
> > penalties from definition can't be fixed.
> Hmm. I'm not quite sure how to parse that. Does that mean that we
> need to abstractly discuss various options (which would go against
> your interpretation of the process), or does that mean that the idea
> of glep55 is flawed (which would be a rather interesting concession
> coming from you)?

I shall explain it to you in simple terms: there can be two reasons for
"x is slower". Either the implementation of x is bad, in which case it
can be improved, or the definition of what x has to do requires
slowness, in which case you can't fix it. For example, an
implementation might be slow because it doesn't carefully avoid doing
more disk work than necessary, in which case it can be fixed, or it
might be slow because the specification of what it does requires it to
do lots of disk work, in which case it can't.

> > > Infact it has already been stated:
> > > "Adding metadata to the filename is not required and is bad system
> > > design practice"
> >
> > Stating something doesn't make it true. You could just as easily
> > argue that having PV in the filename is bad.
>
> Ignoring it doesn't make it go away. Reasonable discussion would be
> the best thing to do now ... are you willing to do that instead of
> running in circles and barking the same dog-matic statements?

Please go back to your "nothing subjective" comment.

> > > 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
> >
> > The reason is that there is no equally good alternative.
> 
> The reason is that GLEP55 is no reasonable alternative to the rest.

We've already established that a fix is necessary. Now we're just
discussing which fix is best, and GLEP 55 conclusively provides the
answer.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

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

[Patrick Lauer]

On Thursday 28 May 2009 20:04:18 Ciaran McCreesh wrote:
> On Thu, 28 May 2009 18:56:00 +0100
>
> Roy Bamford <neddyseagoon@gentoo.org> wrote:
> > As I understand this, it may add six seconds to an emerge world while
> > the dep tree is calculated. Lets say it takes an hour to do emerge
> > world, the time has increased from 3600 seconds to 3606 seconds or a
> > trivial 0.1666667%
>
> Interactive time is important. If it were adding those extra seconds to
> the build, no-one would care. But it's not. It's adding them to when
> the user's sitting at the screen waiting for results.

So how about we improve the structure instead of trying to patch up some 
hotspots?
For example a readonly repository would guarantee that the cache is always 
consistent. Then you can add some smart indexes, and suddenly you're no longer 
limited by IO but by CPU. Last time I saw someone try the raw metadata for all 
ebuilds was smaller than 5MB, which can be read by a modern harddisk in under 
half a second - doesn't that sound quite motivating?

> > You mean 0.3% (or less) of the emerge world time?
>
> No, he means 50% of pretend time when you're sitting there waiting to
> see what's going to happen.

So fix the diseases instead of doctoring around some symptoms ...

> > I am against *all* and any metadata in the filename. Today, GLEP 55
> > proposes the add the EAIP, tomorrow, there will be something else,
> > the day after another thing ... and all because allowing EAPI set the
> > precedent.
>
> No there won't be. There is no slippery slope.
And there's no intention of building a wall ;)

> Also, PV and PN are already in the filename.
That is needed to keep the filename reasonably unique. If you know of a nicer 
way to uniqueify it feel free to tell us ... 
>
> > You also make the error of assuming that with eapi-in-ebuild the
> > currently suggested approaches to extracting the EAPI from the ebuild
> > are the best and remain unchanged. Thats unlikely, as not a lot of
> > work has been done it yet.
>
> It is the best. If we're requiring EAPI before trying to parse PV, all
> the EAPIs have to be known to do any ordering.

... and why the [censored] would we want that then?

I mean, seriously. That is a circular argument. 
It also ignores everything said by Roy, denying even the possibility of an 
alternative. Last time I saw that style of argumentation was in a documentary 
that showed how darwinism couldn't be right (and still those people believe in 
the flu. Ha.)

It would help if you would tolerate other opinions (or even the possibility 
that other people may have opinions that do not agree with you). Roy, as an 
experienced engineer and as far as I know project manager,  might have a good 
idea or two about how to make things not blow up, and it might be in our best 
interest to listen to him for a minute or two.

Re: [gentoo-dev] How not to discuss

[Alec Warner]

On Thu, May 28, 2009 at 11:14 AM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Thu, 28 May 2009 08:28:12 +0200
> Patrick Lauer <patrick@gentoo.org> wrote:
>> - Try to avoid subjective statements. Statements like "C++ feels
>> better" don't add anything to the discussion and are objectively
>> wrong for me, so they have no place in a technical discussion
>
> You mean like "EAPI in the filename feels bad"? I agree, that has no
> place in a technical discussion.
>
>> > Not once has there been an equally good alternative proposed.
>>
>> That's subjective, and let me be the first one to disagree.
>
> No, it's entirely objective. GLEP 55 clearly shows how the filename
> based options are objectively better than anything else.

But the decision will not be based entirely on objective merits
(although I will concede that EAPI in filename is the 'best' technical
choice).  If the community does not wish to adopt more metadata in the
filename then it doesn't matter how 'better' the choice is; because it
will not be accepted.  If we can make the #!EAPI=5 crap work fast
enough and it is accepted, then I think that is good enough (minor
speed cost against actually implementing this change, versus
discussing eapi-in-filename for another 2 years).

>
>> > > > GLEP titles are required to be short.
>> Yes, that is a reasonable demand. It is completely independent of the
>> demand that the title describes the _problem_ and not your solution.
>
> The title describes the proposed enhancement.
>
>> > Doesn't cover the intent of the enhancement. The intent of the
>> > enhancement is to use EAPI suffixed ebuilds.
>>
>> No, the intent is to find a better way to determine the EAPI. One
>> proposed solution is the use of a suffix. Please stop trying to
>> distract people in semantic games, it is dishonest.
>
> No, the intent of the enhancement is to switch to EAPI in the filename.

Then your enhancement has a very low probability of getting approved;
because your premise is incorrect in the eyes of a number of people.

>
>> This is an important point - define the problem first, then discuss
>> solutions.
>
> The problem is defined as the first part of the main body of the GLEP.
>
>> > Yes, and the quick summary of the GLEP is that EAPI suffixed file
>> > extensions should be used for ebuilds.
>>
>> No, that is the solution favoured by one group of people.
>
> ...and it is the proposed enhancement.
>
>> > You're being overly harsh on Piotr there. GLEPs aren't supposed to
>> > be written to peer review journal standards -- they're supposed to
>> > be technical material that can be understood by the appropriate
>> > audience and used to propose an enhancement, not something that has
>> > to stand in archives for a thousand years.
>> And still one would expect a minimal coherence - stating the problem
>> (not there), discussing alternatives (incomplete and phrased in a way
>> to make them look extra bad) and maybe a comparison (mostly missing).
>
> Please re-read the GLEP. All the things you claim aren't there are.
>
>> Which points at a simple solution that gets mostly ignored: Since we
>> already state EAPI explicitly we can restrict ourselves to parsing it
>> (with a regexp, maybe) instead of having to source the ebuild. Which
>> has to happen anyway as soon as you need metadata ...
>
> Uhm. No. It's needed as soon as you need metadata if there's no cache.
> Biiiiig difference. If we were sourcing for metadata regardless, it'd
> be unusably slow.
>
>> > Congratulations. That is what this whole thing is about, and GLEP 55
>> > presents the best way of doing that changing.
>>
>> No, GLEP55 is the hackish way of sweeping it under the rug. Feel free
>> to implement it in an experimental overlay and report back what your
>> experiences are in, say, 3 months ...
>
> kdebuild-1 demonstrated the viability of the technique.
>
>> > > Definition of problem is flawed within GLEP55
>> >
>> > No, the definition of the problem is entirely accurate and correct.
>>
>> ... wait, you defined the problem now? I thought GLEP55 was all about
>> the solution. Or are you deliberately trying a switch-and-bate ?
>
> Did you read GLEP 55?
>
>> > The title describes the desired enhancement, yes.
>> ... which completely ignores stating the problem.
>
> ... because there's a length limit. The title is not a substitute for
> reading the GLEP.
>
>> > > 2) the Abstraction is all about the solution
>> >
>> > The abstract describes the desired enhancement in more detail, yes.
>> ... enhancing what to achieve what why?
>
> The abstract is not a substitute for reading the GLEP.
>
>> > > THEN finally we get the actual problem
>> >
>> > The main proposal then expands upon the background and reasoning
>> > behind the enhancement, yes.
>> Oh, you gotta read it backwards. That's awesome. No wait, the other
>> thing. Stupid!
>
> You read the introductory material, then if you want details you read
> the rest. Simple.
>
>> > It's not something that's only true as a
>> > result of an implementation; implementations can be improved, but
>> > penalties from definition can't be fixed.
>> Hmm. I'm not quite sure how to parse that. Does that mean that we
>> need to abstractly discuss various options (which would go against
>> your interpretation of the process), or does that mean that the idea
>> of glep55 is flawed (which would be a rather interesting concession
>> coming from you)?
>
> I shall explain it to you in simple terms: there can be two reasons for
> "x is slower". Either the implementation of x is bad, in which case it
> can be improved, or the definition of what x has to do requires
> slowness, in which case you can't fix it. For example, an
> implementation might be slow because it doesn't carefully avoid doing
> more disk work than necessary, in which case it can be fixed, or it
> might be slow because the specification of what it does requires it to
> do lots of disk work, in which case it can't.
>
>> > > Infact it has already been stated:
>> > > "Adding metadata to the filename is not required and is bad system
>> > > design practice"
>> >
>> > Stating something doesn't make it true. You could just as easily
>> > argue that having PV in the filename is bad.
>>
>> Ignoring it doesn't make it go away. Reasonable discussion would be
>> the best thing to do now ... are you willing to do that instead of
>> running in circles and barking the same dog-matic statements?
>
> Please go back to your "nothing subjective" comment.
>
>> > > 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
>> >
>> > The reason is that there is no equally good alternative.
>>
>> The reason is that GLEP55 is no reasonable alternative to the rest.
>
> We've already established that a fix is necessary. Now we're just
> discussing which fix is best, and GLEP 55 conclusively provides the
> answer.

The community could of course just deny the features that require
glep55 (no bash4, no global scope changes, etc..)  I guess the
community is doing that by default anyway by repeated discussing this
glep and not implementing anything.

>
> --
> Ciaran McCreesh
>

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1654 bytes --]

On Thu, 28 May 2009 20:30:44 +0200
Patrick Lauer <patrick@gentoo.org> wrote:
> > Interactive time is important. If it were adding those extra
> > seconds to the build, no-one would care. But it's not. It's adding
> > them to when the user's sitting at the screen waiting for results.
> 
> So how about we improve the structure instead of trying to patch up
> some hotspots?

That's a subject for a different GLEP, and one that's not going to go
anywhere ever unless someone comes up with a way of doing it
incrementally. GLEP 55's performance concerns are limited to not making
things worse.

> For example a readonly repository would guarantee that the cache is
> always consistent.

Until someone modifies it, yes.

> > > You mean 0.3% (or less) of the emerge world time?
> >
> > No, he means 50% of pretend time when you're sitting there waiting
> > to see what's going to happen.
> 
> So fix the diseases instead of doctoring around some symptoms ...

I await your GLEP that covers how to migrate the tree layout. That's a
separate issue, however.

> > It is the best. If we're requiring EAPI before trying to parse PV,
> > all the EAPIs have to be known to do any ordering.
> 
> ... and why the [censored] would we want that then?

Because without that, we can't make changes to the version format.

> It would help if you would tolerate other opinions (or even the
> possibility that other people may have opinions that do not agree
> with you).

The only issue of opinion is whether or not .ebuild-X and .eapi-X.eb
look pretty. The rest is purely technical and entirely objective.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] How not to discuss

[Patrick Lauer]

On Thursday 28 May 2009 20:14:57 Ciaran McCreesh wrote:
> On Thu, 28 May 2009 08:28:12 +0200
>
> Patrick Lauer <patrick@gentoo.org> wrote:
> > - Try to avoid subjective statements. Statements like "C++ feels
> > better" don't add anything to the discussion and are objectively
> > wrong for me, so they have no place in a technical discussion
>
> You mean like "EAPI in the filename feels bad"? I agree, that has no
> place in a technical discussion.
>
> > > Not once has there been an equally good alternative proposed.
> >
> > That's subjective, and let me be the first one to disagree.
>
> No, it's entirely objective. GLEP 55 clearly shows how the filename
> based options are objectively better than anything else.
>
Ciaran ... you're obviously trying to bait people here.

Please don't do that. Trolling is not something you should do on public 
mailing lists.

I could spend lots of time trying to dissect your monologue, but if you are 
unwilling to accept that your opinion is subjective and that my opinion may 
differ from yours any further communication would be futile.

Now you may still think (subjective thing, that) that glep55 is the best 
solution. And I, with the same subjectivity, think it isn't. Trying to weasel 
your way around that with semantic games is not going to change the objective 
reality we both share. Get used to it.

And once you get used to that we can start a dialogue. Imagine that.

Re: [gentoo-dev] How not to discuss

[Roy Bamford]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2009.05.28 19:36, Alec Warner wrote:
[snip]
> 
> The community could of course just deny the features that require
> glep55 (no bash4, no global scope changes, etc..)  I guess the
> community is doing that by default anyway by repeated discussing this
> glep and not implementing anything.
> 
> 
> 
[snip]

GLEP55 is not in a fit state to be approved. Its a technical paper 
submitted to this list for peer review. As many have pointed out, as a 
technical paper. it lacks quantified, objective discussion of the 
problem and the various solutions it touches on.

- -- 
Regards,

Roy Bamford
(NeddySeagoon) a member of
gentoo-ops
forum-mods
treecleaners
trustees
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkoe3vkACgkQTE4/y7nJvatqXQCfR70cUj06JN4bOFuccihREE6x
J18Ani/YQ5jSLql6X3uff27FHfkrZFgp
=J2CX
-----END PGP SIGNATURE-----

Re: [gentoo-dev] How not to discuss

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 427 bytes --]

On Thu, 28 May 2009 20:49:54 +0200
Patrick Lauer <patrick@gentoo.org> wrote:
> Now you may still think (subjective thing, that) that glep55 is the
> best solution. And I, with the same subjectivity, think it isn't.

GLEP 55 shows that other solutions require either a design-enforced
performance penalty or remove the ability to change how versions are
handled. This is not a subjective matter.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] How not to discuss

[Joe Peterson]

Alec Warner wrote:
>> No, it's entirely objective. GLEP 55 clearly shows how the filename
>> based options are objectively better than anything else.
> 
> But the decision will not be based entirely on objective merits
> (although I will concede that EAPI in filename is the 'best' technical
> choice).

(Jeez, I hate to add another to this thread, but this way of defining
'technical' bothers me)

Along the lines of what Roy so eloquently expressed, I think it's
important that we do not divorce *design* from *technical*.  The
decision of where to place the EAPI is a design issue, and many of us
here clearly believe that it is *not* good design to put this kind of
metadata in the filename.  Therefore, the statement that it is the
'best' technical choice is not objectively true.

Technical issues of performance and efficiency can be addressed when
proper design has been done beforehand.  Part of the purpose of the
implementation (after proper design is in place) is to address
performance and other related issues.  And part of the design is how we
define the *interface*.  The filename is clearly part of the interface.
 It is part of how devs (and users) interact with portage when writing
ebuilds.  Much of the argument for EAPI in the filename has been
motivated by a perceived implementation benefit of speed, as if there
were no other solutions (which is naive).  As Roy suggested, if all
engineering decisions were based purely on pragmatic "ease of
implementation" factors, we'd have a lot of ugly designs/interfaces out
there.

It may be easy (although incorrect) to dismiss elegance/design/interface
issues as "non-technical", but I maintain they actually *are* technical
matters of great importance.  I've been an engineer for over 20 years,
and I have seen the pitfalls of taking the quick-and-dirty approach just
to slap a new feature into a software app.  I've seen how such hasty
design mistakes can cause great pain and regret for a long time after.
Let's get the design right, first.  For what it's worth, GLEP 55 does
now provide an option (#3: Easily fetchable EAPI inside the ebuild and
one-time extension change) that demonstrates good design.

						-Joe

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

[Patrick Lauer]

You know, usually snipping away everything else is a bit evil because it 
removes context, but in this case I just want to point out one or two little 
pieces ...

I almost feel bad for writing so many emails to this list.

On Thursday 28 May 2009 20:48:45 Ciaran McCreesh wrote:
> > For example a readonly repository would guarantee that the cache is
> > always consistent.
>
> Until someone modifies it, yes.
>
Well. DUH. That's why it is readonly. Otherwise it wouldn't be readonly.

> > > It is the best. If we're requiring EAPI before trying to parse PV,
> > > all the EAPIs have to be known to do any ordering.
> >
> > ... and why the [censored] would we want that then?
>
> Because without that, we can't make changes to the version format.

... why?

I mean, you're turning in a tight little circle. We need to change the version 
format ... because ... we ... need to change it.

But WHY do we want it? 

> > It would help if you would tolerate other opinions (or even the
> > possibility that other people may have opinions that do not agree
> > with you).
>
> The only issue of opinion is whether or not .ebuild-X and .eapi-X.eb
> look pretty. The rest is purely technical and entirely objective.

I think I have pointed you a few times at objective statements disagreeing 
with your subjective opinion. I hate repeating myself.

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 2119 bytes --]

On Thu, 28 May 2009 21:19:35 +0200
Patrick Lauer <patrick@gentoo.org> wrote:
> You know, usually snipping away everything else is a bit evil because
> it removes context, but in this case I just want to point out one or
> two little pieces ...

Because you know fine well I'm right, but want to carry on trying to
derail progress?

> I almost feel bad for writing so many emails to this list.

Yes, please stop.

> > > For example a readonly repository would guarantee that the cache
> > > is always consistent.
> >
> > Until someone modifies it, yes.
> >
> Well. DUH. That's why it is readonly. Otherwise it wouldn't be
> readonly.

And just how do you plan to enforce that? What measures will you take
to ensure that there's no way for developers or users to modify the
repository?

> > > > It is the best. If we're requiring EAPI before trying to parse
> > > > PV, all the EAPIs have to be known to do any ordering.
> > >
> > > ... and why the [censored] would we want that then?
> >
> > Because without that, we can't make changes to the version format.
> 
> ... why?

Why what? Why can't we make changes, or why would we want to?

We can't make changes because the package manager needs to know the
EAPI in order to parse versions, since once we make changes versions
will be defined in terms of EAPI.

We want to make changes because, as has been stated several times
previously, allowing 1.1_rc1 but forbidding 1.1-rc1 is entirely silly
and arbitrary.

> > > It would help if you would tolerate other opinions (or even the
> > > possibility that other people may have opinions that do not agree
> > > with you).
> >
> > The only issue of opinion is whether or not .ebuild-X and .eapi-X.eb
> > look pretty. The rest is purely technical and entirely objective.
> 
> I think I have pointed you a few times at objective statements
> disagreeing with your subjective opinion. I hate repeating myself.

And yet you keep ignoring the part where GLEP 55 demonstrates
objectively that the extension solution is better than the alternatives.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] How not to discuss

[Piotr Jaroszyński]

2009/5/28 Joe Peterson <lavajoe@gentoo.org>:
> Alec Warner wrote:
>>> No, it's entirely objective. GLEP 55 clearly shows how the filename
>>> based options are objectively better than anything else.
>>
>> But the decision will not be based entirely on objective merits
>> (although I will concede that EAPI in filename is the 'best' technical
>> choice).
>
> (Jeez, I hate to add another to this thread, but this way of defining
> 'technical' bothers me)
>
> Along the lines of what Roy so eloquently expressed, I think it's
> important that we do not divorce *design* from *technical*.  The
> decision of where to place the EAPI is a design issue, and many of us
> here clearly believe that it is *not* good design to put this kind of
> metadata in the filename.  Therefore, the statement that it is the
> 'best' technical choice is not objectively true.
>
> Technical issues of performance and efficiency can be addressed when
> proper design has been done beforehand.  Part of the purpose of the
> implementation (after proper design is in place) is to address
> performance and other related issues.  And part of the design is how we
> define the *interface*.  The filename is clearly part of the interface.
>  It is part of how devs (and users) interact with portage when writing
> ebuilds.  Much of the argument for EAPI in the filename has been
> motivated by a perceived implementation benefit of speed, as if there
> were no other solutions (which is naive).  As Roy suggested, if all
> engineering decisions were based purely on pragmatic "ease of
> implementation" factors, we'd have a lot of ugly designs/interfaces out
> there.
>
> It may be easy (although incorrect) to dismiss elegance/design/interface
> issues as "non-technical", but I maintain they actually *are* technical
> matters of great importance.  I've been an engineer for over 20 years,
> and I have seen the pitfalls of taking the quick-and-dirty approach just
> to slap a new feature into a software app.  I've seen how such hasty
> design mistakes can cause great pain and regret for a long time after.
> Let's get the design right, first.  For what it's worth, GLEP 55 does
> now provide an option (#3: Easily fetchable EAPI inside the ebuild and
> one-time extension change) that demonstrates good design.

I think what you are missing is that some people (me included) think
that the in-file approach is the cleanest and most obvious solution
(which also happens to not hurt performance). So if you want "bad
design" to be an objective argument you need to back it up with
something concrete. For example, could you foresee any actual problems
of the in-filename approach? Cause all I was hearing was "it doesn't
look nice" which now is "oh no, don't expose metadata". The former is
clearly subjective and the latter is already done ($PN-$PV) and
doesn't seem to cause any problems.

-- 
Best Regards,
Piotr Jaroszyński

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

[Josh Saddler]

[-- Attachment #1: Type: text/plain, Size: 1046 bytes --]

Ladies, please. Put the tampons back in and take a Midol.

* * *

GLEP55 has not effectively shown that there *is* a problem, otherwise we
wouldn't have had months of discussion on that topic. Nor has it shown
that its proposed solution *is* the best solution, otherwise we would
have adopted it months ago instead of dicking about on the mailing lists
with clever doublespeak dodging, like an e-penis jousting tournament.

There are serious issues related to the wording of the GLEP and its
proposed solution, as the majority of list replies have stated for the
last few months. Pretending they don't exist without listing each and
every single one (as I'm sure the proponents of the GLEP would like) is
just ostriching.

Telling someone "It's my way or nothing, because nothing else is valid
and nothing else will work and no one has a better idea than me" is
stonewalling, and it is entirely counterproductive. Perhaps that tactic
works in *some* pet distributions and package managers, but it does not
work for Gentoo.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Roy Bamford]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2009.05.28 20:26, Ciaran McCreesh wrote:
[snip]

> > I think I have pointed you a few times at objective statements
> > disagreeing with your subjective opinion. I hate repeating myself.
> 
> And yet you keep ignoring the part where GLEP 55 demonstrates
> objectively that the extension solution is better than the
> alternatives.
> 
> -- 
> Ciaran McCreesh
> 

Ciaran, 

I don't see any objective measurements of performace in GLEP 55 either.
perhaps you could point me to a version and pargraph in GLEP that 
details these benchmarks ?

Its possible I'm looking at an old version. 

- -- 
Regards,

Roy Bamford
(NeddySeagoon) a member of
gentoo-ops
forum-mods
treecleaners
trustees
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkoe6SsACgkQTE4/y7nJvastiACdGB9T5AxloneQVrcY34liSvIf
5BkAoLQwpuLOw+ueGMrmecYAoPk8AsYn
=gF09
-----END PGP SIGNATURE-----

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 314 bytes --]

On Thu, 28 May 2009 12:42:02 -0700
Josh Saddler <nightmorph@gentoo.org> wrote:
> GLEP55 has not effectively shown that there *is* a problem, otherwise
> we wouldn't have had months of discussion on that topic.

Uh. Did you miss the part where we need global scope changes in ebuilds?

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

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

[Patrick Lauer]

On Thursday 28 May 2009 21:26:43 Ciaran McCreesh wrote:
> On Thu, 28 May 2009 21:19:35 +0200
>
> Patrick Lauer <patrick@gentoo.org> wrote:
> > You know, usually snipping away everything else is a bit evil because
> > it removes context, but in this case I just want to point out one or
> > two little pieces ...
>
> Because you know fine well I'm right, but want to carry on trying to
> derail progress?

That's an interesting concept. But you know as well as I do that it isn't so, 
thus we have to classify your statement as a mediocre trolling attempt. Bonus 
for the anticipated emotional response, but I hope you're not too upset when I 
don't satisfy you with some mindless flaming. This mailinglist just isn't the 
right place for it ...


> > > > For example a readonly repository would guarantee that the cache
> > > > is always consistent.
> > >
> > > Until someone modifies it, yes.
> >
> > Well. DUH. That's why it is readonly. Otherwise it wouldn't be
> > readonly.
>
> And just how do you plan to enforce that? What measures will you take
> to ensure that there's no way for developers or users to modify the
> repository?
I can think of many simple methods. Like a tarball with a checksum. Or a 
zipfile. Or a git repository. That's all implementation details. But I think 
we can agree without too much pain that it is possible to have a reasonably 
tamper-proof format that we can consider readonly for these purposes.
And automatically creating it is not much different from generating rsync 
snapshots now. I guess, smart as you are, you knew that already.

> We can't make changes because the package manager needs to know the
> EAPI in order to parse versions, since once we make changes versions
> will be defined in terms of EAPI.
... why? You're stating one possible scenario as the only potential solution 
again. That ignores the other methods that were mentioned on this mailinglist 
and in other places where you lurk. Please stop being so dishonest.


> We want to make changes because, as has been stated several times
> previously, allowing 1.1_rc1 but forbidding 1.1-rc1 is entirely silly
> and arbitrary.
See Intercal versioning. Also silly and arbitrary to avoid it, but noone has 
provided a proposal to accomodate nonincreasing and nonmonotonic versioning 
systems. I doubt you would want those allowed.

> > > > It would help if you would tolerate other opinions (or even the
> > > > possibility that other people may have opinions that do not agree
> > > > with you).
> > >
> > > The only issue of opinion is whether or not .ebuild-X and .eapi-X.eb
> > > look pretty. The rest is purely technical and entirely objective.
> >
> > I think I have pointed you a few times at objective statements
> > disagreeing with your subjective opinion. I hate repeating myself.
>
> And yet you keep ignoring the part where GLEP 55 demonstrates
> objectively that the extension solution is better than the alternatives.

I really. Really. Hate repeating myself. 
It's so redundantly superfluously redundant. And it wastes people's time. Did 
I mention it is redundant?

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 2200 bytes --]

On Thu, 28 May 2009 21:46:48 +0200
Patrick Lauer <patrick@gentoo.org> wrote:
> > And just how do you plan to enforce that? What measures will you
> > take to ensure that there's no way for developers or users to
> > modify the repository?
> I can think of many simple methods. Like a tarball with a checksum.

...which a user can modify once it's been extracted.

> Or a zipfile.

...which a user can modify once it's been extracted.

> Or a git repository.

...which a user can commit to without telling the package manager that
the cache is now invalid.

> That's all implementation details. But I think we can agree without
> too much pain that it is possible to have a reasonably tamper-proof
> format that we can consider readonly for these purposes.

No, I do not in the slightest bit agree that there is an easy way of
ensuring that what the package manager sees hasn't been tinkered with
by a user or developer who "just wants to try a quick change out".

> > We can't make changes because the package manager needs to know the
> > EAPI in order to parse versions, since once we make changes versions
> > will be defined in terms of EAPI.
>
> ... why? You're stating one possible scenario as the only potential
> solution again. That ignores the other methods that were mentioned on
> this mailinglist and in other places where you lurk. Please stop
> being so dishonest.

No-one has provided a viable way of extending the version format that
doesn't require EAPI changes. So unless you're talking about your
"start a whole new tree" idea, which has already been debunked to
death...

> > We want to make changes because, as has been stated several times
> > previously, allowing 1.1_rc1 but forbidding 1.1-rc1 is entirely
> > silly and arbitrary.
> See Intercal versioning. Also silly and arbitrary to avoid it, but
> noone has provided a proposal to accomodate nonincreasing and
> nonmonotonic versioning systems. I doubt you would want those allowed.

No-one is suggesting making changes to match silly upstream versions.
What we are suggesting is making changes to match sensible and
reasonable upstream versions.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

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

[Ciaran McCreesh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 28 May 2009 20:42:30 +0100
Roy Bamford <neddyseagoon@gentoo.org> wrote:
> I don't see any objective measurements of performace in GLEP 55
> either. perhaps you could point me to a version and pargraph in GLEP
> that details these benchmarks ?

It's not a question of benchmarks. It's a question of being slower by
design. Allow me to explain:

If GLEP 55 were to include benchmarks, they would be dismissed as "well
we can make that code faster", which would be missing the point -- that
it's a design penalty regardless of implementation.

- -- 
Ciaran McCreesh
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkoe6+kACgkQ96zL6DUtXhGqbwCg5Ye1CC5V+WjQ1nArN/eM1hpR
3qwAniS95KnP7FBbnbUiEVJnO5LLIXgF
=FFMi
-----END PGP SIGNATURE-----

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

[Patrick Lauer]

On Thursday 28 May 2009 21:52:49 Ciaran McCreesh wrote:
> On Thu, 28 May 2009 21:46:48 +0200
>
> Patrick Lauer <patrick@gentoo.org> wrote:
> > > And just how do you plan to enforce that? What measures will you
> > > take to ensure that there's no way for developers or users to
> > > modify the repository?
> >
> > I can think of many simple methods. Like a tarball with a checksum.
>
> ...which a user can modify once it's been extracted.
>
> > Or a zipfile.
>
> ...which a user can modify once it's been extracted.
>
> > Or a git repository.
>
> ...which a user can commit to without telling the package manager that
> the cache is now invalid.

So, basically, we can't do anything, because the universe might spontaneously 
decide to cease to exist. Quite scary, that. 

Oh, and if you break stuff it is broken. Splendid!

Your random distraction at least made me giggle, but it is not relevant to the 
discussion of a readonly repository. 

>
> > That's all implementation details. But I think we can agree without
> > too much pain that it is possible to have a reasonably tamper-proof
> > format that we can consider readonly for these purposes.
>
> No, I do not in the slightest bit agree that there is an easy way of
> ensuring that what the package manager sees hasn't been tinkered with
> by a user or developer who "just wants to try a quick change out".

So things blow up. Sometimes Darwin has to do his work, especially when you 
climb over two fences, break open a locked metal door and discover that the 
Ursus arctos is, in fact, a very antisocial carnivore and not as cuddly as you 
thought.

You cannot stop a determined user from painting himself in a corner, but you 
can avoid most cases of accidental damage. 

>
> > > We can't make changes because the package manager needs to know the
> > > EAPI in order to parse versions, since once we make changes versions
> > > will be defined in terms of EAPI.
> >
> > ... why? You're stating one possible scenario as the only potential
> > solution again. That ignores the other methods that were mentioned on
> > this mailinglist and in other places where you lurk. Please stop
> > being so dishonest.
>
> No-one has provided a viable way of extending the version format that
> doesn't require EAPI changes. So unless you're talking about your
> "start a whole new tree" idea,
Wait, I thought noone had provided a way ... except that one ... argh, 
cognitive dissonance detected. 

I'm sorry, you contradicted yourself. Please choose one option only.

> which has already been debunked to
> death...
Weird, that didn't happen in this universe. 

> > > We want to make changes because, as has been stated several times
> > > previously, allowing 1.1_rc1 but forbidding 1.1-rc1 is entirely
> > > silly and arbitrary.
> >
> > See Intercal versioning. Also silly and arbitrary to avoid it, but
> > noone has provided a proposal to accomodate nonincreasing and
> > nonmonotonic versioning systems. I doubt you would want those allowed.
>
> No-one is suggesting making changes to match silly upstream versions.
But I thought you just said that silly and arbitrary restrictions ... I am 
confused. You are in a quantum superposition state where you support both 
sides of an argument and only collapse your brainwave functions whenever 
someone tries to observe you or something ... 

> What we are suggesting is making changes to match sensible and
> reasonable upstream versions.
Which we already have. Excellent, so you agree that we don't need to change 
versioning. Sometimes I really like discussing with you, because after a long 
time you suddenly accept reason :)

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1584 bytes --]

On Thu, 28 May 2009 22:56:46 +0200
Patrick Lauer <patrick@gentoo.org> wrote:
> So, basically, we can't do anything, because the universe might
> spontaneously decide to cease to exist. Quite scary, that. 

No. What we do is don't design a fragile solution. We design a solution
that can handle users doing what we reasonably expect users to do.

> > No-one has provided a viable way of extending the version format
> > that doesn't require EAPI changes. So unless you're talking about
> > your "start a whole new tree" idea,
> Wait, I thought noone had provided a way ... except that one ...
> argh, cognitive dissonance detected. 
> 
> I'm sorry, you contradicted yourself. Please choose one option only.

"Viable".

> > No-one is suggesting making changes to match silly upstream
> > versions.
> But I thought you just said that silly and arbitrary restrictions ...
> I am confused. You are in a quantum superposition state where you
> support both sides of an argument and only collapse your brainwave
> functions whenever someone tries to observe you or something ... 

I said that allowing _rc but forbidding -rc was silly and arbitrary.

> > What we are suggesting is making changes to match sensible and
> > reasonable upstream versions.
>
> Which we already have. Excellent, so you agree that we don't need to
> change versioning. Sometimes I really like discussing with you,
> because after a long time you suddenly accept reason :)

No, we don't allow 1.1-rc1, which is a sensible and reasonable upstream
version.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

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

[Roy Bamford]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2009.05.28 20:54, Ciaran McCreesh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Thu, 28 May 2009 20:42:30 +0100
> Roy Bamford <neddyseagoon@gentoo.org> wrote:
> > I don't see any objective measurements of performace in GLEP 55
> > either. perhaps you could point me to a version and pargraph in
> GLEP
> > that details these benchmarks ?
> 
> It's not a question of benchmarks. It's a question of being slower by
> design. Allow me to explain:
> 
> If GLEP 55 were to include benchmarks, they would be dismissed as
> "well
> we can make that code faster", which would be missing the point --
> that
> it's a design penalty regardless of implementation.
> 
> - -- 
> Ciaran McCreesh
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.9 (GNU/Linux)
> 
> iEYEARECAAYFAkoe6+kACgkQ96zL6DUtXhGqbwCg5Ye1CC5V+WjQ1nArN/eM1hpR
> 3qwAniS95KnP7FBbnbUiEVJnO5LLIXgF
> =FFMi
> -----END PGP SIGNATURE-----
> 
Ciaran,

Having the benchmarks allows consideration of the design trade offs to 
be made. It moves the GLEP one step closer to acceptance, in one form 
or another.

Like tonight at the council meeting, the meeting acknowledged that 
there is one or more problems to be addressed, thats the first step.

The benchmarks are only one piece of the pursuavie evidence.
Speed isn't everything. Let me remind you of an old playground joke,
There is an old bull and a young bull in a field on a hillside, next to 
a herd of cows ....   I'm sure you know it. 

- -- 
Regards,

Roy Bamford
(NeddySeagoon) a member of
gentoo-ops
forum-mods
treecleaners
trustees
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkofAtQACgkQTE4/y7nJvat16QCg2KkRt8+veYkgKiuBvwY6Sgam
7toAoIMdbtTMHR34OkqcxMUxV6Ggi9/u
=aJF8
-----END PGP SIGNATURE-----

[gentoo-dev] Re: How not to discuss

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 925 bytes --]

On Thu, 28 May 2009 08:28:12 +0200
Patrick Lauer <patrick@gentoo.org> wrote:

> This is becoming a rather lengthy email ping pong, but as people seem to be 
> unable to discuss things I had to highlight a few issues there. 

I'm sorry to be rude, but ever consider that the reason people keep repeating
things to you is that you continually misunderstand what they're saying?

I think that by now we've exhausted everything that can possibly be said
about GLEP 55.  Nothing in this discussion is new, nor has it been for some
time.  Can we please just stop now and trust the representatives that we've
elected to make their decision?  Or should we go around the ring one more
time?


-- 
gcc-porting,                                      by design, by neglect
treecleaner,                              for a fact or just for effect
wxwidgets @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: How not to discuss

[Duncan]

Ciaran McCreesh <ciaran.mccreesh@googlemail.com> posted
20090528191457.21ab4546@snowcone, excerpted below, on  Thu, 28 May 2009
19:14:57 +0100:

> No, it's entirely objective. GLEP 55 clearly shows how the filename
> based options are objectively better than anything else.

Now that's just being facetious.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] How not to discuss

[Marijn Schouten (hkBst)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Piotr Jaroszyński wrote:

> I think what you are missing is that some people (me included) think
> that the in-file approach is the cleanest and most obvious solution
> (which also happens to not hurt performance). So if you want "bad
> design" to be an objective argument you need to back it up with
> something concrete. For example, could you foresee any actual problems
> of the in-filename approach? Cause all I was hearing was "it doesn't
> look nice" which now is "oh no, don't expose metadata". The former is
> clearly subjective and the latter is already done ($PN-$PV) and
> doesn't seem to cause any problems.

What we care about doing is being able to install a package of a known name, PN,
with a known version, PV, and we may even want to make sure that the revision,
PR, is just right. Therefore PN, PV and PR are not metadata, but actual data to
identify a specific software unit. (This is also why PR should be bumped if (and
mostly only if) there are changes to files that will be installed.)
On the other hand, EAPI is a value that encodes what is valid in an ebuild and
as such is an implementation detail. Exposing implementation details is bad design.

Actually I think just changing extensions is also an implementation detail. If
we need the user to make certain upgrades (portage, bash) before being able to
use certain ebuilds then we should just tell them. What else are news items for?
As long as we provide an upgrade path from version X_years_old to version
X_days_old via versions A, B and C, I think we have done our part. In fact we
already had one such situation with bash and portage.

Marijn

- --
If you cannot read my mind, then listen to what I say.

Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
<http://www.gentoo.org/proj/en/lisp/>, #gentoo-{lisp,ml} on FreeNode
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkofqY4ACgkQp/VmCx0OL2xOLQCgqkXnwaThpT2oOdpiliS7SHRa
pt8An3/S6O+LiXkzQBRPsw0zRUmxhNZp
=Ntpj
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: How not to discuss

[Patrick Lauer]

On Friday 29 May 2009 04:12:04 Ryan Hill wrote:
> On Thu, 28 May 2009 08:28:12 +0200
>
> Patrick Lauer <patrick@gentoo.org> wrote:
> > This is becoming a rather lengthy email ping pong, but as people seem to
> > be unable to discuss things I had to highlight a few issues there.
>
> I'm sorry to be rude,
Don't be, most other posters on this list have no guilt either ...

> but ever consider that the reason people keep
> repeating things to you is that you continually misunderstand what they're
> saying?
I'd say it is more the refusal of certain people to discuss at all.
The constant attempts to shove a rational discussion into emotional pockets 
makes it quite hard to get any information out of it, statements like:

> No, it's entirely objective. GLEP 55 clearly shows how the filename
> based options are objectively better than anything else.

are just wrong. It ignores one side of the conversation completely, not even 
accepting any potential value in their contribution. It's not a way to lead a 
technical discussion, and I'll do what I can to reduce such sophistry so we 
can _discuss_ things rationally.

If anyone needs help - there's a few experienced engineers on this list that 
can help you get your ideas into a form that can be presented, discussed and 
improved without having to repeatedly ask for clarification what the actual 
problem is. Don't be afraid to learn from them.

> I think that by now we've exhausted everything that can possibly be said
> about GLEP 55.  Nothing in this discussion is new, nor has it been for some
> time.  Can we please just stop now and trust the representatives that we've
> elected to make their decision?  Or should we go around the ring one more
> time?
Looking at how it went last time ... prepare for at least two further rounds 
of trying to convince people that their feelings are wrong. That, of course, 
is doomed to failure because our subjective reality cannot be falsified, but 
facts (and their darn liberal bias!) or logic are usually only accidentally 
involved.

Re: [gentoo-dev] How not to discuss

[Alec Warner]

On Thu, May 28, 2009 at 12:15 PM, Joe Peterson <lavajoe@gentoo.org> wrote:
> Alec Warner wrote:
>>> No, it's entirely objective. GLEP 55 clearly shows how the filename
>>> based options are objectively better than anything else.
>>
>> But the decision will not be based entirely on objective merits
>> (although I will concede that EAPI in filename is the 'best' technical
>> choice).
>
> (Jeez, I hate to add another to this thread, but this way of defining
> 'technical' bothers me)

Lets agree to disagree on the definition of "technical" then and
instead agree that putting EAPI in the filename is a bad design
decision ("technicalness" aside) and then have a beer!

>
> Along the lines of what Roy so eloquently expressed, I think it's
> important that we do not divorce *design* from *technical*.  The
> decision of where to place the EAPI is a design issue, and many of us
> here clearly believe that it is *not* good design to put this kind of
> metadata in the filename.  Therefore, the statement that it is the
> 'best' technical choice is not objectively true.
>
> Technical issues of performance and efficiency can be addressed when
> proper design has been done beforehand.  Part of the purpose of the
> implementation (after proper design is in place) is to address
> performance and other related issues.  And part of the design is how we
> define the *interface*.  The filename is clearly part of the interface.
>  It is part of how devs (and users) interact with portage when writing
> ebuilds.  Much of the argument for EAPI in the filename has been
> motivated by a perceived implementation benefit of speed, as if there
> were no other solutions (which is naive).  As Roy suggested, if all
> engineering decisions were based purely on pragmatic "ease of
> implementation" factors, we'd have a lot of ugly designs/interfaces out
> there.
>
> It may be easy (although incorrect) to dismiss elegance/design/interface
> issues as "non-technical", but I maintain they actually *are* technical
> matters of great importance.  I've been an engineer for over 20 years,
> and I have seen the pitfalls of taking the quick-and-dirty approach just
> to slap a new feature into a software app.  I've seen how such hasty
> design mistakes can cause great pain and regret for a long time after.
> Let's get the design right, first.  For what it's worth, GLEP 55 does
> now provide an option (#3: Easily fetchable EAPI inside the ebuild and
> one-time extension change) that demonstrates good design.
>
>                                                -Joe
>
>

Re: [gentoo-dev] How not to discuss

[Joe Peterson]

Alec Warner wrote:
> Lets agree to disagree on the definition of "technical" then and
> instead agree that putting EAPI in the filename is a bad design
> decision ("technicalness" aside) and then have a beer!

Wow.  That's a *great* idea!  ;)

		-Cheers, Joe

[gentoo-dev] Re: How not to discuss

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 2075 bytes --]

On Fri, 29 May 2009 23:49:26 +0200
Patrick Lauer <patrick@gentoo.org> wrote:

> On Friday 29 May 2009 04:12:04 Ryan Hill wrote:

> > Patrick Lauer <patrick@gentoo.org> wrote:

> > but ever consider that the reason people keep
> > repeating things to you is that you continually misunderstand what they're
> > saying?

> I'd say it is more the refusal of certain people to discuss at all.
> The constant attempts to shove a rational discussion into emotional pockets 
> makes it quite hard to get any information out of it, statements like:

> > No, it's entirely objective. GLEP 55 clearly shows how the filename
> > based options are objectively better than anything else.

> are just wrong. It ignores one side of the conversation completely, not even 
> accepting any potential value in their contribution. It's not a way to lead a 
> technical discussion, and I'll do what I can to reduce such sophistry so we 
> can _discuss_ things rationally.

Allow me to be blunt, since it's gone over your head again.  You have no idea
what you're talking about.  None of your "technical arguments" are
technical.  Your attempts to be the "better person" by offering up helpful
advice about how to have a technical discussion come off as egotistic and
naive, as there was a technical discussion happening long before you started
interjecting ridiculous hand-wavy assertions such as "overlays are
unsupported" and "cache is almost always up-to-date", and highly
hypocritical, as you manage to break most of the rules you lay out /later in
the very same post/.  You are being played with, Mr. Kitten, and statements
such as you quoted above are balls of yarn tossed your way to see how long it
takes you to pounce.  I'm tired of playing, as I'm sure you are.  So please,
let's be quiet now, and let the big people talk.


-- 
gcc-porting,                                      by design, by neglect
treecleaner,                              for a fact or just for effect
wxwidgets @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: How not to discuss

[Richard Freeman]

Ryan Hill wrote:
> I'm tired of playing, as I'm sure you are.  So please,
> let's be quiet now, and let the big people talk.
> 

This is a public list designed to facilitate discussion of gentoo 
software development.  Anybody with something constructive to say is 
more than welcome to speak up - particularly gentoo staff.

I don't pretend to be an expert on package management.  However, hiding 
internal implementation details is just good design.  I can see how 
putting eapi in the filename can be a convenience to the package 
manager, but it still seems like a bad design, as it exposes end users 
to an implementation detail of the package management system.

There are lots of ways that EAPI could be cached that would avoid the 
various penalties that have been referred to.  Even without an improved 
cache the penalty seems superior to accepting the design compromise of 
EAPI in the filename.

As to how EAPI could be cached goes - I could think of a few high-level 
design options:

1.  Cache files are distributed with the portage tree.  EAPIs that break 
the cache format would use different files that older package managers 
would ignore.  Downside is that it doesn't handle user-modified ebuilds 
(unless the user tells the package manager to regenerate the cache), and 
it doesn't handle overlays unless the maintainer generates the cache.

2. Cache files are generated when the tree is synced.  The package 
manager would look at the list of modified files and scan only those 
files one time to index them.  The index could contain the mtime and 
path of the file.  Then, when you perform an operation the package 
manager could check the mtimes in the directories containing those files 
and see if anything was touched and regenerate the cache if needed. 
This takes a little more time during syncing but I suspect that it would 
perform very well - after all after a sync all those files would be in 
the disk cache anyway.  A suitably clever package manager could read the 
files as they are being synced and guarantee they are in-memory.

If we were talking about a 300TB table that got 300k transactions per 
second I could see why we'd be talking about hacks to sacrifice 
normalized design for speed.  We're talking about a package database - 
one that contains < 150k records.  Sacrificing good design for speed 
(instead of improving the algorithm) is a short term gain for a 
long-term cost.

Re: [gentoo-dev] Re: How not to discuss

[Thilo Bangert]

[-- Attachment #1: Type: text/plain, Size: 1208 bytes --]

Richard Freeman <rich0@gentoo.org> said:
> Ryan Hill wrote:
> > I'm tired of playing, as I'm sure you are.  So please,
> > let's be quiet now, and let the big people talk.
>
> This is a public list designed to facilitate discussion of gentoo
> software development.  Anybody with something constructive to say is
> more than welcome to speak up - particularly gentoo staff.

the thing is though, nothing constructive is being said. people are going 
in circles. ciaran and co are pushing glep55 for reasons which they have 
stated gazillion of times and nothing new is coming about.

other people dislike glep55 for various reasons, but they clearly fail at 
proposing a (better) alternative (a competing GLEP).

while both parties claim thechnical superiority of their proposal, the 
difference is what amounts to the colour of a shed. the arguments used to 
support the respective superiority reflect that.

please, please DO write a competing GLEP if you dislike GLEP55. it's late, 
but you might just make it...

it is all too common in gentoo land to be against something. i want to see 
more people be in favor of (not necessarily the same) something.

kind regards
Thilo


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: How not to discuss

[Duncan]

Thilo Bangert <bangert@gentoo.org> posted
200905311126.00274.bangert@gentoo.org, excerpted below, on  Sun, 31 May
2009 11:25:56 +0200:

> the thing is though, nothing constructive is being said. people are
> going in circles. ciaran and co are pushing glep55 for reasons which
> they have stated gazillion of times and nothing new is coming about.
> 
> other people dislike glep55 for various reasons, but they clearly fail
> at proposing a (better) alternative (a competing GLEP).

> please, please DO write a competing GLEP if you dislike GLEP55. it's
> late, but you might just make it...

And this is why GLEP55 is likely ultimately going to be approved, despite 
all the arguing.  At the end of the day, we'll need /some/ solution to 
the general problem, and the proponents of GLEP55 have troubled 
themselves to write a GLEP outlining their solution in some depth as well 
as argue for it over a period of /years/, while the opponents have... 
troubled themselves enough to argue it for years.

A team can have the best rhetoric in the world, but if they don't 
actually show up and field a team on game day, they lose by default.  
Fortunately or unfortunately, that looks to be where this is headed.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: How not to discuss

[Richard Freeman]

Duncan wrote:
> A team can have the best rhetoric in the world, but if they don't 
> actually show up and field a team on game day, they lose by default.  
> Fortunately or unfortunately, that looks to be where this is headed.
> 

Agreed, there is definitely something to be said for offering solutions. 
  I think that parts of GLEP55 are an ugly hack, but since I'm not the 
one writing code the best I can do is ask those who are to think 
carefully about what they're about to do.  In the end, it is better for 
gentoo for something to happen rather than nothing.

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

[Tiziano Müller]

[-- Attachment #1: Type: text/plain, Size: 2786 bytes --]

Am Mittwoch, den 27.05.2009, 20:55 +0100 schrieb Roy Bamford:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 2009.05.27 13:46, Ferris McCormick wrote:
> > On Tue, 2009-05-26 at 20:57 +0200, Tiziano Müller wrote:
> > > This is your friendly reminder! Same bat time (typically the 2nd &
> > 4th
> > > Thursdays at 2000 UTC / 1600 EST), same bat channel (#gentoo-
> > council
> > @
> > > irc.freenode.net) !
> > > 
> > > If you have something you'd wish for us to chat about, maybe even
> > vote
> > > on, let us know! Simply reply to this e-mail for the whole Gentoo
> > dev
> > > list to see.
> > > 
> > > For more info on the Gentoo Council, feel free to browse our
> > homepage:
> > > http://www.gentoo.org/proj/en/council/
> > > 
> > > 
> > > Following is the preliminary meeting agenda. First we'll have to
> > fill
> > > the empty spot. After a short upgrade on EAPI-3 implementation we
> > will
> > > discuss the removal of old eclasses, followed by our old friend 
> > GLEP
> > 55.
> > > If we still have time we can dive into the topic of general EAPI
> > > development.
> > > 
> > 
> > Because Piotr recently amended GLEP55 to provide some further
> > clarification and justification as well as to present a few
> > alternatives
> > addressing some objections people have expressed, it seems to me that
> > the GLEP55 discussion should now go something like this:
> > 
> > 1.  Approve the concept in principle (I think Piotr's examples
> > sufficiently show the need for something along the lines set out in
> > the
> > revised GLEP);
> > 
> [snip]
> > > Cheers,
> > > Tiziano
> > Regards,
> > Ferris
> > -- 
> > Ferris McCormick (P44646, MI) <fmccor@gentoo.org>
> > Developer, Gentoo Linux (Sparc, Userrel, Trustees)
> > 
> GLEP 55 still confuses the problem and the solution.
> Adding metadata to the filename is not required and is bad system 
> design practice. Its also the first step on the slippery slope to 
> adding more metadata in the future.

Ok, while thinking even more about it I have to disagree.
I agree with you that users should be mostly unaware of EAPI as such.
But I don't see ebuilds or ebuild-names as kind of a user-visible
interface the average user has to handle (even though most if not all
Gentoo users will edit or even write an ebuild at least once). Instead
he should use the package manager which hides those implementation
details. As such I don't see a problem of exporting metadata information
into the ebuild-name.



-- 
Tiziano Müller
Gentoo Linux Developer, Council Member
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-zero@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: How not to discuss

[Steven J Long]

Duncan wrote:

> Thilo Bangert <bangert@gentoo.org> posted
> 200905311126.00274.bangert@gentoo.org, excerpted below, on  Sun, 31 May
> 2009 11:25:56 +0200:
> 
>> the thing is though, nothing constructive is being said. people are
>> going in circles. ciaran and co are pushing glep55 for reasons which
>> they have stated gazillion of times and nothing new is coming about.
>> 
>> other people dislike glep55 for various reasons, but they clearly fail
>> at proposing a (better) alternative (a competing GLEP).
> 
>> please, please DO write a competing GLEP if you dislike GLEP55. it's
>> late, but you might just make it...
> 
> And this is why GLEP55 is likely ultimately going to be approved, despite
> all the arguing.  At the end of the day, we'll need /some/ solution to
> the general problem

First we have to agree that there /is/ a problem. "Allowing -rc1 as opposed
to _rc1" is "the big one" apparently. No-one answered when I asked why an
internal format specification needs to allow this, or indeed more variants
on versions. (IME it's *better* to restrict it to one variant.)

Again, debian-style epochs (simply a numeric integer followed by : before
the usual ([0-9]+) at the start of a version) allow us this flexibility,
but as I explained before, this use-case doesn't merit it. 

They're used in Debian when upstream changes to a non-compatible (eg
overlapping) new version sequence. Whether that's needed in Gentoo, or
whether they could be used in a more interesting manner is another
discussion, which I for one would find a lot more interesting than debating
someone's unwillingness to take 'no' for an answer.

>, and the proponents of GLEP55 have troubled
> themselves to write a GLEP outlining their solution
To a non-existent problem.

> in some depth as well
> as argue for it over a period of /years/, while the opponents have...
> troubled themselves enough to argue it for years.
>
Well I'm actually a bit bemused that we are still discussing it. It's a
rank amateur solution to a non-issue, that I thought was dismissed by
consensus a year ago. A minority not accepting the majority viewpoint
doesn't change that that *is* what happened.

EAPI doesn't belong in filename the same way ACCEPT_KEYWORDS doesn't.

Or is that the next step, so that the mangler knows visibility from
filename and doesn't have to open the cache file? What next, DEPEND too?

Getting into a nonsensical debate about PN being metadata seems to be
the level of the argument, so forgive me for not being very impressed.
(It's externally derived and in fact the whole point of the product;
unless someone is proposing losing PN and PV from filename, can we
*please* dismiss that argument as the irrelevance which it is?)

> A team can have the best rhetoric in the world, but if they don't
> actually show up and field a team on game day, they lose by default.
> Fortunately or unfortunately, that looks to be where this is headed.
>
FEATURES=parse-eapi-ebuild-head shows one possible implementation.

Personally I favour restricting the EAPI='blah' line (which imo should
simply be single-quoted to avoid escaping issues, but whatever: it's easy
enough to lex in C, so I fail to see the issue lexing it anywhere else) to
before the inherit line _in_ _the_ _spec_ since no-one has given any reason
why we should want to do anything else, and afaik repoman will warn about
it anyhow.

Could *you* explain to us, why that restriction is such a bad thing?

In summary: the existing design, including harring's EAPI, suffices for all
the 'problems' raised. The most we need to do is specify that the mangler
is allowed to extract the EAPI without sourcing, the restrictions that
enable this, and that global-scope EAPI functions (including a later BASH
version) are consequently allowed.

In the meantime, while we've been discussing this for God knows how long, we
still don't have LDEPENDs, nor do we have elibs which harring envisaged
alongside eclasses and EAPI in the first place. "Broken process" afaic.

Oh btw, -scm [sic] suffix doesn't add ANYTHING to the existing cvs. prefix
that's been available in portage for at least 3 years; it's a binary datum,
either there or not. "Innovation" is not what I'd call all this.

-- 
#friendly-coders -- We're friendly but we're not /that/ friendly ;-)

[gentoo-dev] Re: How not to discuss

[Duncan]

Steven J Long <slong@rathaus.eclipse.co.uk> posted
1565621.WYyjxmS50y@news.friendly-coders.info, excerpted below, on  Tue, 02
Jun 2009 09:20:34 +0100:

> Personally I favour restricting the EAPI='blah' line (which imo should
> simply be single-quoted to avoid escaping issues, but whatever: it's
> easy enough to lex in C, so I fail to see the issue lexing it anywhere
> else) to before the inherit line _in_ _the_ _spec_ since no-one has
> given any reason why we should want to do anything else, and afaik
> repoman will warn about it anyhow.
> 
> Could *you* explain to us, why that restriction is such a bad thing?

Me?  I'm afraid you have *me* mistaken for someone else, or at least my 
position mistaken for that of someone else.

I actually happen to agree with your statement of opinion as quoted 
above, now put in my own words, that an in-ebuild EAPI='blah' line (or 
similar in-ebuild equivalent, shebangs, etc), suitably restricted in 
position and value, complete with single quotes to avoid escaped-char 
issues, is sufficient.  Either wait a suitable time or change the ebuild 
extension *ONCE* to ensure all actively supported PMs work with this 
before the first otherwise disruptive global change (as to say filename 
version information, but that's a separate issue), and run with it.

Plus the in-extension (or in-filename) solution has very similar 
restrictions. so it's not about the question of adding EAPI restrictions, 
that's a given either way.  We can just add them to the existing in-file 
solution and get on with the show, with the same ultimate extensibility 
benefits and very similar restrictions either way, so we might as /well/ 
just go with simple restrictions on the current solution, and be done 
with it.

If the pre-source parsing is slower than the eapi-in-extension (or in 
filename) solution, so be it.  It works technically, and the speed trade-
off for non-technical aesthetic sensibilities and semi-technical design 
is manageable and IMO a worthwhile tradeoff.  After all, Gentoo users and 
developers both obviously have other priorities than installation speed, 
or they'd be using a binary distribution and packages.

But, particularly if we're going the *single* extension change route 
anyway, it's a great opportunity to do any useful cache file format 
changes, like say, a single unified metadata file for all versions of a 
package, or all in a category, or adding tags or similar metadata so for 
instance kmail can show up in both the kde-base and mail client 
categories.  While doing that, the speed penalty of in-file EAPI can be 
mitigated or entirely eliminated as well, so it becomes a non-issue.  
However, cache structure changes would need debated and are an entirely 
different issue, while meanwhile, we can formalize the in-file EAPI 
restrictions now and get on with business, living with the slow-down 
temporarily if it comes to that.

So no, I'm NOT going to attempt to explain why the restriction is such a 
bad thing, as I don't believe it myself, and there's plenty of others to 
argue the point better than I could play devil's advocate.

The point I made, however, was entirely separate, that being that 
regardless of one's personal feelings on GLEP55 and the merits of its 
implementation, we're likely to be stuck with it, as nobody has bothered 
formulating a properly constructed alternative solution.

As for whether there's even a problem, the council did vote that in 
principle, they did see the problem, and I agree, there are global format 
restrictions in the current EAPI due to the /lack/ of specifics in the 
EAPI assignment rules that ARE a problem in terms of flexibility.  So 
while I don't particularly care about _ vs. - and -scm vs lack thereof, 
problems like allowable bash version features do crop up from time to 
time, and they'd be MUCH easier handled if the EAPI could handle them 
without worry about breakage, as it could if it were parseable before 
sourcing, and I thus see a problem that GLEP55 among other solutions, 
would solve.  Then we're back to my point, that GLEP55 being the only 
formalized proposed solution, it's likely to be the ultimately accepted 
one, regardless of the merits, because when it comes down to it, it's the 
suitably hashed out and formally defined choice out there.

> In summary: the existing design, including harring's EAPI, suffices for
> all the 'problems' raised. The most we need to do is specify that the
> mangler is allowed to extract the EAPI without sourcing, the
> restrictions that enable this, and that global-scope EAPI functions
> (including a later BASH version) are consequently allowed.

So you're saying the current solution, with a few minor changes, is 
enough, while I'm saying the current solution as-is, is not enough, and 
needs at least minor changes.

I think we're in violent agreement there! =:^)

I'm simply adding that whatever one's position on GLEP55 and its 
suitability, given that it's remains the only formally defined proposal 
after YEARS of debate, it's likely to be the one adopted, for lack of an 
alternative.  The opposition is demonstrating by its actions that it 
simply doesn't care enough about it to be motivated to provide a 
sufficiently defined alternative, since it hasn't done so.  If there's 
anyone out there who'd be sufficiently disappointed by that to actually 
care enough to do something about it, they should consider themselves 
lucky GLEP55 hasn't been adopted already, and they better get crackin', 
as every day that goes by without a suitably formalized alternative is a 
day closer to GLEP55 being adopted simply because it's the only 
alternative suitably well defined /to/ be adopted.

> In the meantime, while we've been discussing this for God knows how
> long, we still don't have LDEPENDs, nor do we have elibs which harring
> envisaged alongside eclasses and EAPI in the first place. "Broken
> process" afaic.

I'd tend to agree.

> Oh btw, -scm [sic] suffix doesn't add ANYTHING to the existing cvs.
> prefix that's been available in portage for at least 3 years; it's a
> binary datum, either there or not. "Innovation" is not what I'd call all
> this.

Indeed.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: How not to discuss

[Richard Freeman]

Steven J Long wrote:
> Getting into a nonsensical debate about PN being metadata seems to be
> the level of the argument, so forgive me for not being very impressed.
> (It's externally derived and in fact the whole point of the product;
> unless someone is proposing losing PN and PV from filename, can we
> *please* dismiss that argument as the irrelevance which it is?)
> 

Without actually intending to open a new debate on that issue <cringes>, 
  I'm actually a fan of NOT obtaining PN and PV from the filename.  I've 
seen an approach like this used in various systems and I happen to like it:

1.  First, I don't propose ebuild names should change at all.  By all 
means we should continue to leave PN and PV in the filename since the 
current naming convention makes sense.
2.  However, I do propose that the package manager should ignore PN/PV 
in the filename entirely.
3.  Instead, the package manager will obtain PN and PV from inside the 
ebuild (as ordinary shell variables).  I'd even break up PV into an 
upstream revision and an ebuild revision.

Once you make these changes I see these benefits:
a.  You get rid of all kinds of parsing issues - like restrictions on 
dashes in the various components.
b.  You can more flexibly allow for all kinds of crazy upstream 
versioning systems, since it isn't mashed together with the ebuild revision.
c.  If somebody comes up with a more clever way to name files we can use it.
d.  We can bend the rules on PN/PV/etc in the filename since it is just 
a user-visible representation of PN/PV and not the source of these values.

On the other hand, a bump will require more than a cp command.  There 
are also increased demands on caching (similar to all the glep55 
ebuild-in-file issues).

In any case, this isn't a serious proposal that needs a 47-reply debate. 
  Just an idea...

Re: [gentoo-dev] Re: How not to discuss

[Marijn Schouten (hkBst)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Richard Freeman wrote:
> Steven J Long wrote:
>> Getting into a nonsensical debate about PN being metadata seems to be
>> the level of the argument, so forgive me for not being very impressed.
>> (It's externally derived and in fact the whole point of the product;
>> unless someone is proposing losing PN and PV from filename, can we
>> *please* dismiss that argument as the irrelevance which it is?)
>>
> 
> Without actually intending to open a new debate on that issue <cringes>,
>  I'm actually a fan of NOT obtaining PN and PV from the filename.  I've
> seen an approach like this used in various systems and I happen to like it:

In which systems did you see this approach?

Marijn


- --
If you cannot read my mind, then listen to what I say.

Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
<http://www.gentoo.org/proj/en/lisp/>, #gentoo-{lisp,ml} on FreeNode
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkomU8YACgkQp/VmCx0OL2ym0QCfcbruFkqtUIBhdwhKIjaP9qol
Qi8An0TdECGv14pgMTmjdDhllvGylM7y
=1iV1
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: How not to discuss

[Richard Freeman]

Marijn Schouten (hkBst) wrote:
> Richard Freeman wrote:
>> Without actually intending to open a new debate on that issue <cringes>,
>>  I'm actually a fan of NOT obtaining PN and PV from the filename.  I've
>> seen an approach like this used in various systems and I happen to like it:
> 
> In which systems did you see this approach?
> 

A bunch of proprietary systems that nobody here would have heard of 
(well, most likely).  They had nothing to do with package management. 
The systems in question use a distinct field to display record names 
(which is user definable) and use separate fields to capture the content 
of the record.  In many cases the contents of some of these separate 
fields end up in the informal record name field, but it is still 
desirable that they be distinct.

Sorry if I implied that my example was directly related to gentoo or 
package management.  I was extrapolating from a completely different 
field.  However, I still think this is worth considering (entirely apart 
from glep55).  If I were building a portage system from scratch I'd 
consider doing it this way.  With all the history we have currently I'm 
not sure I'd be eager to make this change now (though I guess we 
actually could as part of a new EAPI).

[gentoo-dev] Re: How not to discuss

[Steven J Long]

Duncan wrote:
> Steven J Long posted:
> 
>> Personally I favour restricting the EAPI='blah' line (which imo should
>> simply be single-quoted to avoid escaping issues, but whatever: it's
>> easy enough to lex in C, so I fail to see the issue lexing it anywhere
>> else) to before the inherit line _in_ _the_ _spec_ since no-one has
>> given any reason why we should want to do anything else, and afaik
>> repoman will warn about it anyhow.
>> 
>> Could *you* explain to us, why that restriction is such a bad thing?
> 
> Me?  I'm afraid you have *me* mistaken for someone else, or at least my
> position mistaken for that of someone else.
> 
> I actually happen to agree with your statement of opinion as quoted
> above, now put in my own words, that an in-ebuild EAPI='blah' line (or
> similar in-ebuild equivalent, shebangs, etc), suitably restricted in
> position and value, complete with single quotes to avoid escaped-char
> issues, is sufficient.
*phew* ;)

btw repoman could easily correct this (given a valid EAPI somewhere in
the ebuild) and thus enforce it automatically while not causing the dev
any interruption in workflow (beyond a warning.)

>  Either wait a suitable time or change the ebuild
> extension *ONCE* to ensure all actively supported PMs work with this
> before the first otherwise disruptive global change (as to say filename
> version information, but that's a separate issue), and run with it.
>
The thing is we don't need to change anything beyond tightening up the
PMS. And that's been the issue: that changes to the spec are not accepted
from the list, or simply trolled on bugzilla. It's a one-way street
(hence the "broken process".)
 
> Plus the in-extension (or in-filename) solution has very similar
> restrictions. so it's not about the question of adding EAPI restrictions,
> that's a given either way.  We can just add them to the existing in-file
> solution and get on with the show, with the same ultimate extensibility
> benefits and very similar restrictions either way, so we might as /well/
> just go with simple restrictions on the current solution, and be done
> with it.
>
Agreed.
 
> But, particularly if we're going the *single* extension change route
> anyway, it's a great opportunity to do any useful cache file format
> changes, like say, a single unified metadata file for all versions of a
> package, or all in a category, or adding tags or similar metadata so for
> instance kmail can show up in both the kde-base and mail client
> categories.

I am not following why any of those require an extension change? Cache is
totally separate to ebuilds.

> The point I made, however, was entirely separate, that being that
> regardless of one's personal feelings on GLEP55 and the merits of its
> implementation, we're likely to be stuck with it, as nobody has bothered
> formulating a properly constructed alternative solution.
> 
> As for whether there's even a problem, the council did vote that in
> principle, they did see the problem, and I agree, there are global format
> restrictions in the current EAPI due to the /lack/ of specifics in the
> EAPI assignment rules that ARE a problem in terms of flexibility.

So again, change the spec to reflect the reality. Problem solved. Bear in
mind that the mangler doesn't even bother looking at the version if the
EAPI is not supported.

>> In summary: the existing design, including harring's EAPI, suffices for
>> all the 'problems' raised. The most we need to do is specify that the
>> mangler is allowed to extract the EAPI without sourcing, the
>> restrictions that enable this, and that global-scope EAPI functions
>> (including a later BASH version) are consequently allowed.
> 
> So you're saying the current solution, with a few minor changes, is
> enough, while I'm saying the current solution as-is, is not enough, and
> needs at least minor changes.
> 
> I think we're in violent agreement there! =:^)
>
Yes but those changes are minor and simply to do with PMS. There's nothing
portage needs to change, nor are there any implications for mangler
developers (it actually makes their life easier) and ebuild authors.
 
> I'm simply adding that whatever one's position on GLEP55 and its
> suitability, given that it's remains the only formally defined proposal
> after YEARS of debate, it's likely to be the one adopted, for lack of an
> alternative.  The opposition is demonstrating by its actions that it
> simply doesn't care enough about it to be motivated to provide a
> sufficiently defined alternative, since it hasn't done so.

That's because no change is required, beyond the simple tightening of the
spec. Since no GLEP is needed, why on Earth would we bother going through
the tortuous process of arguing for one with people who insult us with every
line and add nothing else? (in 90% of the replies I get. Yes, that's a made
up stat, it could well be more.. ;)

And believe me, we get worse on bugzilla.

In a nutshell: the GLEP was rejected by consensus last year; the problem was
only ever in the PMS, nowhere else. In such a circumstance, no GLEP is
required from the "other side."

[project]
I for one am sick of all the arguing and insults (and yes, I'm aware I tend
to give as good as I get;) it's why I went off posting to this list, and to
my knowledge it's why quite a few Gentoo devs have left over the past 3
years.

Collaboration in my free time does *not* tend to go on being insulted by
people who have no clue what they are on about, in my professional opinion,
and seem to be more interested in ruining the atmosphere that this list
started out with (I recommend reading that far back to anyone who never
has. "Manners maketh the man.")

The thing is: Gentoo collaboration /could/ be so much more fun, on the list
just as much as it already is on IRC.
[/project]
--
#friendly-coders -- We're friendly but we're not /that/ friendly ;-)