[gentoo-dev] The fallacies of GLEP55

[gentoo-dev] The fallacies of GLEP55

[Patrick Lauer]

For quite some time (over a year, actually) we've been discussing the
mysterious and often misunderstood GLEP55. 
[http://www.gentoo.org/proj/en/glep/glep-0055.html]

The proposed solution to a problem that is never refined, in short, is to add
the EAPI into the ebuild filename "to make things easier". Which is a rather
unsubstantiated idea that doesn't really add up if you look at it ... and it 
adds some artifacts that we've been laughing about for a decade because 
microsoft did the exact same thing (binding the executable-ness of a file to 
the filename).

Here's just some of the theories in support of GLEP55 that have been thrown at
me, and a few words to show how they are not really issues:

"You need to know the EAPI to parse the ebuild to find the EAPI"
Obviously that's not true, because somehow we manage at the moment.
And if one does a small restriction (which doesn't restrict current behaviour
because all in-tree ebuilds currently fit within this limitation) it becomes
trivial again:

Let EAPI be defined as (the part behind the = of) the first line of the ebuild
starting with EAPI=

As long as ebuilds remain shell-like this is not much of a restriction, and 
any format that diverges enough to make this inconvenient shouldn't be called 
an ebuild anyway. Finding the EAPI is then quite unsurprisingly trivial.

"You need to parse the ebuild and its eclasses to find the EAPI!"
See above, and eclasses shouldn't change EAPI anyway. It leads to lots of
strange effects and is implicitly impossible with GLEP55 anyway, so it might 
be easier to just declare it invalid. 

"It's slower!"
The theory here being that a stat() is needed if it is encoded in the 
filename, but a stat() followed by an open() to parse it from the file.
Well then, just cache it! You can use the mtime to check the cache validity 
(which means you do a stat() anyway, so with glep55 caching it is actually 
slower!), and then you have to parse the ebuild anyway for the other metadata. 
So the "extra" cost of finding the EAPI is ... what extra cost?
The only case when it is actually slower is when there is no cache because 
then you have to parse the ebuild. But that "degenerate" case will only hit 
some overlay users and people like developers that can wait .3 seconds longer. 
And ... uhm ... to extract other metadata like DEPENDS you'll have to parse it
anyway.

"But we need to be able to change things in the future!"
Well then. Once we have identified such an issue we can do the changes. Until
then it's not even clear if there are such changes, so why should we break
current known and predictable behaviour to satisfy a need we don't even have?
Make a structured proposal defining a concrete problem in unambiguous terms,
list all the ways to solve this issue, including advantages and disadvantages,
and we can get it voted on and ratified within a month.

"We want to change the versioning rules!"
Why do you want that, and what do we gain from it? 

"Having GLEP55 allows us to add GLEP54 without issues!"
Yeah, uhm, the live-ness of an ebuild is an attribute. How about we add it to
metadata, as we should for all metadata? Define a key, I don't know ... LIVE ? 
LIVE="true". There. No need to fix the filename. And now stop mixing up issues
because it is highly confusing!

"Obviously you don't understand the issue, because if you did you'd support 
it!"
Uhm, obviously you have no idea what you are saying. But  just to play along
... if it were that obvious we wouldn't have had to discuss it for so long.
Maybe understanding the issue forces one to support the current behaviour!


A few words in closing - 

We can encode all the relevant info in "the first line of the ebuild starting
with EAPI="
The overhead of parsing out this value for all ebuilds in the tree has been
timed at ~2 CPU-seconds by solar. It's negligible.
The changes are none at the moment, all that changes is the specification. And
if we ever have the need to change things around we can still look at the
expected costs and benefits and decide to implement something almost, but not
completely unlike GLEP55. And maybe we can now spend the same amount of
council-time (it has been eating time for over a year!) to get important 
things done ...

hth,

Patrick the bonsaikitten


P.S. http://dev.gentooexperimental.org/~dreeevil/whargarbl.jpg

Re: [gentoo-dev] The fallacies of GLEP55

[Ciaran McCreesh]

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

On Thu, 14 May 2009 20:06:51 +0200
Patrick Lauer <patrick@gentoo.org> wrote:
> "You need to know the EAPI to parse the ebuild to find the EAPI"
> Obviously that's not true, because somehow we manage at the moment.
> And if one does a small restriction (which doesn't restrict current
> behaviour because all in-tree ebuilds currently fit within this
> limitation) it becomes trivial again:
> 
> Let EAPI be defined as (the part behind the = of) the first line of
> the ebuild starting with EAPI=

Uh, so horribly utterly and obviously wrong.

    inherit foo
    EAPI=4

where foo is both a global and a non-global eclass that sets metadata.

If you're looking for a formally correct alternative that works in the
way you suggest, I already provided one, and you already read about it
-- and it still doesn't solve the problems that 55 does.

> "It's slower!"
> The theory here being that a stat() is needed if it is encoded in the 
> filename, but a stat() followed by an open() to parse it from the
> file. Well then, just cache it! You can use the mtime to check the
> cache validity (which means you do a stat() anyway, so with glep55
> caching it is actually slower!), and then you have to parse the
> ebuild anyway for the other metadata. So the "extra" cost of finding
> the EAPI is ... what extra cost? The only case when it is actually
> slower is when there is no cache because then you have to parse the
> ebuild. But that "degenerate" case will only hit some overlay users
> and people like developers that can wait .3 seconds longer. And ...
> uhm ... to extract other metadata like DEPENDS you'll have to parse
> it anyway.

Where on earth are you getting the idea that GLEP 55 makes things
slower? The only difference to the code with GLEP 55 is in checking
file extensions against a slightly larger set of strings, which is
nowhere near a measurable increase in anything. You're claiming that
checking for a suffix of either ".ebuild-4" or ".ebuild" against a
fixed string is in any way relevant, which is obviously trolling.

> "Having GLEP55 allows us to add GLEP54 without issues!"
> Yeah, uhm, the live-ness of an ebuild is an attribute. How about we
> add it to metadata, as we should for all metadata? Define a key, I
> don't know ... LIVE ? LIVE="true". There. No need to fix the
> filename. And now stop mixing up issues because it is highly
> confusing!

There is no existing version ordering solution that accurately
represents upstream scm branches.

> A few words in closing - 
> 
> We can encode all the relevant info in "the first line of the ebuild
> starting with EAPI="

No we can't. That's *obviously* completely wrong.

> The overhead of parsing out this value for all ebuilds in the tree
> has been timed at ~2 CPU-seconds by solar. It's negligible.

Those of us who have been measuring this have been discarding CPU time
entirely, since it's utterly irrelevant. That you bring CPU time into
this shows you've been deliberately ignoring everything we've said.

We all know you're not stupid enough to believe what you've been
posting or ignorant enough to miss the point so badly. So please stop
pretending -- this issue would have gone through a long time ago were
it not for you and your ilk deliberately pretending to be retarded so
you can raise straw man arguments against it rather than addressing the
issues at hand. You're doing both yourself and everyone else a huge
disfavour by acting dumb and assuming everyone else is going to play
along with that.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] The fallacies of GLEP55

[Patrick Lauer]

On Thursday 14 May 2009 20:39:07 Ciaran McCreesh wrote:
> On Thu, 14 May 2009 20:06:51 +0200
>
> Patrick Lauer <patrick@gentoo.org> wrote:
> > "You need to know the EAPI to parse the ebuild to find the EAPI"
> > Obviously that's not true, because somehow we manage at the moment.
> > And if one does a small restriction (which doesn't restrict current
> > behaviour because all in-tree ebuilds currently fit within this
> > limitation) it becomes trivial again:
> >
> > Let EAPI be defined as (the part behind the = of) the first line of
> > the ebuild starting with EAPI=
>
> Uh, so horribly utterly and obviously wrong.
>
>     inherit foo
>     EAPI=4
>
> where foo is both a global and a non-global eclass that sets metadata.
Interesting, but quite subtly wrong. I'm surprised that you try to slip such 
an obvious logical mistake in in an attempt to save your arguments.

> If you're looking for a formally correct alternative that works in the
> way you suggest, I already provided one, and you already read about it
> -- and it still doesn't solve the problems that 55 does.
And glep55 doesn't solve the problem either. It's neither formal nor correct, 
plus in this case ... what on earth are you trying to communicate?

> > "It's slower!"
> > The theory here being that a stat() is needed if it is encoded in the
> > filename, but a stat() followed by an open() to parse it from the
> > file. Well then, just cache it! You can use the mtime to check the
> > cache validity (which means you do a stat() anyway, so with glep55
> > caching it is actually slower!), and then you have to parse the
> > ebuild anyway for the other metadata. So the "extra" cost of finding
> > the EAPI is ... what extra cost? The only case when it is actually
> > slower is when there is no cache because then you have to parse the
> > ebuild. But that "degenerate" case will only hit some overlay users
> > and people like developers that can wait .3 seconds longer. And ...
> > uhm ... to extract other metadata like DEPENDS you'll have to parse
> > it anyway.
> Where on earth are you getting the idea that GLEP 55 makes things
> slower? The only difference to the code with GLEP 55 is in checking
> file extensions against a slightly larger set of strings, which is
> nowhere near a measurable increase in anything. You're claiming that
> checking for a suffix of either ".ebuild-4" or ".ebuild" against a
> fixed string is in any way relevant, which is obviously trolling.
That is quite definitely not my point. I mean, hombre, did you even READ my 
email, or do you just apply prewritten text blocks in the hope of solving 
issues like most "technical" "support" does? 

> There is no existing version ordering solution that accurately
> represents upstream scm branches.
Ah. Thanks. At last you say in clear words that GLEP54 doesn't actually solve 
the problem either. So we can safely keep it buried ...

> > A few words in closing -
> >
> > We can encode all the relevant info in "the first line of the ebuild
> > starting with EAPI="
>
> No we can't. That's *obviously* completely wrong.
>
It's obviously quite specifically not. Can you show any case where that fails 
or where adding this restriction removes relevant functionality?

> > The overhead of parsing out this value for all ebuilds in the tree
> > has been timed at ~2 CPU-seconds by solar. It's negligible.
>
> Those of us who have been measuring this have been discarding CPU time
> entirely, since it's utterly irrelevant. That you bring CPU time into
> this shows you've been deliberately ignoring everything we've said.
Eh, I already smashed the disk seek time argument somewhere up there. It 
amortizes quite nicely. And you are ignoring everything I say just to make a 
point that is not even wrong anymore. 

> We all know you're not stupid enough to believe what you've been
> posting or ignorant enough to miss the point so badly. So please stop
> pretending -- this issue would have gone through a long time ago were
> it not for you and your ilk deliberately pretending to be retarded so
> you can raise straw man arguments against it rather than addressing the
> issues at hand. You're doing both yourself and everyone else a huge
> disfavour by acting dumb and assuming everyone else is going to play
> along with that.
Hey. Wow. I'll keep that to post it whenever you try to insult, confuse or 
obfuscate issues to get your ideas pushed in. It describes you so wonderfully 
precise how only your own words can do.

Now, thanks for the logical fallacies (I think you've missed at least one, but 
I haven't been looking carefully) and the attempt at a personal attack. It's 
quite great, but this mailing list is definitely not the place for it. 

Now can we please get back to _debating_ things instead of wargharbling?

Thanks,

el meow

Re: [gentoo-dev] The fallacies of GLEP55

[Ciaran McCreesh]

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

On Thu, 14 May 2009 21:05:52 +0200
Patrick Lauer <patrick@gentoo.org> wrote:
> > Where on earth are you getting the idea that GLEP 55 makes things
> > slower? The only difference to the code with GLEP 55 is in checking
> > file extensions against a slightly larger set of strings, which is
> > nowhere near a measurable increase in anything. You're claiming that
> > checking for a suffix of either ".ebuild-4" or ".ebuild" against a
> > fixed string is in any way relevant, which is obviously trolling.
> That is quite definitely not my point. I mean, hombre, did you even
> READ my email, or do you just apply prewritten text blocks in the
> hope of solving issues like most "technical" "support" does? 

Please explain why you claimed GLEP 55 makes things slower. Until you
answer that, it's hard to take you for anything other than a troll.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] The fallacies of GLEP55

[RB]

On Thu, May 14, 2009 at 13:11, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> Please explain why you claimed GLEP 55 makes things slower. Until you
> answer that, it's hard to take you for anything other than a troll.

Hell, I'll explain.  Read paragraph 8 again.  Slowly.  Read it a
second time, since you obviously didn't read the first time.  The
paragraph makes the point that the pro-GLEP55 stance says that
encoding EAPI inside the file is slower.  It is not saying GLEP55 is
slower, it is attempting to debunk the theory that it is faster.

You may be a lightning-fast typer and emailer, but until your
comprehension catches up, you might want to consider reading things
that make you angry twice.

Re: [gentoo-dev] The fallacies of GLEP55

[Ciaran McCreesh]

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

On Thu, 14 May 2009 13:17:24 -0600
RB <aoz.syn@gmail.com> wrote:
> On Thu, May 14, 2009 at 13:11, Ciaran McCreesh
> <ciaran.mccreesh@googlemail.com> wrote:
> > Please explain why you claimed GLEP 55 makes things slower. Until
> > you answer that, it's hard to take you for anything other than a
> > troll.
> 
> Hell, I'll explain.  Read paragraph 8 again.  Slowly.  Read it a
> second time, since you obviously didn't read the first time.  The
> paragraph makes the point that the pro-GLEP55 stance says that
> encoding EAPI inside the file is slower.  It is not saying GLEP55 is
> slower, it is attempting to debunk the theory that it is faster.

"so with glep55 caching it is actually slower!"

There's no possible way that can make sense. Whatever he's claiming by
that is obviously nonsense.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] The fallacies of GLEP55

[Patrick Lauer]

On Thursday 14 May 2009 21:20:18 Ciaran McCreesh wrote:
> On Thu, 14 May 2009 13:17:24 -0600
>
> RB <aoz.syn@gmail.com> wrote:
> > On Thu, May 14, 2009 at 13:11, Ciaran McCreesh
> >
> > <ciaran.mccreesh@googlemail.com> wrote:
> > > Please explain why you claimed GLEP 55 makes things slower. Until
> > > you answer that, it's hard to take you for anything other than a
> > > troll.
> >
> > Hell, I'll explain.  Read paragraph 8 again.  Slowly.  Read it a
> > second time, since you obviously didn't read the first time.  The
> > paragraph makes the point that the pro-GLEP55 stance says that
> > encoding EAPI inside the file is slower.  It is not saying GLEP55 is
> > slower, it is attempting to debunk the theory that it is faster.
>
> "so with glep55 caching it is actually slower!"
>
> There's no possible way that can make sense. Whatever he's claiming by
> that is obviously nonsense.


Ah. I was not precise enough.

Let me rephrase it in less ambiguous terms then - 


"Having EAPI in the ebuild is slower than having it encoded in the filename"

Counterpoint: No, you use caching if it is that darn slow
Bonus: GLEP55 makes caching that slower than accessing it directly
Extra bonus: about a dozen emails going around in circles over a careless 
formulation that gets misinterpreted into "The iraqis have weapons of mass 
destruction!"

Re: [gentoo-dev] The fallacies of GLEP55

[Ciaran McCreesh]

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

On Thu, 14 May 2009 21:24:14 +0200
Patrick Lauer <patrick@gentoo.org> wrote:
> > "so with glep55 caching it is actually slower!"
> >
> > There's no possible way that can make sense. Whatever he's claiming
> > by that is obviously nonsense.
> 
> Ah. I was not precise enough.
> 
> Let me rephrase it in less ambiguous terms then - 
> 
> "Having EAPI in the ebuild is slower than having it encoded in the
> filename"
> 
> Counterpoint: No, you use caching if it is that darn slow

Cache it where? There's already a cache, and introducing any new cache
will only slow things down, not speed them up.

And you still haven't justified how glep 55 makes it slower.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] The fallacies of GLEP55

[Robert Bridge]

Patrick Lauer wrote:
> On Thursday 14 May 2009 20:39:07 Ciaran McCreesh wrote:
>> On Thu, 14 May 2009 20:06:51 +0200
>>
>> Patrick Lauer <patrick@gentoo.org> wrote:
>>> Let EAPI be defined as (the part behind the = of) the first line of
>>> the ebuild starting with EAPI=
>> Uh, so horribly utterly and obviously wrong.
>>
>>     inherit foo
>>     EAPI=4
>>
>> where foo is both a global and a non-global eclass that sets metadata.
>
> Interesting, but quite subtly wrong. I'm surprised that you try to slip such 
> an obvious logical mistake in in an attempt to save your arguments.

Patrick, in the interest of making this comprehensible to the average 
schmuck like me, which you seem to be trying to do, could you actually 
explain WHY this is wrong? Otherwise it looks like you are simply trying 
the arrogant "I am right because I say so" line.

>> If you're looking for a formally correct alternative that works in the
>> way you suggest, I already provided one, and you already read about it
>> -- and it still doesn't solve the problems that 55 does.
>
> And glep55 doesn't solve the problem either. It's neither formal nor correct, 
> plus in this case ... what on earth are you trying to communicate?

Again, see my previous comment.

>>> We can encode all the relevant info in "the first line of the ebuild
>>> starting with EAPI="
>> No we can't. That's *obviously* completely wrong.
>>
> It's obviously quite specifically not. Can you show any case where that fails 
> or where adding this restriction removes relevant functionality?

Both of you need to explain your opinions here.


Just my thoughts,
R.

[gentoo-dev] Re: The fallacies of GLEP55

[Steven J Long]

Robert Bridge wrote:

> Patrick Lauer wrote:
>> On Thursday 14 May 2009 20:39:07 Ciaran McCreesh wrote:
>>> On Thu, 14 May 2009 20:06:51 +0200
>>>
>>> Patrick Lauer <patrick@gentoo.org> wrote:
>>>> Let EAPI be defined as (the part behind the = of) the first line of
>>>> the ebuild starting with EAPI=
>>> Uh, so horribly utterly and obviously wrong.
>>>
>>>     inherit foo
>>>     EAPI=4
>>>
>>> where foo is both a global and a non-global eclass that sets metadata.
>>
>> Interesting, but quite subtly wrong. I'm surprised that you try to slip
>> such an obvious logical mistake in in an attempt to save your arguments.
> 
> Patrick, in the interest of making this comprehensible to the average
> schmuck like me, which you seem to be trying to do, could you actually
> explain WHY this is wrong? Otherwise it looks like you are simply trying
> the arrogant "I am right because I say so" line.
>
AFAIK, setting EAPI has to be done before any call to inherit. Not to do
so is considered a QA violation, and I believe repoman will scream at you
if you do so (I could be wrong as I don't use it. If it doesn't, perhaps it
should.)

Furthermore, eclasses are not supposed to set EAPI. They can test what the
ebuild's EAPI is, and act accordingly, should the need arise, but they are
not supposed to set it. (I'm informed this is disallowed by GLEP-55 in any
event, so it's not a restriction anyone cares too much about, one would
surmise.)

From conversation with Harring, who invented the whole EAPI thing, they were
never meant to change very quickly. The complementary mechanism was elibs,
that is files with useful library functions, which is often how eclasses
are used nowadays. Eclasses in that context would be able to set EAPI,
since they would effectively be a template, not a repository of
functionality.

(This is my no doubt flawed understanding of what he said; I'm sure he'll
correct, and hopefully forgive, any errors which are of course my own.)

I am curious as to why eclass versioning, which has been proposed for
donkey's years, hasn't seen as much impetus as what appear from a software
engineering perspective to be quite esoteric, and poorly thought-through,
use-cases. There does appear to be a process issue, though resolution is
another matter.

Good luck with the distro. :-)

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

Re: [gentoo-dev] The fallacies of GLEP55

[Tomáš Chvátal]

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

Dne čtvrtek 14 Květen 2009 20:39:07 Ciaran McCreesh napsal(a):
> Where on earth are you getting the idea that GLEP 55 makes things
> slower? The only difference to the code with GLEP 55 is in checking
> file extensions against a slightly larger set of strings, which is
> nowhere near a measurable increase in anything. You're claiming that
> checking for a suffix of either ".ebuild-4" or ".ebuild" against a
> fixed string is in any way relevant, which is obviously trolling.
Read the block once more, he is not stating that adding suffix to the filename 
is slower.
>
> > "Having GLEP55 allows us to add GLEP54 without issues!"
> > Yeah, uhm, the live-ness of an ebuild is an attribute. How about we
> > add it to metadata, as we should for all metadata? Define a key, I
> > don't know ... LIVE ? LIVE="true". There. No need to fix the
> > filename. And now stop mixing up issues because it is highly
> > confusing!
>
> There is no existing version ordering solution that accurately
> represents upstream scm branches.
>
> > A few words in closing -
> >
> > We can encode all the relevant info in "the first line of the ebuild
> > starting with EAPI="
>
> No we can't. That's *obviously* completely wrong.
We actualy can, you consider it wrong, so we all should do so
>
> > The overhead of parsing out this value for all ebuilds in the tree
> > has been timed at ~2 CPU-seconds by solar. It's negligible.
>
> Those of us who have been measuring this have been discarding CPU time
> entirely, since it's utterly irrelevant. That you bring CPU time into
> this shows you've been deliberately ignoring everything we've said.
Well cpu is not real benchmark, but if it took 2 secs it means the tweaking is 
not worth efforts.
>
> We all know you're not stupid enough to believe what you've been
> posting or ignorant enough to miss the point so badly. So please stop
> pretending -- this issue would have gone through a long time ago were
> it not for you and your ilk deliberately pretending to be retarded so
> you can raise straw man arguments against it rather than addressing the
> issues at hand. You're doing both yourself and everyone else a huge
> disfavour by acting dumb and assuming everyone else is going to play
> along with that.
And this is really just personal offense which you should take out from your 
mails if you want somebody to take your experience acordingly to your 
knowledge and not just judge you as 10 year old whining kid.

Tomas

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

Re: [gentoo-dev] The fallacies of GLEP55

[Ciaran McCreesh]

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

On Thu, 14 May 2009 21:09:58 +0200
Tomáš Chvátal <scarabeus@gentoo.org> wrote:
> Dne čtvrtek 14 Květen 2009 20:39:07 Ciaran McCreesh napsal(a):
> > Where on earth are you getting the idea that GLEP 55 makes things
> > slower? The only difference to the code with GLEP 55 is in checking
> > file extensions against a slightly larger set of strings, which is
> > nowhere near a measurable increase in anything. You're claiming that
> > checking for a suffix of either ".ebuild-4" or ".ebuild" against a
> > fixed string is in any way relevant, which is obviously trolling.
> Read the block once more, he is not stating that adding suffix to the
> filename is slower.

He is stating that GLEP 55 makes things slower. I quote:

"so with glep55 caching it is actually slower!"

The only possible change to GLEP 55 performance-wise is in the file
name recognition, and that's so obviously not an issue that there's no
way anyone can take it seriously.

Unless you seriously think he's claiming that GLEP 55 does away with the
need for storing EAPI in metadata cache, which is even more obviously
nonsense...

Either way, he's trolling and needs to be called on it.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] The fallacies of GLEP55

[George Prowse]

Ciaran McCreesh wrote:
> On Thu, 14 May 2009 20:06:51 +0200
> Patrick Lauer <patrick@gentoo.org> wrote:
>> "You need to know the EAPI to parse the ebuild to find the EAPI"
>> Obviously that's not true, because somehow we manage at the moment.
>> And if one does a small restriction (which doesn't restrict current
>> behaviour because all in-tree ebuilds currently fit within this
>> limitation) it becomes trivial again:
>>
>> Let EAPI be defined as (the part behind the = of) the first line of
>> the ebuild starting with EAPI=
> 
> Uh, so horribly utterly and obviously wrong.
> 
>     inherit foo
>     EAPI=4
> 
> where foo is both a global and a non-global eclass that sets metadata.
> 
> If you're looking for a formally correct alternative that works in the
> way you suggest, I already provided one, and you already read about it
> -- and it still doesn't solve the problems that 55 does.
> 
>> "It's slower!"
>> The theory here being that a stat() is needed if it is encoded in the 
>> filename, but a stat() followed by an open() to parse it from the
>> file. Well then, just cache it! You can use the mtime to check the
>> cache validity (which means you do a stat() anyway, so with glep55
>> caching it is actually slower!), and then you have to parse the
>> ebuild anyway for the other metadata. So the "extra" cost of finding
>> the EAPI is ... what extra cost? The only case when it is actually
>> slower is when there is no cache because then you have to parse the
>> ebuild. But that "degenerate" case will only hit some overlay users
>> and people like developers that can wait .3 seconds longer. And ...
>> uhm ... to extract other metadata like DEPENDS you'll have to parse
>> it anyway.
> 
> Where on earth are you getting the idea that GLEP 55 makes things
> slower? The only difference to the code with GLEP 55 is in checking
> file extensions against a slightly larger set of strings, which is
> nowhere near a measurable increase in anything. You're claiming that
> checking for a suffix of either ".ebuild-4" or ".ebuild" against a
> fixed string is in any way relevant, which is obviously trolling.
> 
>> "Having GLEP55 allows us to add GLEP54 without issues!"
>> Yeah, uhm, the live-ness of an ebuild is an attribute. How about we
>> add it to metadata, as we should for all metadata? Define a key, I
>> don't know ... LIVE ? LIVE="true". There. No need to fix the
>> filename. And now stop mixing up issues because it is highly
>> confusing!
> 
> There is no existing version ordering solution that accurately
> represents upstream scm branches.
> 
>> A few words in closing - 
>>
>> We can encode all the relevant info in "the first line of the ebuild
>> starting with EAPI="
> 
> No we can't. That's *obviously* completely wrong.
> 
>> The overhead of parsing out this value for all ebuilds in the tree
>> has been timed at ~2 CPU-seconds by solar. It's negligible.
> 
> Those of us who have been measuring this have been discarding CPU time
> entirely, since it's utterly irrelevant. That you bring CPU time into
> this shows you've been deliberately ignoring everything we've said.
> 
> We all know you're not stupid enough to believe what you've been
> posting or ignorant enough to miss the point so badly. So please stop
> pretending -- this issue would have gone through a long time ago were
> it not for you and your ilk deliberately pretending to be retarded so
> you can raise straw man arguments against it rather than addressing the
> issues at hand. You're doing both yourself and everyone else a huge
> disfavour by acting dumb and assuming everyone else is going to play
> along with that.
> 
Having countered those four points I guess you agree with the other five 
then. Over 50% success rate (by your definition) is hardly being 
ignorant or trolling

Re: [gentoo-dev] The fallacies of GLEP55

[David Leverton]

On Friday 15 May 2009 02:42:33 George Prowse wrote:
> Having countered those four points I guess you agree with the other five
> then. Over 50% success rate (by your definition) is hardly being
> ignorant or trolling

In that case we can assume that Patrick agrees with all my counterpoints, 
since he hasn't responded to my email at all.

Re: [gentoo-dev] The fallacies of GLEP55

[Richard Freeman]

Ciaran McCreesh wrote:
> On Thu, 14 May 2009 20:06:51 +0200
> Patrick Lauer <patrick@gentoo.org> wrote:
>> Let EAPI be defined as (the part behind the = of) the first line of
>> the ebuild starting with EAPI=
> 
> Uh, so horribly utterly and obviously wrong.
> 
>     inherit foo
>     EAPI=4
> 
> where foo is both a global and a non-global eclass that sets metadata.
> 

This seems to come up from time to time but I don't see how this is a 
problem that GLEP 55 solves.  If the rule is "first line of the ebuild 
starting with EAPI=" and the ebuild is as you suggest above, then the 
EAPI is 4 (without any regard whatsoever to what might be in "foo").

The counterargument seems to be that eclasses should be able to modify 
EAPI behavior.  However, if you want to do this then you DEFINITELY 
don't want to put the EAPI in the filename - unless you want eclasses to 
start renaming the ebuilds to change their EAPIs and then trigger a 
metadata regen.

This seems to be a case where a problem is proposed, with a solution. 
Somebody proposes an alternate solution and the complaint is raised that 
it doesn't handle situation X.  However, the original proposed solution 
doesn't handle situation X either, so that can hardly be grounds for 
accepting it over the alternate.

I'm actually more in favor of an approach like putting the EAPI in a 
comment line or some other place that is more "out-of-band".  Almost all 
modern file formats incorporate a version number into a fixed position 
in the file header so that it is trivial for a program to figure out 
whether or not it knows how to handle the file.  Another common approach 
is to put a header-length field and add extensions to the end of a 
header, so that as long as you don't break past behavior you could 
create a file that is readable by older program versions (perhaps with 
the loss of some metadata that the older version doesn't understand). 
Just look up the UStar tar file format or the gzip file format for 
examples.   Of course, such file formats generally aren't designed to be 
human-readable or created with a text editor.

The same applies to executables.  It is impossible from the filename to 
tell if /bin/bash is in a.out or ELF format, or if it is a shell script. 
  Instead a simple standard is defined that allows the OS to figure it 
out and handle it appropriately.  If you try to run an ELF on some 
ancient version of linux it doesn't crash or perform erratic behavior - 
it will simply tell you that it doesn't understand the file format 
(invalid magic number).

In any case, I'm going to try to restrain myself from replying further 
in this thread unless something genuinely new comes up.  When I see 26 
new messages in my gentoo-dev folder I should know by now that somebody 
has managed to bring up GLEP 55 again...  :)

Re: [gentoo-dev] The fallacies of GLEP55

[Robert R. Russell]

On Friday 15 May 2009 05:44:47 Richard Freeman wrote:
> Ciaran McCreesh wrote:
> > On Thu, 14 May 2009 20:06:51 +0200
> >
> > Patrick Lauer <patrick@gentoo.org> wrote:
> >> Let EAPI be defined as (the part behind the = of) the first line of
> >> the ebuild starting with EAPI=
> >
> > Uh, so horribly utterly and obviously wrong.
> >
> >     inherit foo
> >     EAPI=4
> >
> > where foo is both a global and a non-global eclass that sets metadata.
>
> This seems to come up from time to time but I don't see how this is a
> problem that GLEP 55 solves.  If the rule is "first line of the ebuild
> starting with EAPI=" and the ebuild is as you suggest above, then the
> EAPI is 4 (without any regard whatsoever to what might be in "foo").
>
> The counterargument seems to be that eclasses should be able to modify
> EAPI behavior.  However, if you want to do this then you DEFINITELY
> don't want to put the EAPI in the filename - unless you want eclasses to
> start renaming the ebuilds to change their EAPIs and then trigger a
> metadata regen.
>
> This seems to be a case where a problem is proposed, with a solution.
> Somebody proposes an alternate solution and the complaint is raised that
> it doesn't handle situation X.  However, the original proposed solution
> doesn't handle situation X either, so that can hardly be grounds for
> accepting it over the alternate.
>
> I'm actually more in favor of an approach like putting the EAPI in a
> comment line or some other place that is more "out-of-band".  Almost all
> modern file formats incorporate a version number into a fixed position
> in the file header so that it is trivial for a program to figure out
> whether or not it knows how to handle the file.  Another common approach
> is to put a header-length field and add extensions to the end of a
> header, so that as long as you don't break past behavior you could
> create a file that is readable by older program versions (perhaps with
> the loss of some metadata that the older version doesn't understand).
> Just look up the UStar tar file format or the gzip file format for
> examples.   Of course, such file formats generally aren't designed to be
> human-readable or created with a text editor.
>
> The same applies to executables.  It is impossible from the filename to
> tell if /bin/bash is in a.out or ELF format, or if it is a shell script.
>   Instead a simple standard is defined that allows the OS to figure it
> out and handle it appropriately.  If you try to run an ELF on some
> ancient version of linux it doesn't crash or perform erratic behavior -
> it will simply tell you that it doesn't understand the file format
> (invalid magic number).
>
> In any case, I'm going to try to restrain myself from replying further
> in this thread unless something genuinely new comes up.  When I see 26
> new messages in my gentoo-dev folder I should know by now that somebody
> has managed to bring up GLEP 55 again...  :)

If I understand the problem GLEP 55 is trying to solve correctly, it stems 
from portage's assumption that an unknown EAPI is equal to EAPI 0. Could that 
assumption be changed to an unknown EAPI is equal to the latest supported 
EAPI. Now I understand that this change would have to wait until all the 
ebuilds in the portage tree correctly define their EAPI, but would the idea be 
technically feasible at least excluding EAPI0 ebuilds? I think it would be if 
all EAPIs are forward compatible up until the EAPI declaration in the ebuild.

Re: [gentoo-dev] The fallacies of GLEP55

[Ciaran McCreesh]

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

On Fri, 15 May 2009 11:16:11 -0500
"Robert R. Russell" <nahoy_kbiki@hushmail.com> wrote:
> If I understand the problem GLEP 55 is trying to solve correctly, it
> stems from portage's assumption that an unknown EAPI is equal to EAPI
> 0. Could that assumption be changed to an unknown EAPI is equal to
> the latest supported EAPI. Now I understand that this change would
> have to wait until all the ebuilds in the portage tree correctly
> define their EAPI, but would the idea be technically feasible at
> least excluding EAPI0 ebuilds? I think it would be if all EAPIs are
> forward compatible up until the EAPI declaration in the ebuild.

No, that still wouldn't help, because the package manager doesn't know
that what it thinks is the 'latest' EAPI (not that there really is such
a thing -- EAPIs aren't a linear sequence) actually is the 'latest'
EAPI.

-- 
Ciaran McCreesh

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

[gentoo-dev] Re: The fallacies of GLEP55

[Steven J Long]

Robert R. Russell wrote:

<snip>
> If I understand the problem GLEP 55 is trying to solve correctly, it stems
> from portage's assumption that an unknown EAPI is equal to EAPI 0.

No, portage will reject an ebuild with an unknown EAPI, as per the spec.
(This is important for shared overlays.) Search for:
def eapi_is_supported
..in pym/portage/__init__.py for the impl,  and you can see usage of it in
pym/_emerge/__init__.py, if you want to confirm this (or are just
interested in the code;)

http://sources.gentoo.org/viewcvs.py/portage/main/trunk/
(has instructions for anonymous download, should anyone be interested in
following portage development, or perhaps contributing at some stage.)

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

Re: [gentoo-dev] Re: The fallacies of GLEP55

[Ciaran McCreesh]

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

On Fri, 15 May 2009 20:12:03 +0100
Steven J Long <slong@rathaus.eclipse.co.uk> wrote:
> Robert R. Russell wrote:
> <snip>
> > If I understand the problem GLEP 55 is trying to solve correctly,
> > it stems from portage's assumption that an unknown EAPI is equal to
> > EAPI 0.
> 
> No, portage will reject an ebuild with an unknown EAPI, as per the
> spec.

You're confusing the term 'unknown' here.

Before an ebuild has had its metadata generated, its EAPI is unknown. At
this point, the package manager assumes EAPI 0.

After an ebuild has had its metadata generated, its EAPI is either
known or unsupported, but if known may be unspecified. If it is known
but unspecified, the package manager treats it as equivalent to EAPI 0.

Conceptually, these aren't the same thing.

-- 
Ciaran McCreesh

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

[gentoo-dev] Re: Re: The fallacies of GLEP55

[Steven J Long]

Ciaran McCreesh wrote:
> Steven J Long wrote:
>> Robert R. Russell wrote:
>> <snip>
>> > If I understand the problem GLEP 55 is trying to solve correctly,
>> > it stems from portage's assumption that an unknown EAPI is equal to
>> > EAPI 0.
>> 
>> No, portage will reject an ebuild with an unknown EAPI, as per the
>> spec.
> 
> You're confusing the term 'unknown' here.
> 
> Before an ebuild has had its metadata generated, its EAPI is unknown. At
> this point, the package manager assumes EAPI 0.
>
With the format restriction, that everyone last year seemed happy with,
apart from the few pushing GLEP-55, this isn't an issue. The mangler
*should* be scanning first for the EAPI to see if it can even handle
the rest of the ebuild (assuming it's not from the main tree or an
upstream overlay, or we're not a normal user. Developer machines rightly
need to do a bit more work, but it's not exactly onerous since portage
automatically does it for you.)

> After an ebuild has had its metadata generated, its EAPI is either
> known or unsupported, but if known may be unspecified. If it is known
> but unspecified, the package manager treats it as equivalent to EAPI 0.
>
Yes, empty = 0 as well-understood.

> Conceptually, these aren't the same thing.
>
In practical terms, this is a useless proposal. It rightly got trashed
last year. Let's just use a prefix instead of a suffix to indicate vcs,
keep branch and upstream for dep specification, not filename, to allow
inter-repo dependency for overlays for the few cases where it's actually
needed, and add debian-style epochs to guarantee future expansion.

If you have a use-case that actually requires more in a version specifier
for upstream software, please present it and explain how it cannot be
represented with the above.

In passing, I must express bewildered amusement at the idea of a format
with an unlimited amount of extensions. If you really want something so
radically different that it cannot be handled in the Gentoo scheme, or
BASH, use ONE _other_ extension.

Have a good weekend, all.

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

Re: [gentoo-dev] Re: Re: The fallacies of GLEP55

[Ciaran McCreesh]

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

On Fri, 15 May 2009 21:06:13 +0100
Steven J Long <slong@rathaus.eclipse.co.uk> wrote:
> > Before an ebuild has had its metadata generated, its EAPI is
> > unknown. At this point, the package manager assumes EAPI 0.
> >
> With the format restriction, that everyone last year seemed happy
> with, apart from the few pushing GLEP-55, this isn't an issue.

The format restriction hasn't been agreed upon, and doesn't solve the
whole problem anyway.

> If you have a use-case that actually requires more in a version
> specifier for upstream software, please present it and explain how it
> cannot be represented with the above.

Go and look at all the ebuilds using MY_PV style hacks. Group these
into "necessary because upstream are being silly" and "we're only doing
this because of some utterly arbitrary rules imposed in the early days
of Gentoo". Most are in the second camp.

> In passing, I must express bewildered amusement at the idea of a
> format with an unlimited amount of extensions.

Not what's being proposed. We're proposing giving each format its own
file extension.

-- 
Ciaran McCreesh

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

[gentoo-dev] Re: Re: Re: The fallacies of GLEP55

[Steven J Long]

Ciaran McCreesh wrote:

> On Fri, 15 May 2009 21:06:13 +0100
> Steven J Long wrote:
>> > Before an ebuild has had its metadata generated, its EAPI is
>> > unknown. At this point, the package manager assumes EAPI 0.
>> >
>> With the format restriction, that everyone last year seemed happy
>> with, apart from the few pushing GLEP-55, this isn't an issue.
> 
> The format restriction hasn't been agreed upon,
By you. (oh, and your gang.) You're right though, it hasn't been spammed to
the list on more occasions than anyone cares to remember, nor has it been
pushed up to the Council to vote on, when someone can't convince the rest
of the developer community. It just works.

> and doesn't solve the whole problem anyway.

Only we're not allowed to hear what problem you _think_ exists. You just
resort to the Emperor's New Clothes defence. ("I can't explain it, as the
fact you don't agree with me, clearly means you're far too stupid to
explain it to.")

Sorry but those clothes look like rags to me.

Shiny you say? Explain it then, as they /still/ look like rags.

Or stop wasting everybody's time. Pick one.

>> If you have a use-case that actually requires more in a version
>> specifier for upstream software, please present it and explain how it
>> cannot be represented with the above.
> 
> Go and look at all the ebuilds using MY_PV style hacks. Group these
> into "necessary because upstream are being silly" and "we're only doing
> this because of some utterly arbitrary rules imposed in the early days
> of Gentoo". Most are in the second camp.
>
Please elucidate the use-case, and how the versions cannot be represented
within Gentoo, or within the expanded def'n[2] as you were asked to do.

If you're concerned about stupid BASH, perhaps you could direct your energy
towards better BASH scripting, and not relying on an eclass to do what #bash
beginners learn in their first two weeks. Learning the craft is part of the
process. I realise openly sharing knowledge makes it harder for you to
hoard it. Deal with it, or don't work in Free software.

As for "utterly arbitrary" some of the syntax you've proposed is exactly
that. Even worse, it's completely cack-handed. That'd be fine if you didn't
also insist that everything you dream up is perfectly worked-out and
thought-through from the beginning[1]. The combination is quite dangerous,
and were this a professional situation you'd have been out on your ear a
long time ago. Not storming back after being 'fired' and emailing the whole
company with your rants for the next 3 years.

>> In passing, I must express bewildered amusement at the idea of a
>> format with an unlimited amount of extensions.
> 
> Not what's being proposed. We're proposing giving each format its own
> file extension.
>
No, you're trying to hijack .ebuild. Even cat-foo/blah-version--EAPI.ebuild
would be better than this nonsense.

It'd *still* be a bad idea for all the reasons lavajoe (iirc) outlined way
back when. I suggest you re-read his post from a long time ago.

If you want to do a radically new format, go ahead; no-one's stopping you or
holding your work back in any way. The same cannot be said for your
continued antics.

Oh yeah, .exheres hasn't quite got the same cachet as .ebuild. No
satisfaction in it, unlike getting Gentoo to 'submit'.

I still haven't seen a version that cannot be handled within the Gentoo
schema (and I note you were remarkably silent on suggestions that were put
to you[2], as you always are if they didn't come from paludis.) If you're
arguing no human input should be required, I think you have a
misunderstanding of the user-base.

Some of us prefer to know that a human has both tried the ebuild out, and
gone through repoman. And that that person takes pride in their name on the
commit, and stands by the principle of "you broke it, you fix it."

It's called a distribution, not "ciara's collection of stuff scraped from a
webservice."

[1] 'If it is unwise to trust other people's claims for "one true way", it's
even more foolish to believe them about your own designs.'
http://www.catb.org/~esr/writings/taoup/html/ch01s06.html#id2879078
[You seem not to have read this site _at all_. Correct that before posting
again.]

[2] "Let's just use a prefix instead of a suffix to indicate vcs, keep
branch and upstream for dep specification, not filename, to allow
inter-repo dependency for overlays for the few cases where it's actually
needed, and add debian-style epochs to guarantee future expansion."

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

Re: [gentoo-dev] Re: Re: Re: The fallacies of GLEP55

[Ciaran McCreesh]

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

On Sun, 24 May 2009 21:53:34 +0100
Steven J Long <slong@rathaus.eclipse.co.uk> wrote:
> > The format restriction hasn't been agreed upon,
>
> By you. (oh, and your gang.) You're right though, it hasn't been
> spammed to the list on more occasions than anyone cares to remember,
> nor has it been pushed up to the Council to vote on, when someone
> can't convince the rest of the developer community. It just works.

You are more than welcome to write up your alternative into a formal
proposal if you desire.

> > and doesn't solve the whole problem anyway.
> 
> Only we're not allowed to hear what problem you _think_ exists.

... The ones mentioned in GLEP 55. Which you should read.

> > Go and look at all the ebuilds using MY_PV style hacks. Group these
> > into "necessary because upstream are being silly" and "we're only
> > doing this because of some utterly arbitrary rules imposed in the
> > early days of Gentoo". Most are in the second camp.
> >
> Please elucidate the use-case, and how the versions cannot be
> represented within Gentoo, or within the expanded def'n[2] as you
> were asked to do.

Examples are given in GLEP 55. Which you should read.

> If you're concerned about stupid BASH, perhaps you could direct your
> energy towards better BASH scripting, and not relying on an eclass to
> do what #bash beginners learn in their first two weeks.

Had you looked at the tree before versionator came along, you would
know why versionator was by far the lesser of two evils...

> >> In passing, I must express bewildered amusement at the idea of a
> >> format with an unlimited amount of extensions.
> > 
> > Not what's being proposed. We're proposing giving each format its
> > own file extension.
> >
> No, you're trying to hijack .ebuild. Even
> cat-foo/blah-version--EAPI.ebuild would be better than this nonsense.

And you will note that GLEP 55 includes an alternative for people who
think that .ebuild-X is bad but .something.X.eb is fine.

> If you want to do a radically new format, go ahead; no-one's stopping
> you or holding your work back in any way. The same cannot be said for
> your continued antics.

No, I want good, incremental improvement.

> Oh yeah, .exheres hasn't quite got the same cachet as .ebuild. No
> satisfaction in it, unlike getting Gentoo to 'submit'.

As you have been told several times before, Exherbo has entirely
different goals, and I don't consider it to be a replacement for
Gentoo. Please stop your pathetic attempts at trolling.

> I still haven't seen a version that cannot be handled within the
> Gentoo schema (and I note you were remarkably silent on suggestions
> that were put to you[2], as you always are if they didn't come from
> paludis.) If you're arguing no human input should be required, I
> think you have a misunderstanding of the user-base.

You still haven't read GLEP 55?

> Some of us prefer to know that a human has both tried the ebuild out,
> and gone through repoman. And that that person takes pride in their
> name on the commit, and stands by the principle of "you broke it, you
> fix it."
> 
> It's called a distribution, not "ciara's collection of stuff scraped
> from a webservice."

What does this have to do with anything? It's entirely unrelated to the
matter at hand.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Re: Re: The fallacies of GLEP55

[David Leverton]

On Friday 15 May 2009 21:06:13 Steven J Long wrote:
> In practical terms, this is a useless proposal. It rightly got trashed
> last year.

No, it did not get "trashed", despite some people's attempts to make their 
side sound more popular than it really is.  Some people like the idea, some 
don't, and people have put forward various arguments in both directions.  If 
it were really as widely hated as you claim (presumably with the implication 
that the people who still support it are horrible and evil for even thinking 
about it) then it wouldn't still be under discussion.

[gentoo-dev] Re: Re: Re: The fallacies of GLEP55

[Steven J Long]

David Leverton wrote:

> On Friday 15 May 2009 21:06:13 Steven J Long wrote:
>> In practical terms, this is a useless proposal. It rightly got trashed
>> last year.
> 
> No, it did not get "trashed", despite some people's attempts to make their
> side sound more popular than it really is.

Yes there's a lot of that about.

>  Some people like the idea, some  don't, and people have put forward
> various arguments in both directions.
Well that adds a lot. Suffice to say that some people not only dislike the
idea but actually think it's a massively retrograde step, going as it does
against basic Software Engineering principles some of us have seen the
reason for at the coalface. (You know, where there are real consequences to
getting things wrong, that will affect your real-life, your home and your
family.)

> If it were really as widely hated as you claim (presumably with the
> implication that the people who still support it are horrible and evil for
> even thinking about it)
Hmm way to go putting thoughts in my head that aren't there. I realise
you're very good at couching your assertions in language that can later be
denied, but that only really works in this situation. Try it in the
workplace and see how far you get.

> then it wouldn't still be under discussion.
Or alternatively, some people just can't take 'no' for an answer, and
conceding even one flaw is too much for someone's ego, especially in the
conduct of what appears to be a concerted campaign to get Gentoo to
admit they were "wrong" to take whatever action they took so many years ago.
(Only not in so many words. Apparently, ceding control of the direction of
all future innovation will suffice to heal the wound.)

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

Re: [gentoo-dev] Re: Re: Re: The fallacies of GLEP55

[David Leverton]

On Sunday 24 May 2009 21:40:57 Steven J Long wrote:
> Hmm way to go putting thoughts in my head that aren't there.

Yes, that sums you up quite nicely.

Re: [gentoo-dev] The fallacies of GLEP55

[David Leverton]

On Thursday 14 May 2009 19:06:51 Patrick Lauer wrote:
> For quite some time (over a year, actually) we've been discussing the
> mysterious and often misunderstood GLEP55.
> [http://www.gentoo.org/proj/en/glep/glep-0055.html]

We agree on the latter adjective, if nothing else.

> The proposed solution to a problem that is never refined, in short, is to
> add the EAPI into the ebuild filename "to make things easier". Which is a
> rather unsubstantiated idea that doesn't really add up if you look at it
> ... and it adds some artifacts that we've been laughing about for a decade
> because microsoft did the exact same thing (binding the executable-ness of
> a file to the filename).

I wonder where people get this strange delusion that only Windows uses file 
extensions for anything?

> Here's just some of the theories in support of GLEP55 that have been thrown
> at me, and a few words to show how they are not really issues:
>
> "You need to know the EAPI to parse the ebuild to find the EAPI"
> Obviously that's not true, because somehow we manage at the moment.

Because we haven't yet introduced any changes that would break it.

> And if one does a small restriction (which doesn't restrict current
> behaviour because all in-tree ebuilds currently fit within this limitation)
> it becomes trivial again:
>
> Let EAPI be defined as (the part behind the = of) the first line of the
> ebuild starting with EAPI=
>
> As long as ebuilds remain shell-like this is not much of a restriction,

It's an arbitrary, magical restriction that doesn't follow from the general 
rules of the language that ebuilds are written in - you said it 
yourself, "shell-like".   "printf -v EAPI 1" is perfectly valid shell (at 
least if we decide to allow bash 3.1 features), and has the same effect 
as "EAPI=1" under the rules of the shell, but it's not compatible with your 
new rule.

> "You need to parse the ebuild and its eclasses to find the EAPI!"
> See above, and eclasses shouldn't change EAPI anyway. It leads to lots of
> strange effects and is implicitly impossible with GLEP55 anyway, so it
> might be easier to just declare it invalid.

With GLEP 55 it's naturally invalid, and can't possibly be assumed to be 
valid.  If you keep the assignment-like syntax but disallow it in eclasses, 
it's an extra weird restriction.

> "It's slower!"
> The theory here being that a stat() is needed if it is encoded in the
> filename, but a stat() followed by an open() to parse it from the file.
> Well then, just cache it! You can use the mtime to check the cache validity
> (which means you do a stat() anyway, so with glep55 caching it is actually
> slower!), and then you have to parse the ebuild anyway for the other
> metadata. So the "extra" cost of finding the EAPI is ... what extra cost?
> The only case when it is actually slower is when there is no cache because
> then you have to parse the ebuild. But that "degenerate" case will only hit
> some overlay users and people like developers that can wait .3 seconds
> longer. And ... uhm ... to extract other metadata like DEPENDS you'll have
> to parse it anyway.

And people say Gentoo users are ricers... the whole speed argument is a 
strawman, relevant only to the extent that we don't want to make things 
noticeably slower than they are already.  You claim that GLEP 55 does that, 
but this claim seems to be based on the assumption that without it there 
would be no need to parse the filename in any way, which clearly isn't true.

> "But we need to be able to change things in the future!"
> Well then. Once we have identified such an issue we can do the changes.
> Until then it's not even clear if there are such changes, so why should we
> break current known and predictable behaviour to satisfy a need we don't
> even have? Make a structured proposal defining a concrete problem in
> unambiguous terms, list all the ways to solve this issue, including
> advantages and disadvantages, and we can get it voted on and ratified
> within a month.

The same thing happened when EAPI itself was introduced.  EAPI support was 
committed to Portage in late September 2005, but the first new EAPI in 
mainstream Gentoo was introduced in early October 2007, just over two years 
later.  That's clearly not an argument for rejecting a compatibility 
mechanism.

It's also not necessary to start putting EAPI in the filename as soon as it's 
approved.  The Council could easily state that "once we need to make a change 
that requires a stronger mechanism than EAPI is currently, we'll do it like 
this" - no need to reject it, or keep "maybe"ing it for eternity.

Of course, there's at least one GLEP 55-scope change that people want already, 
to the extent that they're making up hacks to work around the lack of it, 
namely per-package eclasses.  I would hope that everyone agrees that a 
package manager-supported mechanism would be far preferably (I know that 
vapier does).

> "We want to change the versioning rules!"
> Why do you want that, and what do we gain from it?

Aside from -scm (below), there are various changes suggested at 
http://lists.exherbo.org/pipermail/exherbo-dev/2009-February/000400.html that 
would help match various upstream version formats more closely, and reduce 
the amount of versionator hacking.  Even if you don't like any of those 
examples, the version format has changed in the past, and it would be quite 
foolish to design around the assumption that it will never happen again.

> "Having GLEP55 allows us to add GLEP54 without issues!"
> Yeah, uhm, the live-ness of an ebuild is an attribute.

No more so than the "1.2ness".  "This ebuild installs the latest sources from 
the repository" is the same class of information as "this ebuild installs 
version 1.2", and therefore belongs in the same place.

> How about we add it 
> to metadata, as we should for all metadata? Define a key, I don't know ...
> LIVE ? LIVE="true". There. No need to fix the filename. And now stop mixing
> up issues because it is highly confusing!

That still doesn't solve the version ordering issues, as has already been said 
countless times.

> "Obviously you don't understand the issue, because if you did you'd support
> it!"
> Uhm, obviously you have no idea what you are saying. But  just to play
> along ... if it were that obvious we wouldn't have had to discuss it for so
> long.

You'd think so, but it never seems to work out that way.

> Maybe understanding the issue forces one to support the current 
> behaviour!

Unlikely.

Re: [gentoo-dev] The fallacies of GLEP55

[Jeremy Olexa]

On Thu, May 14, 2009 at 2:06 PM, David Leverton
<levertond@googlemail.com> wrote:
> yourself, "shell-like".   "printf -v EAPI 1" is perfectly valid shell (at
> least if we decide to allow bash 3.1 features), and has the same effect

To stir things up:
Who decides this? There are more and more bash-3.1 features in the
tree and I brought it up to the Council months ago becase the PMS says
that only bash-3.0 is allowed but no one cares.

-Jeremy

Re: [gentoo-dev] The fallacies of GLEP55

[Ciaran McCreesh]

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

On Thu, 14 May 2009 14:15:28 -0500
Jeremy Olexa <darkside@gentoo.org> wrote:
> On Thu, May 14, 2009 at 2:06 PM, David Leverton
> <levertond@googlemail.com> wrote:
> > yourself, "shell-like".   "printf -v EAPI 1" is perfectly valid
> > shell (at least if we decide to allow bash 3.1 features), and has
> > the same effect
> 
> To stir things up:
> Who decides this? There are more and more bash-3.1 features in the
> tree and I brought it up to the Council months ago becase the PMS says
> that only bash-3.0 is allowed but no one cares.

Can't allow newer bash features in global scope until the whole "can't
make global scope changes" thing is sorted out.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] The fallacies of GLEP55

[Ben de Groot]

Patrick Lauer wrote:
> For quite some time (over a year, actually) we've been discussing the
> mysterious and often misunderstood GLEP55. 
> [http://www.gentoo.org/proj/en/glep/glep-0055.html]
> 
> The proposed solution to a problem that is never refined, 

This, in my opinion, is the crux of the matter. Most of us apparently
are not sufficiently convinced that there actually is a problem. Until
the problem is explained with clarity, the rest of the proposal is useless.

> "Obviously you don't understand the issue, because if you did you'd support 
> it!"

I concur that speaking for myself, I don't understand the issue. And it
looks like many others don't either. So if anyone wants to promote this
GLEP, their job is clear: make people understand what the issue is here,
and convince them it is actually an issue. (Examples, scenarios usually
work well, indeed a lot better than calling people names.)

> And maybe we can now spend the same amount of
> council-time (it has been eating time for over a year!) to get important 
> things done ...

I want to call on the Council to reject this GLEP in its current form,
as the problem has been insufficiently clarified. We should not waste
more time on it.

Cheers,
-- 
Ben de Groot
Gentoo Linux developer (qt, media, lxde, desktop-misc)
Gentoo Linux Release Engineering PR liaison
______________________________________________________

Re: [gentoo-dev] The fallacies of GLEP55

[Peter Alfredsen]

On Thu, 14 May 2009 22:03:22 +0200
Ben de Groot <yngwin@gentoo.org> wrote:

> I concur that speaking for myself, I don't understand the issue. And
> it looks like many others don't either. So if anyone wants to promote
> this GLEP, their job is clear: make people understand what the issue
> is here, and convince them it is actually an issue. (Examples,
> scenarios usually work well, indeed a lot better than calling people
> names.)

We need a mechanism to be able to use newer bash-features in ebuilds.
Preferably one that doesn't go "Wait a couple of years, hope
everyone did X then Just Do it." We want one that goes like "Get a new
EAPI approved with new minimum bash-version attached, start using cool
stuff like ( Bash-4.0 ):

shopt -s globstar
for i in /usr/share/man/**/*remote*
do
	stuff
done

Built-in find in bash, how do you like them bananas? :-)

find equivalent would be, if you wanted the same level of space-safety:

while read -r line
do
	stuff
done < <(find /usr/share/man -name '*remote*')

Personally, I like the first version better. It would be cool if we
could start using it sooner. GLEP-55 provides the "clean" solution, by
just making the file name indicate what's inside. No need to parse, no
nothing. Portage is currently testing a "first line with EAPI=
determines EAPI" method. That's slightly less clean, but has the added
benefit of not breaking anything that relies on .ebuild extension for
ebuilds and I think it's not an unreasonable limitation on ebuilds to
require EAPI= to be parseable by !bash.

/loki_val

Re: [gentoo-dev] The fallacies of GLEP55

[William Hubbs]

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

Hi,

I realize that I'm asking this very late in the discussion, so please
bear with me if it has been hashed before.

On Thu, May 14, 2009 at 11:16:23PM +0200, Peter Alfredsen wrote:
> We need a mechanism to be able to use newer bash-features in ebuilds.
> Preferably one that doesn't go "Wait a couple of years, hope
> everyone did X then Just Do it." We want one that goes like "Get a new
> EAPI approved with new minimum bash-version attached, start using cool
> stuff like ( Bash-4.0 ):
 
 <snip>

> Personally, I like the first version better. It would be cool if we
> could start using it sooner. GLEP-55 provides the "clean" solution, by
> just making the file name indicate what's inside. No need to parse, no
> nothing. Portage is currently testing a "first line with EAPI=
> determines EAPI" method. That's slightly less clean, but has the added
> benefit of not breaking anything that relies on .ebuild extension for
> ebuilds and I think it's not an unreasonable limitation on ebuilds to
> require EAPI= to be parseable by !bash.
 
I don't know how strong this argument is, but here is my opinion about
the issue, followed up with a question.

The second solution seems to be the better one because it does not go
against standards.  For example, we see extentions like .c, .py and
.pl, instead of .c-43, .py-25 and .pl-58.  There are ways within the
languages to tell which version of the compiler is compiling them as
needed.  So, If we say that, EAPI 4, for example, requires bash-4.0,
Isn't there a way the PM could find out which version of bash is being
run, compare that to the EAPI, then take appropriate action?

- -- 
William Hubbs
gentoo accessibility team lead
williamh@gentoo.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkoMkdUACgkQblQW9DDEZTihowCdEynGXsB0Z1r9y43VeWEs9JLF
SrQAn2iNPikCR+tZHGyrv+ykr4y1D+81
=6F5i
-----END PGP SIGNATURE-----

Re: [gentoo-dev] The fallacies of GLEP55

[Ciaran McCreesh]

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

On Thu, 14 May 2009 16:49:09 -0500
William Hubbs <williamh@gentoo.org> wrote:
> The second solution seems to be the better one because it does not go
> against standards.  For example, we see extentions like .c, .py and
> .pl, instead of .c-43, .py-25 and .pl-58.  There are ways within the
> languages to tell which version of the compiler is compiling them as
> needed.  So, If we say that, EAPI 4, for example, requires bash-4.0,
> Isn't there a way the PM could find out which version of bash is being
> run, compare that to the EAPI, then take appropriate action?

It can't, because it doesn't know the EAPI until it's sourced the thing
using bash. Using things like += in global scope will break older bash
versions to the point that they can't reliably extract EAPI.

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

iEYEARECAAYFAkoMkuMACgkQ96zL6DUtXhEWmQCeOIHQLeguFo7vZXQCG5aE5imF
0rIAn1tOEyeyATdwoLGI8dCUs5s3afKR
=JRMB
-----END PGP SIGNATURE-----

Re: [gentoo-dev] The fallacies of GLEP55

[Patrick Lauer]

On Thursday 14 May 2009 23:53:37 Ciaran McCreesh wrote:
> On Thu, 14 May 2009 16:49:09 -0500
>
> William Hubbs <williamh@gentoo.org> wrote:
> > The second solution seems to be the better one because it does not go
> > against standards.  For example, we see extentions like .c, .py and
> > .pl, instead of .c-43, .py-25 and .pl-58.  There are ways within the
> > languages to tell which version of the compiler is compiling them as
> > needed.  So, If we say that, EAPI 4, for example, requires bash-4.0,
> > Isn't there a way the PM could find out which version of bash is being
> > run, compare that to the EAPI, then take appropriate action?
>
> It can't, because it doesn't know the EAPI until it's sourced the thing
> using bash. Using things like += in global scope will break older bash
> versions to the point that they can't reliably extract EAPI.

Trying to pull a Goebbels, eh?

As I've said a few times you don't have to do something as complex as sourcing 
it. In most cases you might get lucky and have some form of caching or pre-
parsed data available, so you don't even have to care. And in the other cases, 
assuming that we're talking about current ebuilds which are shell-ish and 
either define EAPI explicitly or can be assumed to be EAPI0 you can search 
with a simple regexp. That's so funky that it even works!

So if you were a lazy Unix coder you'd just restrict the current rules a bit 
so that there's only one line starting with EAPI= allowed (or maybe you just 
take the first or last one, but that's annoying) and if no such line matches 
you can safely assume EAPI0

Maybe you're very lazy, so you explicitly forbid eclasses from setting or 
changing EAPI. That also avoids weird effects that make you lose lots of time 
for debugging because you didn't think about what would happen if foo.eclass 
set EAPI="3.14" and bar.eclass inherited later set EAPI="1" ...

And magically you haven't really changed current behaviour, can get the EAPI 
without sourcing it and you can be lazy once more. Isn't it great?

Re: [gentoo-dev] The fallacies of GLEP55

[Arun Raghavan]

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

On Fri, 2009-05-15 at 00:44 +0200, Patrick Lauer wrote:
[...]
> So if you were a lazy Unix coder you'd just restrict the current rules a bit 
> so that there's only one line starting with EAPI= allowed (or maybe you just 
> take the first or last one, but that's annoying) and if no such line matches 
> you can safely assume EAPI0
> 
> Maybe you're very lazy, so you explicitly forbid eclasses from setting or 
> changing EAPI. That also avoids weird effects that make you lose lots of time 
> for debugging because you didn't think about what would happen if foo.eclass 
> set EAPI="3.14" and bar.eclass inherited later set EAPI="1" ...
> 
> And magically you haven't really changed current behaviour, can get the EAPI 
> without sourcing it and you can be lazy once more. Isn't it great?

As I've stated a long time ago, I'm for this solution. My understanding
is that there are 2 objections to this:

1) We can't change the ebuild format to XML or what have you. I think
this is a problem to deal with *if it ever happens*. I am completely
against trying to solve a problem that will not exist in the foreseeable
future.

2) There might be a performance impact for cases where the metadata is
uncached - I think the impact is acceptable in the face of the fugliness
added by putting the EAPI in the ebuild's name (Joe Peterson summarise
this quite well earlier [1]).

Really, the key issue seems to be (1), because there's no other good
reason to be trying to adopt this GLEP.

-- Arun

[1]
http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg29311.html

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

Re: [gentoo-dev] The fallacies of GLEP55

[Ciaran McCreesh]

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

On Sat, 16 May 2009 00:28:36 +0530
Arun Raghavan <ford_prefect@gentoo.org> wrote:
> As I've stated a long time ago, I'm for this solution. My
> understanding is that there are 2 objections to this:

3) It doesn't solve the problem. It doesn't allow things like version
format extensions.

That's the big one, not the other two.

-- 
Ciaran McCreesh

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

[gentoo-dev] Re: The fallacies of GLEP55

[Steven J Long]

Ciaran McCreesh wrote:

> On Sat, 16 May 2009 00:28:36 +0530
> Arun Raghavan <ford_prefect@gentoo.org> wrote:
>> As I've stated a long time ago, I'm for this solution. My
>> understanding is that there are 2 objections to this:
> 
> 3) It doesn't solve the problem. It doesn't allow things like version
> format extensions.
> 
> That's the big one, not the other two.
>
Debian-style epochs, which were mooted to this list over a year ago, do
however, given that we already have SLOT.

They're also a lot simpler and do not 'require' a potentially unlimited
set of new extensions for every "new format" (look, shiny!) that a herd
might experiment with.

And again, you haven't explained why an internal format specification
should allow NN variants on the format (beyond your usual sniping at
the level of developer expertise, which you propose to address by making
it easy to mess up the spec, instead of simply expecting people to learn;
which they certainly appear capable of doing, as the ebuild tree attests.)

In summary, the proposed benefit doesn't seem like one, and certainly not
enough to justify the fundamental noob mistake of breaking encapsulation.

Personally I remain unconvinced this is even enough to merit the use of
epochs. I'd much rather see them kept in reserve for a real issue, and
an innovation which actually solves a problem our end-users face. So no,
not a "big one" at all; just yet another student attempt at coercion
cloaked in obfuscation. No more, no less.

'Sometimes I find it hard to believe that people can attach so much of
their ego to one particular design, even when the obvious flaws are
pointed out. As a wise man once said to me:
"There also comes a point where you realise that no one can know
everything, so it's not a problem to ask someone or on occasion be
wrong.."'[1]

Think about it. No? Ah well never mind, didn't really expect you to ever
accept you might still have something to learn. No doubt there'll be
another 50 or so emails from you next time I catch up on the list. And
of course if each one doesn't have a detailed objection, it's enough for
you to claim that you've run it past the list. And if they do, it's
simply because the person doesn't understand (despite your clear and
lucid explanations to the list.) </sarcasm>

[project]
You are aware that many Gentoo developers simply cba to argue with you?
Since the stuff you're proposing often makes no effective difference to
what they're doing anyway (it's /that/ useful), it can seem easier simply
to let you have your way. Believe it or not, that's how I feel; I'm only
speaking now as your GLEPs are so massively flawed, that I've been told
I would have to maintain a patched portage were they to go ahead.

Happily the only patches required would be to get rid of the crap you're
proposing. I *still* resent the extra workload, and the fact that it's
only necessitated because you haven't got over the rejection of being the
only developer ever to be kicked in such a fashion. Twice.
[/project]

[1] http://igliot.blogspot.com/
--
#friendly-coders -- We're friendly but we're not /that/ friendly ;-)

Re: [gentoo-dev] The fallacies of GLEP55

[William Hubbs]

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

On Thu, May 14, 2009 at 10:53:37PM +0100, Ciaran McCreesh wrote:
> It can't, because it doesn't know the EAPI until it's sourced the thing
> using bash. Using things like += in global scope will break older bash
> versions to the point that they can't reliably extract EAPI.
 
I just figured out a line in bash that will get an EAPI without
sourcing the ebuild:

eval `grep '^EAPI=' ebuildfile | head -n 1`

will set EAPI in the current scope to EAPI in the ebuild, without
sourcing it, unless the issue with something like this would be its use
of grep and head, but these are both in the system set, so unless you
don't want to depend on the system set, I don't know what the objection
would be.

- -- 
William Hubbs
gentoo accessibility team lead
williamh@gentoo.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkoNxeEACgkQblQW9DDEZThaFACfYSQTpPTxfh3MzvErzbSNGZ8M
46AAoIyGTJxbWQ4Be7075uHXYN+hfnDl
=X3Wn
-----END PGP SIGNATURE-----

Re: [gentoo-dev] The fallacies of GLEP55

[Ciaran McCreesh]

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

On Fri, 15 May 2009 14:43:29 -0500
William Hubbs <williamh@gentoo.org> wrote:
> On Thu, May 14, 2009 at 10:53:37PM +0100, Ciaran McCreesh wrote:
> > It can't, because it doesn't know the EAPI until it's sourced the
> > thing using bash. Using things like += in global scope will break
> > older bash versions to the point that they can't reliably extract
> > EAPI.
>  
> I just figured out a line in bash that will get an EAPI without
> sourcing the ebuild:
> 
> eval `grep '^EAPI=' ebuildfile | head -n 1`
> 
> will set EAPI in the current scope to EAPI in the ebuild, without
> sourcing it, unless the issue with something like this would be its
> use of grep and head, but these are both in the system set, so unless
> you don't want to depend on the system set, I don't know what the
> objection would be.

The objection is that your code doesn't work. It's entirely legal to
do, say:

    export EAPI="1"

or:

    inherit versionator

    if version_is_at_least 2 ; then
        EAPI="2"
    else
        EAPI="0"
    fi

Besides, if we were able to do what your code does, we'd just code it
natively, not use external programs.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] The fallacies of GLEP55

[Tobias Klausmann]

Hi! 

On Fri, 15 May 2009, Ciaran McCreesh wrote:
> > eval `grep '^EAPI=' ebuildfile | head -n 1`
> > 
> > will set EAPI in the current scope to EAPI in the ebuild, without
> > sourcing it, unless the issue with something like this would be its
> > use of grep and head, but these are both in the system set, so unless
> > you don't want to depend on the system set, I don't know what the
> > objection would be.
> 
> The objection is that your code doesn't work. It's entirely legal to
> do, say:
> 
>     export EAPI="1"

Change the spec, then. Or aren't we talking about
writing/changing/clarifying a spec right now? I mean... yes,
ebuilds are actually bash scripts. But I don't see a problem with
using a subset of what's allowed for *this* *specific* line. 

Actually, I personally would prefer taking it out of the
parsed-by-bash part entirely. Add it as a shebang-like line at
the top:

#EAPI-1

as the first or second line. Allowing it on the second line
allows you to later bolt on a true shebang-line if you should so
desire. Only having to look at the first two lines makes finding
it out easier (note that I don't call that parsing on purpose).

> or:
> 
>     inherit versionator
> 
>     if version_is_at_least 2 ; then
>         EAPI="2"
>     else
>         EAPI="0"
>     fi

I was under the impression that it's illegal to change/set the
EAPI after using inherit.

Regards,
Tobias

-- 
Found on a small utility knife in MIT's lab supply:
"Caution.  Blade is sharp.  Keep out of children."

[gentoo-dev] Re: The fallacies of GLEP55

[Duncan]

Tobias Klausmann <klausman@gentoo.org> posted
20090516092710.GA3221@eric.schwarzvogel.de, excerpted below, on  Sat, 16
May 2009 11:27:10 +0200:

> On Fri, 15 May 2009, Ciaran McCreesh wrote:
 
>> or:
>> 
>>     inherit versionator
>> 
>>     if version_is_at_least 2 ; then
>>         EAPI="2"
>>     else
>>         EAPI="0"
>>     fi
> 
> I was under the impression that it's illegal to change/set the EAPI
> after using inherit.

The short answer, based on my understanding of posts to this point, would 
be that it's illegal for Gentoo (in-tree, council decided), but not 
necessarily for all the overlays and Gentoo based projects out there.

On the one hand, as a result of the above, Gentoo doesn't have to concern 
itself with the others and can decide what's best for the Gentoo tree and 
dev-sponsored overlays presumably targeted at eventual tree inclusion.  
On the other, regardless of what Gentoo decides, PMs wishing widest 
compatibility must be prepared for it anyway.  If I'm not mistaken, 
paludis has the widest deployment footprint both in practice and by goal 
at this point, so naturally, those developing it have broader concerns 
than just Gentoo.

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

[gentoo-dev] Re: The fallacies of GLEP55

[Steven J Long]

Duncan wrote:

> Tobias Klausmann <klausman@gentoo.org> posted
>> I was under the impression that it's illegal to change/set the EAPI
>> after using inherit.
> 
> The short answer, based on my understanding of posts to this point, would
> be that it's illegal for Gentoo (in-tree, council decided), but not
> necessarily for all the overlays and Gentoo based projects out there.
> 
> On the one hand, as a result of the above, Gentoo doesn't have to concern
> itself with the others and can decide what's best for the Gentoo tree and
> dev-sponsored overlays presumably targeted at eventual tree inclusion.
> On the other, regardless of what Gentoo decides, PMs wishing widest
> compatibility must be prepared for it anyway.  If I'm not mistaken,
> paludis has the widest deployment footprint both in practice and by goal
> at this point, so naturally, those developing it have broader concerns
> than just Gentoo.
> 
Well is it okay for the Gentoo developer list to be focussed firstly on
Gentoo product and solving the real issues people actually face as opposed
to non-issues like typing in a version specifier?

Further, if there is a valid use-case for setting EAPI after inherit, could
you (or someone else) explain what it is and why Gentoo, or indeed anyone
working on a Gentoo-based product, should care? ATM it looks like a classic
case of obfuscation; it's frankly well below par to post code that isn't
allowed and then claim it as a use-case requiring such massive changes.

I'd ask you also to consider prefix-portage when you assess the "deployment
footprint" (however you're coming to that conclusion.)
-- 
#friendly-coders -- We're friendly but we're not /that/ friendly ;-)

Re: [gentoo-dev] The fallacies of GLEP55

[Ciaran McCreesh]

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

On Sat, 16 May 2009 11:27:10 +0200
Tobias Klausmann <klausman@gentoo.org> wrote:
> Change the spec, then.

If we change the spec, we can't do anything with the change until we're
absolutely sure that everyone's updated both their ebuilds and their
package manager for it.

> Actually, I personally would prefer taking it out of the
> parsed-by-bash part entirely. Add it as a shebang-like line at
> the top:
> 
> #EAPI-1
> 
> as the first or second line. Allowing it on the second line
> allows you to later bolt on a true shebang-line if you should so
> desire. Only having to look at the first two lines makes finding
> it out easier (note that I don't call that parsing on purpose).

Would mean we'd have to change every existing ebuild everywhere.

> I was under the impression that it's illegal to change/set the
> EAPI after using inherit.

Nope. It's considered by some to be a QA violation, but EAPI's rules
are the same as the rules for any other metadata variable.

-- 
Ciaran McCreesh

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

[gentoo-dev] Re: The fallacies of GLEP55

[Steven J Long]

Ciaran McCreesh wrote:

> On Sat, 16 May 2009 11:27:10 +0200
> Tobias Klausmann <klausman@gentoo.org> wrote:
>> Change the spec, then.
> 
> If we change the spec, we can't do anything with the change until we're
> absolutely sure that everyone's updated both their ebuilds and their
> package manager for it.
>
Isn't that what the EAPI process is for?

The "support every overlay and old version of portage known to Gentoo"
is a "straw man" as one hears so much of. GLEP-55 makes explicit mention
of waiting for 2008.0 to ship, and Gentoo is ultimately only responsible
for the software it ships, including sunrise.

Since this is Gentoo, ofc, users will be kept in the loop, and upgrade paths
will be provided. It's about the users, or it used to be. (As is the GPL.)

>> Actually, I personally would prefer taking it out of the
>> parsed-by-bash part entirely. Add it as a shebang-like line at
>> the top:
>> 
>> #EAPI-1
>> 
>> as the first or second line. Allowing it on the second line
>> allows you to later bolt on a true shebang-line if you should so
>> desire. Only having to look at the first two lines makes finding
>> it out easier (note that I don't call that parsing on purpose).
>
Restricting (via repoman or equivalent) to first non-comment line
means we can use existing ebuilds with a minor edit, which can be
automated as part of repoman, with a warning if not -q etc, and
makes it easier to find, and to scan for. (I agree, it's not
parsing.)
 
> Would mean we'd have to change every existing ebuild everywhere.
> 
>> I was under the impression that it's illegal to change/set the
>> EAPI after using inherit.
> 
> Nope. It's considered by some to be a QA violation, but EAPI's rules
> are the same as the rules for any other metadata variable.
> 
So refine the spec; that's what the discussion is supposed to lead to,
remember?

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

Re: [gentoo-dev] Re: The fallacies of GLEP55

[Ciaran McCreesh]

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

On Sat, 16 May 2009 15:50:39 +0100
Steven J Long <slong@rathaus.eclipse.co.uk> wrote:
> Ciaran McCreesh wrote:
> > On Sat, 16 May 2009 11:27:10 +0200
> > Tobias Klausmann <klausman@gentoo.org> wrote:
> >> Change the spec, then.
> > 
> > If we change the spec, we can't do anything with the change until
> > we're absolutely sure that everyone's updated both their ebuilds
> > and their package manager for it.
> >
> Isn't that what the EAPI process is for?
> 
> The "support every overlay and old version of portage known to Gentoo"
> is a "straw man" as one hears so much of. GLEP-55 makes explicit
> mention of waiting for 2008.0 to ship, and Gentoo is ultimately only
> responsible for the software it ships, including sunrise.

You've missed the point. The point is, the EAPI process can't avoid the
"huge wait before we can use it" for certain types of change that
would be extremely useful. GLEP 55 fixes this limitation, and it's the
*only* thing that fixes this limitation.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Re: The fallacies of GLEP55

[Richard Freeman]

Ciaran McCreesh wrote:
> You've missed the point. The point is, the EAPI process can't avoid the
> "huge wait before we can use it" for certain types of change that
> would be extremely useful. GLEP 55 fixes this limitation, and it's the
> *only* thing that fixes this limitation.
> 

Except that if we had just implemented one of other proposals a year ago 
we probably would be done waiting now, while refusal to accept anything 
other than EAPI-in-filename might have you waiting for this ten years 
from now.

Sure, you might disagree with this, but that doesn't change the fact 
that we are at an impasse and I see no sign of this changing anytime 
soon - the last council clearly wasn't a big fan of GLEP 55 as it 
stands, and the current council seems to be going in the same direction. 
   I guess you can always wait for the next council election and see 
what 2010 brings.  However, I hope you're not going to do that to "speed 
things up!"

Re: [gentoo-dev] Re: The fallacies of GLEP55

[Ciaran McCreesh]

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

On Sat, 16 May 2009 11:15:58 -0400
Richard Freeman <rich0@gentoo.org> wrote:
> Ciaran McCreesh wrote:
> > You've missed the point. The point is, the EAPI process can't avoid
> > the "huge wait before we can use it" for certain types of change
> > that would be extremely useful. GLEP 55 fixes this limitation, and
> > it's the *only* thing that fixes this limitation.
> > 
> 
> Except that if we had just implemented one of other proposals a year
> ago we probably would be done waiting now, while refusal to accept
> anything other than EAPI-in-filename might have you waiting for this
> ten years from now.

Had we gone with any of the other proposals a year ago, we'd be waiting
a year every time a new change came along.

> Sure, you might disagree with this, but that doesn't change the fact 
> that we are at an impasse and I see no sign of this changing anytime 
> soon - the last council clearly wasn't a big fan of GLEP 55 as it 
> stands, and the current council seems to be going in the same
> direction. I guess you can always wait for the next council election
> and see what 2010 brings.  However, I hope you're not going to do
> that to "speed things up!"

If the Council were not a fan of GLEP 55, they would have voted against
it.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Re: The fallacies of GLEP55

[Richard Freeman]

Ciaran McCreesh wrote:
> 
> Had we gone with any of the other proposals a year ago, we'd be waiting
> a year every time a new change came along.

Only if that change prevented obtaining EAPI from wherever it was 
placed.  If you want to make the rule "EAPI=foo appears at the start of 
a new line at the top of the ebuild - EAPI is obtained from the first 
such line" then that would handle any situation except where the ebuild 
format can't have EAPI=foo at the start of a line.  Even XML could 
handle that (just put it in tags flanking it on different lines - since 
XML ignores newlines).  Even a binary file format could handle that if 
you just put <newline>EAPI=<eapi><newline> in the header.  The only 
thing it wouldn't handle is dynamically setting the EAPI, but I'm not 
aware of any proposals that do (except for splitting the EAPI into two 
parts - one part defines how to obtain the EAPI the other part does it - 
but that also works with EAPI=foo in the ebuild).

> 
> If the Council were not a fan of GLEP 55, they would have voted against
> it.
> 

Why?  If there is no reason to move forward with haste why not just 
leave it out there and see if somebody comes up with a better idea or 
see if circumstances change?  If the perception was that there were a 
pressing need for forward movement on this chances are that somebody 
would have proposed an alternative GLEP and the council would have just 
approved that instead.

Re: [gentoo-dev] Re: The fallacies of GLEP55

[Ciaran McCreesh]

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

On Sat, 16 May 2009 11:34:14 -0400
Richard Freeman <rich0@gentoo.org> wrote:
> Ciaran McCreesh wrote:
> > Had we gone with any of the other proposals a year ago, we'd be
> > waiting a year every time a new change came along.
> 
> Only if that change prevented obtaining EAPI from wherever it was 
> placed.

...or if you want version format changes.

> > If the Council were not a fan of GLEP 55, they would have voted
> > against it.
> 
> Why?  If there is no reason to move forward with haste why not just 
> leave it out there and see if somebody comes up with a better idea or 
> see if circumstances change?  If the perception was that there were a 
> pressing need for forward movement on this chances are that somebody 
> would have proposed an alternative GLEP and the council would have
> just approved that instead.

Three out of six Council members considered GLEP 55 to be necessary
enough to vote yes on it the last time it was put to a vote...

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] The fallacies of GLEP55

[Tobias Klausmann]

Hi! 

On Sat, 16 May 2009, Ciaran McCreesh wrote:
> On Sat, 16 May 2009 11:27:10 +0200
> Tobias Klausmann <klausman@gentoo.org> wrote:
> > Change the spec, then.
> 
> If we change the spec, we can't do anything with the change until we're
> absolutely sure that everyone's updated both their ebuilds and their
> package manager for it.

The change the extension *once*, and make an EAPI spec at the top
of the file for that file format. 

I'd rather have the extension change once, with pain, than with
every EAPI change. My opinion is that reflecting the EAPI in the
file name is a very, very Bad Idea.

> > Actually, I personally would prefer taking it out of the
> > parsed-by-bash part entirely. Add it as a shebang-like line at
> > the top:
> > 
> > #EAPI-1
> > 
> > as the first or second line. Allowing it on the second line
> > allows you to later bolt on a true shebang-line if you should so
> > desire. Only having to look at the first two lines makes finding
> > it out easier (note that I don't call that parsing on purpose).
> 
> Would mean we'd have to change every existing ebuild everywhere.

No, it means we have to change every ebuild of which we claim
that it works that way. Versioned file structures *without*
changing the extension have been done and they have worked.

Yes, there may be pain along the way. But that is true no matter
which route we go.

What people prefer is in no small way tied to the amount of pain
they expect from a given solution. And they're right to do so.

Regards,
Tobias
-- 
Found on a small utility knife in MIT's lab supply:
"Caution.  Blade is sharp.  Keep out of children."

Re: [gentoo-dev] The fallacies of GLEP55

[Ciaran McCreesh]

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

On Sat, 16 May 2009 17:32:24 +0200
Tobias Klausmann <klausman@gentoo.org> wrote:
> On Sat, 16 May 2009, Ciaran McCreesh wrote:
> > On Sat, 16 May 2009 11:27:10 +0200
> > Tobias Klausmann <klausman@gentoo.org> wrote:
> > > Change the spec, then.
> > 
> > If we change the spec, we can't do anything with the change until
> > we're absolutely sure that everyone's updated both their ebuilds
> > and their package manager for it.
> 
> The change the extension *once*, and make an EAPI spec at the top
> of the file for that file format. 

That doesn't let us do version format changes.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] The fallacies of GLEP55

[Tobias Klausmann]

Hi! 

On Sat, 16 May 2009, Ciaran McCreesh wrote:
> On Sat, 16 May 2009 17:32:24 +0200
> Tobias Klausmann <klausman@gentoo.org> wrote:
> > On Sat, 16 May 2009, Ciaran McCreesh wrote:
> > > On Sat, 16 May 2009 11:27:10 +0200
> > > Tobias Klausmann <klausman@gentoo.org> wrote:
> > > > Change the spec, then.
> > > 
> > > If we change the spec, we can't do anything with the change until
> > > we're absolutely sure that everyone's updated both their ebuilds
> > > and their package manager for it.
> > 
> > The change the extension *once*, and make an EAPI spec at the top
> > of the file for that file format. 
> 
> That doesn't let us do version format changes.

What exactly is _needed_ there? EAPI versions could be arbitrary
strings without \n in them. I see nothing you couldn't get into
that.

Or are we talking about the *ebuild* versions? I see that as
different matter. Plus: You could change the version format with
the changed extension. I sure do hope there are no plans on
making those changes as often as new EAPIs.

Regards,
Tobias

-- 
Found on a small utility knife in MIT's lab supply:
"Caution.  Blade is sharp.  Keep out of children."

Re: [gentoo-dev] The fallacies of GLEP55

[Ciaran McCreesh]

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

On Sat, 16 May 2009 17:43:32 +0200
Tobias Klausmann <klausman@gentoo.org> wrote:
> > That doesn't let us do version format changes.
> 
> Or are we talking about the *ebuild* versions? I see that as
> different matter. Plus: You could change the version format with
> the changed extension. I sure do hope there are no plans on
> making those changes as often as new EAPIs.

Yes, those. The current rules include some pointless arbitrary
restrictions that are only there for historical reasons and that mean
people have to mess with convoluted MY_PV things.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] The fallacies of GLEP55

[Tobias Klausmann]

Hi! 

On Sat, 16 May 2009, Ciaran McCreesh wrote:

> On Sat, 16 May 2009 17:43:32 +0200
> Tobias Klausmann <klausman@gentoo.org> wrote:
> > > That doesn't let us do version format changes.
> > 
> > Or are we talking about the *ebuild* versions? I see that as
> > different matter. Plus: You could change the version format with
> > the changed extension. I sure do hope there are no plans on
> > making those changes as often as new EAPIs.
> 
> Yes, those. The current rules include some pointless arbitrary
> restrictions that are only there for historical reasons and that mean
> people have to mess with convoluted MY_PV things.

Still: a sane spec for those plus a sane spec for inside-the-file
EAPI specs can be done with/during *one* extension change. 

Any further features that mandate a change in filename format?
Pile them on. 

Regards,
Tobias

-- 
Found on a small utility knife in MIT's lab supply:
"Caution.  Blade is sharp.  Keep out of children."

Re: [gentoo-dev] The fallacies of GLEP55

[Ciaran McCreesh]

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

On Sat, 16 May 2009 17:55:01 +0200
Tobias Klausmann <klausman@gentoo.org> wrote:
> > Yes, those. The current rules include some pointless arbitrary
> > restrictions that are only there for historical reasons and that
> > mean people have to mess with convoluted MY_PV things.
> 
> Still: a sane spec for those plus a sane spec for inside-the-file
> EAPI specs can be done with/during *one* extension change. 

GLEP 55's just one extension change: it moves from .ebuild
to .ebuild-EAPI.

> Any further features that mandate a change in filename format?
> Pile them on. 

There probably will be, and we don't know what they all are yet.
Unfortunately we can't see the future.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] The fallacies of GLEP55

[Tobias Klausmann]

Hi! 

On Sat, 16 May 2009, Ciaran McCreesh wrote:
> Tobias Klausmann <klausman@gentoo.org> wrote:
> > > Yes, those. The current rules include some pointless arbitrary
> > > restrictions that are only there for historical reasons and that
> > > mean people have to mess with convoluted MY_PV things.
> > 
> > Still: a sane spec for those plus a sane spec for inside-the-file
> > EAPI specs can be done with/during *one* extension change. 
> 
> GLEP 55's just one extension change: it moves from .ebuild
> to .ebuild-EAPI.

So we're not talking about .ebuild-2 for EAPI=2, .ebuild-3 for
EAPI=3 etc? That would just be silly and it was the first idea I
got when I saw the proposal.

Also, I think there might be better options for the new
extensions (.gbuild?, just a random idea).

Aside from that, one idea that came to me recently was to specify
per tree what kind of files (version-format-wise, EAPI
elsewhere[0]) a PM has to expect. Tree distributors (Gentoo
itself, other similar distros, overlays... ) would be Providing
that information along a similar route as profiles/repo_name.
This would also reduce the amount of mixing and matching version
formats (something undesirable, if you ask me). It would also
make it easier to take a look at historical (snapshots of)
repositories.

[0] I see EAPI specification and version-format spec as separate
issues.

> > Any further features that mandate a change in filename format?
> > Pile them on. 
> 
> There probably will be, and we don't know what they all are yet.
> Unfortunately we can't see the future.

I meant further as in "not discussed yet".

Regards,
Tobias
-- 
Found on a small utility knife in MIT's lab supply:
"Caution.  Blade is sharp.  Keep out of children."

Re: [gentoo-dev] The fallacies of GLEP55

[Ciaran McCreesh]

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

On Sat, 16 May 2009 18:15:58 +0200
Tobias Klausmann <klausman@gentoo.org> wrote:
> On Sat, 16 May 2009, Ciaran McCreesh wrote:
> > Tobias Klausmann <klausman@gentoo.org> wrote:
> > > > Yes, those. The current rules include some pointless arbitrary
> > > > restrictions that are only there for historical reasons and that
> > > > mean people have to mess with convoluted MY_PV things.
> > > 
> > > Still: a sane spec for those plus a sane spec for inside-the-file
> > > EAPI specs can be done with/during *one* extension change. 
> > 
> > GLEP 55's just one extension change: it moves from .ebuild
> > to .ebuild-EAPI.
> 
> So we're not talking about .ebuild-2 for EAPI=2, .ebuild-3 for
> EAPI=3 etc? That would just be silly and it was the first idea I
> got when I saw the proposal.

Yes, yes we are. That's just one change, from a static string to a
pattern for a string.

Heck, pretend GLEP 55 says .eapi-X.eb instead if it makes you happy.

> Aside from that, one idea that came to me recently was to specify
> per tree what kind of files (version-format-wise, EAPI
> elsewhere[0]) a PM has to expect. Tree distributors (Gentoo
> itself, other similar distros, overlays... ) would be Providing
> that information along a similar route as profiles/repo_name.
> This would also reduce the amount of mixing and matching version
> formats (something undesirable, if you ask me). It would also
> make it easier to take a look at historical (snapshots of)
> repositories.

It also means an end to nice incremental updates.

> [0] I see EAPI specification and version-format spec as separate
> issues.

It's something we can do as an EAPI thing, and by doing so we keep the
smooth upgrade path thing.

> > > Any further features that mandate a change in filename format?
> > > Pile them on. 
> > 
> > There probably will be, and we don't know what they all are yet.
> > Unfortunately we can't see the future.
> 
> I meant further as in "not discussed yet".

Well, I strongly doubt that anyone's already thought of all the useful
changes we might want to make in the future, so I don't think proposing
a solution that assumes that they have is a good idea.

Otherwise, in another year or two we'll just be back to "well we need
to change extensions again, but let's just do it as a second one-off
thing".

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] The fallacies of GLEP55

[Tobias Klausmann]

Hi! 

On Sat, 16 May 2009, Ciaran McCreesh wrote:
> > So we're not talking about .ebuild-2 for EAPI=2, .ebuild-3 for
> > EAPI=3 etc? That would just be silly and it was the first idea I
> > got when I saw the proposal.
> 
> Yes, yes we are. That's just one change, from a static string to a
> pattern for a string.
> 
> Heck, pretend GLEP 55 says .eapi-X.eb instead if it makes you happy.

It doesn't. I forsee a non-trivial amount of extra work, breakage
and pain with a moving extension. And not anywhere near enough
benefit in exchange for it.

> > Aside from that, one idea that came to me recently was to specify
> > per tree what kind of files (version-format-wise, EAPI
> > elsewhere[0]) a PM has to expect. Tree distributors (Gentoo
> > itself, other similar distros, overlays... ) would be Providing
> > that information along a similar route as profiles/repo_name.
> > This would also reduce the amount of mixing and matching version
> > formats (something undesirable, if you ask me). It would also
> > make it easier to take a look at historical (snapshots of)
> > repositories.
> 
> It also means an end to nice incremental updates.

I think wanting incremental updates for version specs is a dream
we should abandon. The ordering issues avoided by doing so would
justify it alone, if you ask me. Yes, that means having a flag
day for every repository. But since I figure the new spec will be
a superset of the old spec, that could be automated.

As for EAPI, I feel we agree that it could live inside the file
itself under this scheme.

My point is this: from experience I suspect having a hard change
once and having easy progress on either side of it is preferable
to having mid-range complications all the time.

> Well, I strongly doubt that anyone's already thought of all the useful
> changes we might want to make in the future, so I don't think proposing
> a solution that assumes that they have is a good idea.

I think it's a river we should think about once we reach it.

> Otherwise, in another year or two we'll just be back to "well we need
> to change extensions again, but let's just do it as a second one-off
> thing".

My experience tells me that with proper preparation of *this*
change, that can be pushed past the "in the next ten years" mark.
And that is close enough to "indefinitely" for me. 

Regards,
Tobias
-- 
Found on a small utility knife in MIT's lab supply:
"Caution.  Blade is sharp.  Keep out of children."

Re: [gentoo-dev] The fallacies of GLEP55

[Ciaran McCreesh]

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

On Sat, 16 May 2009 18:31:38 +0200
Tobias Klausmann <klausman@gentoo.org> wrote:
> On Sat, 16 May 2009, Ciaran McCreesh wrote:
> > > So we're not talking about .ebuild-2 for EAPI=2, .ebuild-3 for
> > > EAPI=3 etc? That would just be silly and it was the first idea I
> > > got when I saw the proposal.
> > 
> > Yes, yes we are. That's just one change, from a static string to a
> > pattern for a string.
> > 
> > Heck, pretend GLEP 55 says .eapi-X.eb instead if it makes you happy.
> 
> It doesn't. I forsee a non-trivial amount of extra work, breakage
> and pain with a moving extension. And not anywhere near enough
> benefit in exchange for it.

Why? What's the big deal with .ebuild-? or .eapi-?.eb instead
of .ebuild?

> I think wanting incremental updates for version specs is a dream
> we should abandon.

It's an easy goal that we can deliver without much work. Ignoring it,
on the other hand, means holding Gentoo back unnecessarily every time
we want to change something.

> My point is this: from experience I suspect having a hard change
> once and having easy progress on either side of it is preferable
> to having mid-range complications all the time.

.ebuild-? is not complicated.

> > Well, I strongly doubt that anyone's already thought of all the
> > useful changes we might want to make in the future, so I don't
> > think proposing a solution that assumes that they have is a good
> > idea.
> 
> I think it's a river we should think about once we reach it.

Why? We know we'll reach it. Pretending we won't just means when we do
reach it, we'll still be crossing it on foot rather than in a
helicopter.

> > Otherwise, in another year or two we'll just be back to "well we
> > need to change extensions again, but let's just do it as a second
> > one-off thing".
> 
> My experience tells me that with proper preparation of *this*
> change, that can be pushed past the "in the next ten years" mark.
> And that is close enough to "indefinitely" for me. 

The only way it'll be "in the next ten years" rather than "in the next
two years" is if Gentoo continues its current approach of making
changes require every single person to agree...

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] The fallacies of GLEP55

[Tobias Klausmann]

Hi! 

On Sat, 16 May 2009, Ciaran McCreesh wrote:

> On Sat, 16 May 2009 18:31:38 +0200
> Tobias Klausmann <klausman@gentoo.org> wrote:
> > On Sat, 16 May 2009, Ciaran McCreesh wrote:
> > > > So we're not talking about .ebuild-2 for EAPI=2, .ebuild-3 for
> > > > EAPI=3 etc? That would just be silly and it was the first idea I
> > > > got when I saw the proposal.
> > > 
> > > Yes, yes we are. That's just one change, from a static string to a
> > > pattern for a string.
> > > 
> > > Heck, pretend GLEP 55 says .eapi-X.eb instead if it makes you happy.
> > 
> > It doesn't. I forsee a non-trivial amount of extra work, breakage
> > and pain with a moving extension. And not anywhere near enough
> > benefit in exchange for it.
> 
> Why? What's the big deal with .ebuild-? or .eapi-?.eb instead
> of .ebuild?

One that you illustrate yourself: what aboud .eapi-11.eb or
.ebuild-11?  What if you want to be able to choos EAPI names more
freely?

> > I think wanting incremental updates for version specs is a dream
> > we should abandon.
> 
> It's an easy goal that we can deliver without much work. Ignoring it,
> on the other hand, means holding Gentoo back unnecessarily every time
> we want to change something.

And on the "without much work" we disagree wildly. I think it
creates more trouble than it's worth. Being an opinion, it's up
for change, naturally.

> > My point is this: from experience I suspect having a hard change
> > once and having easy progress on either side of it is preferable
> > to having mid-range complications all the time.
> 
> .ebuild-? is not complicated.

Oh, it adds a variable portion to something that's otherwise
static. 
            glob        regex
classic   *.ebuild    .*\.ebuild
                      \.ebuild$

pms-style *.ebuild-*  .*\.ebuild-[0-9]+
                      \.ebuild-[0-9]+$

The newer sort of extension is much more involved to get *really*
right in patterns. Globs and regexen are only the two most
popular examples.

On top of that, other domains that are involved with ebuilds will
be more complex (and complicated) by a variable file extension.

And it's not just the command line for users. All code that
handles these files (yet probably doesn't even care about their
contents) needs to become more complex. 

For all those who think they are regex wizzes: create a regex
that can tell properly formatted email-addresses from improper
ones. From scratch; heeding all RFCs. And no googling!

> > > Well, I strongly doubt that anyone's already thought of all the
> > > useful changes we might want to make in the future, so I don't
> > > think proposing a solution that assumes that they have is a good
> > > idea.
> > 
> > I think it's a river we should think about once we reach it.
> 
> Why? We know we'll reach it. Pretending we won't just means when we do
> reach it, we'll still be crossing it on foot rather than in a
> helicopter.

Every metaphor only goes so far, so I'll abandon it for now. When
we reach a point where we will need another change, we can make
an informed decision. Now, we can only guess what might need
change. As such, it's very difficult to create a system of easy
updates that cover all possibilities.

> > > Otherwise, in another year or two we'll just be back to "well we
> > > need to change extensions again, but let's just do it as a second
> > > one-off thing".
> > 
> > My experience tells me that with proper preparation of *this*
> > change, that can be pushed past the "in the next ten years" mark.
> > And that is close enough to "indefinitely" for me. 
> 
> The only way it'll be "in the next ten years" rather than "in the next
> two years" is if Gentoo continues its current approach of making
> changes require every single person to agree...

There is such a things as too much change too quickly. And even
if we take that 2 years number: do *you* know what changes we
might need in two years? I suspect not. Neither do I (or just
about anybody else). I just think the hoops we have to jump
through now to tackle hypothetical problems in two (or ten) years
aren't worth it. 




-- 
Found on a small utility knife in MIT's lab supply:
"Caution.  Blade is sharp.  Keep out of children."

Re: [gentoo-dev] The fallacies of GLEP55

[Ciaran McCreesh]

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

On Sat, 16 May 2009 18:54:41 +0200
Tobias Klausmann <klausman@gentoo.org> wrote:
> > Why? What's the big deal with .ebuild-? or .eapi-?.eb instead
> > of .ebuild?
> 
> One that you illustrate yourself: what aboud .eapi-11.eb or
> .ebuild-11?

Then you include those in your static list not using patterns that
deals with them.

>  What if you want to be able to choos EAPI names more
> freely?

Not a problem. We used .kdebuild-1 rather than .ebuild-kdebuild-1 for
kdebuild, for example.

> > > My point is this: from experience I suspect having a hard change
> > > once and having easy progress on either side of it is preferable
> > > to having mid-range complications all the time.
> > 
> > .ebuild-? is not complicated.
> 
> Oh, it adds a variable portion to something that's otherwise
> static. 
>             glob        regex
> classic   *.ebuild    .*\.ebuild
>                       \.ebuild$
> 
> pms-style *.ebuild-*  .*\.ebuild-[0-9]+
>                       \.ebuild-[0-9]+$
> 
> The newer sort of extension is much more involved to get *really*
> right in patterns. Globs and regexen are only the two most
> popular examples.

You shouldn't be writing anything that even tries to look at any EAPI
you don't support. You should be using a static list of file
extensions, not a pattern.

> > The only way it'll be "in the next ten years" rather than "in the
> > next two years" is if Gentoo continues its current approach of
> > making changes require every single person to agree...
> 
> There is such a things as too much change too quickly. And even
> if we take that 2 years number: do *you* know what changes we
> might need in two years? I suspect not. Neither do I (or just
> about anybody else). I just think the hoops we have to jump
> through now to tackle hypothetical problems in two (or ten) years
> aren't worth it. 

That's my point -- I don't pretend to know what we'll need in the
future, so I don't advocate a solution that requires that we do know.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] The fallacies of GLEP55

[Tobias Klausmann]

Hi! 

On Sat, 16 May 2009, Ciaran McCreesh wrote:
> Tobias Klausmann <klausman@gentoo.org> wrote:
> > > Why? What's the big deal with .ebuild-? or .eapi-?.eb instead
> > > of .ebuild?
> > 
> > One that you illustrate yourself: what aboud .eapi-11.eb or
> > .ebuild-11?
> 
> Then you include those in your static list not using patterns that
> deals with them.

I'm unable to parse this sentence. 

> >  What if you want to be able to choos EAPI names more
> > freely?
> 
> Not a problem. We used .kdebuild-1 rather than .ebuild-kdebuild-1 for
> kdebuild, for example.

Which makes the whole thing more obscure. Are those templates for
proper Ebuilds? Or maybe something KDE invented and accidentally
chose a strange name for? The kdebuild example is of limited use:
very few people outside the original project ever got in contact
with it. That does not hold true for good ol' ebuilds. As such,
the confusiong by the ever-mutation file extension would be much
broader if we did that to the classic portage tree and overlays.

> You shouldn't be writing anything that even tries to look at any EAPI
> you don't support. You should be using a static list of file
> extensions, not a pattern.

Not every piece of code dealing with ebuilds does care about EAPI
/at all/. And it needn't. There is just no way I can do this with
your proposal:

	find /usr/local/portage -iname foobar\*ebuild -print

Or it won't be as easy, at least.

> > There is such a things as too much change too quickly. And even
> > if we take that 2 years number: do *you* know what changes we
> > might need in two years? I suspect not. Neither do I (or just
> > about anybody else). I just think the hoops we have to jump
> > through now to tackle hypothetical problems in two (or ten) years
> > aren't worth it. 
> 
> That's my point -- I don't pretend to know what we'll need in the
> future, so I don't advocate a solution that requires that we do know.

And I don't pretend that I know a way to ensure that the change
will be easy. So I advocate *not* going out of our way to comfort
that possible Mother of All Changes.

Don't get me wrong: I don't want to build format dead-ends into
the package manager design specs, either. But I think the amount
of work and hassle you want to pour into avoiding it outweighs
the benefits, however speculative they may be.

Regards,
Tobias

-- 
Found on a small utility knife in MIT's lab supply:
"Caution.  Blade is sharp.  Keep out of children."

Re: [gentoo-dev] The fallacies of GLEP55

[Ciaran McCreesh]

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

On Sat, 16 May 2009 19:13:21 +0200
Tobias Klausmann <klausman@gentoo.org> wrote:
> > Then you include those in your static list not using patterns that
> > deals with them.
> 
> I'm unable to parse this sentence. 

If you're writing a tool that deals with ebuilds, you should have a
list of EAPIs and their associated file extensions. Any EAPI you don't
explicitly support must be ignored as much as possible.

> > Not a problem. We used .kdebuild-1 rather than .ebuild-kdebuild-1
> > for kdebuild, for example.
> 
> Which makes the whole thing more obscure. Are those templates for
> proper Ebuilds? Or maybe something KDE invented and accidentally
> chose a strange name for? The kdebuild example is of limited use:
> very few people outside the original project ever got in contact
> with it. That does not hold true for good ol' ebuilds. As such,
> the confusiong by the ever-mutation file extension would be much
> broader if we did that to the classic portage tree and overlays.

The kdebuild-1 project was extremely useful in testing out ideas and
driving progress forward. We couldn't have used a regular EAPI number
there for obvious reasons, hence the name.

> > You shouldn't be writing anything that even tries to look at any
> > EAPI you don't support. You should be using a static list of file
> > extensions, not a pattern.
> 
> Not every piece of code dealing with ebuilds does care about EAPI
> /at all/.

But that's not the case, since you don't know anything about EAPIs you
don't recognise.

> And it needn't. There is just no way I can do this with
> your proposal:
> 
> 	find /usr/local/portage -iname foobar\*ebuild -print

You should ask your package manager to give you the information you
require.

> And I don't pretend that I know a way to ensure that the change
> will be easy. So I advocate *not* going out of our way to comfort
> that possible Mother of All Changes.

This isn't some hypothetical possible change thing. We already know a
whole bunch of things that need a change, and it's highly likely we'll
discover more later on.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] The fallacies of GLEP55

[Richard Freeman]

Ciaran McCreesh wrote:
> The only way it'll be "in the next ten years" rather than "in the next
> two years" is if Gentoo continues its current approach of making
> changes require every single person to agree...
> 

Frankly, I won't be at all surprised if this thread (in some form) is 
still going on in the next two years, and nothing at all has been 
implemented.

As far as Gentoo requiring EVERY single person to agree - that is hardly 
the case.  But there does need to be a general consensus or some impetus 
for moving forward without one.  I don't really see either.

If consensus isn't necessary then I'll solve the whole debate for you 
now - EAPI goes on line 5 of the ebuild in the syntax EAPI=foo, and 
filenames remain as they are now.  There we are - done.  Now, lets go 
ahead and start implementing it so that in 6-12 months we can roll out 
new version numbering schemes.  Surely you're not suggesting that we 
shouldn't move forward with this merely because some people (like you) 
don't agree?

Since the inevitable reply is going to be that it isn't about consensus, 
but rather it is about merit - as the official arbiter of all things 
meritorious I hereby declare that my idea is the best one out there.

Now, back in the real world where neither of us is the dictator of 
Gentoo, I'm quite happy to wait for the Council to rule on this, or to 
choose to not rule on this.  Their reluctance to do so to date just 
reflects how divided the developer community is over the issue.

Re: [gentoo-dev] The fallacies of GLEP55

[Arun Raghavan]

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

On Sat, 2009-05-16 at 16:49 +0100, Ciaran McCreesh wrote:
> On Sat, 16 May 2009 17:43:32 +0200
> Tobias Klausmann <klausman@gentoo.org> wrote:
> > > That doesn't let us do version format changes.
> > 
> > Or are we talking about the *ebuild* versions? I see that as
> > different matter. Plus: You could change the version format with
> > the changed extension. I sure do hope there are no plans on
> > making those changes as often as new EAPIs.
> 
> Yes, those. The current rules include some pointless arbitrary
> restrictions that are only there for historical reasons and that mean
> people have to mess with convoluted MY_PV things.

So from all the debate that's going on, the current major issue seems to
be being able to support '-scm' as per GLEP-54. What other restrictions
in the version format are you referring to?

-- Arun

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

Re: [gentoo-dev] The fallacies of GLEP55

[Thomas Anderson]

On Sat, May 16, 2009 at 10:05:08PM +0530, Arun Raghavan wrote:
> On Sat, 2009-05-16 at 16:49 +0100, Ciaran McCreesh wrote:
> > On Sat, 16 May 2009 17:43:32 +0200
> > Tobias Klausmann <klausman@gentoo.org> wrote:
> > > > That doesn't let us do version format changes.
> > > 
> > > Or are we talking about the *ebuild* versions? I see that as
> > > different matter. Plus: You could change the version format with
> > > the changed extension. I sure do hope there are no plans on
> > > making those changes as often as new EAPIs.
> > 
> > Yes, those. The current rules include some pointless arbitrary
> > restrictions that are only there for historical reasons and that mean
> > people have to mess with convoluted MY_PV things.
> 
> So from all the debate that's going on, the current major issue seems to
> be being able to support '-scm' as per GLEP-54. What other restrictions
> in the version format are you referring to?
> 
> -- Arun

For one, there's the restriction that all *-alpha/*-rc has to be
represented _rc/_alpha. I plan on doing more research into perhaps
lifting this restriction in a future EAPI, but this would of course
require glep 55's solution.

-- 
---------
Thomas Anderson
Gentoo Developer
/////////
Areas of responsibility:
AMD64, Secretary to the Gentoo Council
---------

Re: [gentoo-dev] The fallacies of GLEP55

[Arun Raghavan]

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

On Sat, 2009-05-16 at 12:39 -0400, Thomas Anderson wrote:
[...]
> For one, there's the restriction that all *-alpha/*-rc has to be
> represented _rc/_alpha. I plan on doing more research into perhaps
> lifting this restriction in a future EAPI, but this would of course
> require glep 55's solution.

As Tobias stated, I also prefer coming up with solutions to these
problems *now*, and fixing them, rather than implementing (IMO) a fugly
solution to make solving potential problems that we don't know exist
easier.

-- Arun

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

Re: [gentoo-dev] The fallacies of GLEP55

[Ciaran McCreesh]

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

On Sat, 16 May 2009 22:14:30 +0530
Arun Raghavan <ford_prefect@gentoo.org> wrote:
> On Sat, 2009-05-16 at 12:39 -0400, Thomas Anderson wrote:
> > For one, there's the restriction that all *-alpha/*-rc has to be
> > represented _rc/_alpha. I plan on doing more research into perhaps
> > lifting this restriction in a future EAPI, but this would of course
> > require glep 55's solution.
> 
> As Tobias stated, I also prefer coming up with solutions to these
> problems *now*, and fixing them, rather than implementing (IMO) a
> fugly solution to make solving potential problems that we don't know
> exist easier.

Ok, what are all the things requiring format-break changes that we'll
want in the next ten years? Please provide a complete list.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] The fallacies of GLEP55

[Arun Raghavan]

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

On Sat, 2009-05-16 at 17:47 +0100, Ciaran McCreesh wrote:
> 
> Ok, what are all the things requiring format-break changes that we'll
> want in the next ten years? Please provide a complete list.

Don't care. Let's fix the problems we have *now* using solutions that we
can agree upon, rather than try to foist solutions that a reasonably
large population of developers *don't* like (even after extended debate)
to solve problems that don't exist yet.

-- Arun

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

Re: [gentoo-dev] The fallacies of GLEP55

[Ciaran McCreesh]

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

On Sat, 16 May 2009 22:24:04 +0530
Arun Raghavan <ford_prefect@gentoo.org> wrote:
> On Sat, 2009-05-16 at 17:47 +0100, Ciaran McCreesh wrote:
> > Ok, what are all the things requiring format-break changes that
> > we'll want in the next ten years? Please provide a complete list.
> 
> Don't care. Let's fix the problems we have *now* using solutions that
> we can agree upon, rather than try to foist solutions that a
> reasonably large population of developers *don't* like (even after
> extended debate) to solve problems that don't exist yet.

No, let's fix it so we don't have to do the whole thing again in
another year or two.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] The fallacies of GLEP55

[Arun Raghavan]

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

On Sat, 2009-05-16 at 17:59 +0100, Ciaran McCreesh wrote:
[...]
> > Don't care. Let's fix the problems we have *now* using solutions that
> > we can agree upon, rather than try to foist solutions that a
> > reasonably large population of developers *don't* like (even after
> > extended debate) to solve problems that don't exist yet.
> 
> No, let's fix it so we don't have to do the whole thing again in
> another year or two.

I see nothing about the current problem that merits the fooling around
with the ebuild extension. I've listened to and considered all the
arguments that have been made, and I still stand by my opinion that it
an unclean solution (meaning, we don't need to rehash those arguments
again here).

Bottom line, we (everyone who has been on this discussion from the
beginning) disagree. Just as we did a year ago. Standing steadfast on
the filename extension just means that all the version format problems
that you're trying to solve are going to stand blocked because of it.

I think it makes far more sense to work towards agreeing on a solution
rather than restating the same arguments every 6 months and reaching the
same impasse.

-- Arun

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

Re: [gentoo-dev] The fallacies of GLEP55

[Ciaran McCreesh]

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

On Sat, 16 May 2009 22:39:46 +0530
Arun Raghavan <ford_prefect@gentoo.org> wrote:
> On Sat, 2009-05-16 at 17:59 +0100, Ciaran McCreesh wrote:
> > > Don't care. Let's fix the problems we have *now* using solutions
> > > that we can agree upon, rather than try to foist solutions that a
> > > reasonably large population of developers *don't* like (even after
> > > extended debate) to solve problems that don't exist yet.
> > 
> > No, let's fix it so we don't have to do the whole thing again in
> > another year or two.
> 
> I see nothing about the current problem that merits the fooling around
> with the ebuild extension. I've listened to and considered all the
> arguments that have been made, and I still stand by my opinion that it
> an unclean solution (meaning, we don't need to rehash those arguments
> again here).

You have yet to provide an alternative for fixing the arbitrary and
pointless version format restrictions that are currently in place.

> I think it makes far more sense to work towards agreeing on a solution
> rather than restating the same arguments every 6 months and reaching
> the same impasse.

We only have one viable solution.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] The fallacies of GLEP55

[Arun Raghavan]

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

On Sat, 2009-05-16 at 18:55 +0100, Ciaran McCreesh wrote:
[...]
> You have yet to provide an alternative for fixing the arbitrary and
> pointless version format restrictions that are currently in place.

Create an EAPI for the required changes, fast track inclusion to a
stable portage.

If this is not viable, make an unrecognised version string cause the
same fallback as an unsupported EAPI => ignore the ebuild. Again, fast
track to stable portage, and not so long after, you're done.

-- Arun

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

Re: [gentoo-dev] The fallacies of GLEP55

[Ciaran McCreesh]

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

On Sun, 17 May 2009 00:42:58 +0530
Arun Raghavan <ford_prefect@gentoo.org> wrote:
> On Sat, 2009-05-16 at 18:55 +0100, Ciaran McCreesh wrote:
> [...]
> > You have yet to provide an alternative for fixing the arbitrary and
> > pointless version format restrictions that are currently in place.
> 
> Create an EAPI for the required changes, fast track inclusion to a
> stable portage.

Can't do that. The package manager has to barf on unrecognised .ebuild
files.

> If this is not viable, make an unrecognised version string cause the
> same fallback as an unsupported EAPI => ignore the ebuild. Again, fast
> track to stable portage, and not so long after, you're done.

Again, no good. First, it means a year or more wait before doing
anything. Second, it removes a whole level of error checking. Third, it
means a package manager can't know what versions are available for a
package without generating metadata for every potential version.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] The fallacies of GLEP55

[Arun Raghavan]

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

On Sat, 2009-05-16 at 20:21 +0100, Ciaran McCreesh wrote:
[...] 
> Can't do that. The package manager has to barf on unrecognised .ebuild
> files.

I assume the reasons are the same as below.

> > If this is not viable, make an unrecognised version string cause the
> > same fallback as an unsupported EAPI => ignore the ebuild. Again, fast
> > track to stable portage, and not so long after, you're done.
> 
> Again, no good. First, it means a year or more wait before doing
> anything. Second, it removes a whole level of error checking. Third, it
> means a package manager can't know what versions are available for a
> package without generating metadata for every potential version.

1) Why a year? I'd say 4-6 months after portage goes stable is fine.

2) Replace the errors with warnings. And these need to exist only at
'repoman manifest' time, so they're not end-user-visible (and don't need
to be).

-- Arun

3) This is again, when the metadata is uncached, which is not the normal
case and can be ignored. And the (minor) performance penalty in the
cached case, if any, is not reason enough to make this change.

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

Re: [gentoo-dev] The fallacies of GLEP55

[Nick Fortino]

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

Ciaran McCreesh wrote:
> On Sat, 16 May 2009 22:39:46 +0530
> Arun Raghavan <ford_prefect@gentoo.org> wrote:
>  
>> On Sat, 2009-05-16 at 17:59 +0100, Ciaran McCreesh wrote:
>>    
>>>> Don't care. Let's fix the problems we have *now* using solutions
>>>> that we can agree upon, rather than try to foist solutions that a
>>>> reasonably large population of developers *don't* like (even after
>>>> extended debate) to solve problems that don't exist yet.
>>>>        
>>> No, let's fix it so we don't have to do the whole thing again in
>>> another year or two.
>>>      
>> I see nothing about the current problem that merits the fooling around
>> with the ebuild extension. I've listened to and considered all the
>> arguments that have been made, and I still stand by my opinion that it
>> an unclean solution (meaning, we don't need to rehash those arguments
>> again here).
>>    
>
> You have yet to provide an alternative for fixing the arbitrary and
> pointless version format restrictions that are currently in place.
>
>
>  

It seems to me that putting the EAPI in a fixed place in the file has
nearly identical freedom as specifying the EAPI in the file name, and
therefore the argument is more philosophical than based upon features.

To be concrete, consider two proposals,
1. For an ebuild wishing to be sourced with EAPI != 0, line 4 shall be
blank and line 5 shall contain the string EAPI="arg", where arg is the
desired EAPI.
2. An ebuild wishing to be sourced with EAPI != 0 shall have the
extension .ebuild-EAPIarg, where arg is the desired EAPI.

Throughout, these shall be referred to as ebuilds of type 1 and 2
respectively.

I claim for any format where the concept of line 4 and line 5 are well
defined and identical across EAPIs, and the EAPI string embeddable in
the file name, these two proposals allow identical expressive power.[1][2]

"Proof":
Given a set of ebuilds of type 1 transform to ebuilds of type 2 as
follows: for every ebuild ${A}.ebuild, look for a blank line 4 and
line 5 with EAPI="arg". If found, move the ebuild to
${A}.ebuild-EAPIarg, and remove lines 4 and 5. Otherwise, move the
file to ${A}.ebuild-EAPI0.

Given a set of ebuilds of type 2 transform to ebuilds of type 1 as
follows: for every ebuild ${A}.ebuild-EAPIarg, insert a blank line 4
and put the string EAPI="arg" on line 5. move the ebuild to
${A}.ebuild. For every ebuild ${A}.ebuild, insert a blank line 4, and
EAPI="0" on line 5.

Such a transformation is possible, given the restrictions on arg, as
well as ebuild format.

Given the further restriction that any algorithm using ebuilds must
behave identically with ebuilds of unspecified EAPI as with ebuilds
with specified EAPI="0" [3], it can easily be seen that the two
transformations are inverses of each other, and that every ebuild of
either type can be transformed. Thus, the above must be a one-to-one
and onto mapping between the two formats. The conclusion is any
algorithm which can be run on a set of ebuilds type 1 has a set of
ebuilds with type 2 and an appropriate algorithm for which identical
results will be produced, and vice versa [4].

Given the above, it should be clear that any argument which states
some future improvement to the ebuild format  will be impossible based
upon making the wrong choice between proposal 1 and proposal 2 must be
invalid, as they have the same expressive power. Note that allowable
algorithms for which the proof works includes caching and version
ordering as well as the simple execution of the ebuild.


Nick Fortino

[1] I further state, philosophically, any formats which have differing
(including non-existent) concepts of line 4 and line 5 should have
different extensions. Proposal 2 takes care of this automatically. For
any format, the desired EAPI should be specifiable within the file in
a manner uniquely determined by the extension of the file, so proposal
1 is also capable of achieving this freedom.

[2] The astute reader may notice that the concept of a blank line is
also needed, and that line 5 must be capable of encoding the desired
data in a way specified by only the extension. To avoid clutter, these
details are located here, but are in fact restrictions made on the
ebuild format.

[3] There are no algorithms I know of which violate this for EAPI="0",
and I would hope that there are no EAPI="0" ebuilds which are broken
by putting this specification explicitly in the file. Similarly, I
would hope that anything in proposal 2 with EAPI="0" which works with
the .ebuild extension works with the .ebuild-EAPI0 extension.
Note that one could dream up algorithms violating this (take the MD5
hash, do something based on this which affects the outcome). Doing
such a thing where the difference would be visible to the user would
be silly. It is mostly irrelevant for this argument anyway, as it only
affects EAPI="0", which nobody will debate both schemes can handle.

[4] If this is unclear, consider the following (inefficient)
construction of a set of ebuilds of type 2 and a corresponding
algorithm, given a set of type 1:
Take the set of ebuilds, transform to type 2; let this be the new set
of ebuilds.
Take the given type 1 algorithm, and produce the modified algorithm as
follows:
Given the type 1 algorithm, take the set of ebuilds of type 2,
transform to type 1, and run the algorithm on the properly formatted
ebuilds.
Our mapping is 1-1 and onto. We are comparing the result of running
the type 1 algorithm directly, and running the type 1 algorithm on the
ebuild having the mapping and it's inverse applied. The result must be
the same for any algorithm satisfying our restrictions.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkoPTrwACgkQRQqsawN7JJSefwCaAunc1F/iGV0FITN9W8EwUZkZ
vHQAoIbcbl4cIwjWjeILSfpSFj5yG17Z
=DVZJ
-----END PGP SIGNATURE-----

Re: [gentoo-dev] The fallacies of GLEP55

[Ciaran McCreesh]

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

On Sat, 16 May 2009 16:39:40 -0700
Nick Fortino <nfortino@gmail.com> wrote:
> Given the above, it should be clear that any argument which states
> some future improvement to the ebuild format  will be impossible based
> upon making the wrong choice between proposal 1 and proposal 2 must be
> invalid, as they have the same expressive power. Note that allowable
> algorithms for which the proof works includes caching and version
> ordering as well as the simple execution of the ebuild.

Unfortunately, your argument is entirely wrong, as can be illustrated
by a simple counter-example that you would already know about, had you
read the GLEP or the thread.

With EAPI in a fixed format, it is impossible to allow extensions to the
version format in future EAPIs. Even given a fixed format and a constant
extension, adding foo-1.23-rc1.ebuild will cause breakage, but adding
foo-1.23-rc1.ebuild-4 will not.

This has already been covered at length, and is explained in the GLEP.
Why did you disregard this when posting your 'proof'?

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] The fallacies of GLEP55

[Nick Fortino]

Ciaran McCreesh wrote:
> On Sat, 16 May 2009 16:39:40 -0700
> Nick Fortino <nfortino@gmail.com> wrote:
>   
>> Given the above, it should be clear that any argument which states
>> some future improvement to the ebuild format  will be impossible based
>> upon making the wrong choice between proposal 1 and proposal 2 must be
>> invalid, as they have the same expressive power. Note that allowable
>> algorithms for which the proof works includes caching and version
>> ordering as well as the simple execution of the ebuild.
>>     
>
> Unfortunately, your argument is entirely wrong, as can be illustrated
> by a simple counter-example that you would already know about, had you
> read the GLEP or the thread.
>
> With EAPI in a fixed format, it is impossible to allow extensions to the
> version format in future EAPIs. Even given a fixed format and a constant
> extension, adding foo-1.23-rc1.ebuild will cause breakage, but adding
> foo-1.23-rc1.ebuild-4 will not.
>
> This has already been covered at length, and is explained in the GLEP.
> Why did you disregard this when posting your 'proof'?
>
>   
I didn't intentionally disregard that case, but I see your point. I made
the assumption that package mangers wouldn't try to source ebuilds with
a sourcing EAPI they didn't understand. I concede this is a terrible
assumption, unless such a thing is specified in the PMS itself. It is
still fixed by a single extension change, as opposed to a whole set.
Once this is done, simply state that all package managers should ignore
EAPIs they don't understand (a requirement of GLEP-55 as well).

Your point still does not dispute that specifying the EAPI within the
ebuild and outside the ebuild convey identical information (this is all
I was trying to prove in the first place). For the case you bring up:
If foo-1.23-rc1.ebuild is added, it must not be in any of the currently
existing EAPIs, for if it were, it would be illegal. Thus, a package
manager would open this file, get the sourcing EAPI in an EAPI
independent way, realize it doesn't understand, and abort the sourcing
of that ebuild. Changing the extension once insures current package
managers don't try to do things they aren't capable of (I apologize for
not putting this in my first mailing). Given this change, however, I
still assert the statement of the two schemes have identical expressive
power.

For versioning, it has been pointed out (by you and others) that getting
the latest version would require, under any implementation, opening N
files in case 1, and reading N file names in case 2. I do not dispute
this in any way. Instead, I would like to point out that moving the
argument from features which are possible to support (which I still
contend are essentially identical), to efficiency vs. a perceived
prettiness would be significant progress. Indeed, at this point it would
be possible to make a decision based on reference implementations for
known common use cases, and an executive council decision about whether
timing or extension consistency is more important. If it turns out that
using a solution of type 1 takes minutes to resolve versions, than by
all means, GLEP-55 is by far the best proposed solution. If, instead,
the runtime difference in real use cases is negligible, then the pure
philosophical arguments for using a single extension holds true (in my
opinion).

Nick Fortino

Re: [gentoo-dev] The fallacies of GLEP55

[Robert R. Russell]

On Saturday 16 May 2009 20:17:14 Nick Fortino wrote:
> Ciaran McCreesh wrote:
> > On Sat, 16 May 2009 16:39:40 -0700
> >
> > Nick Fortino <nfortino@gmail.com> wrote:
> >> Given the above, it should be clear that any argument which states
> >> some future improvement to the ebuild format  will be impossible based
> >> upon making the wrong choice between proposal 1 and proposal 2 must be
> >> invalid, as they have the same expressive power. Note that allowable
> >> algorithms for which the proof works includes caching and version
> >> ordering as well as the simple execution of the ebuild.
> >
> > Unfortunately, your argument is entirely wrong, as can be illustrated
> > by a simple counter-example that you would already know about, had you
> > read the GLEP or the thread.
> >
> > With EAPI in a fixed format, it is impossible to allow extensions to the
> > version format in future EAPIs. Even given a fixed format and a constant
> > extension, adding foo-1.23-rc1.ebuild will cause breakage, but adding
> > foo-1.23-rc1.ebuild-4 will not.
> >
> > This has already been covered at length, and is explained in the GLEP.
> > Why did you disregard this when posting your 'proof'?
>
> I didn't intentionally disregard that case, but I see your point. I made
> the assumption that package mangers wouldn't try to source ebuilds with
> a sourcing EAPI they didn't understand. I concede this is a terrible
> assumption, unless such a thing is specified in the PMS itself. It is
> still fixed by a single extension change, as opposed to a whole set.
> Once this is done, simply state that all package managers should ignore
> EAPIs they don't understand (a requirement of GLEP-55 as well).
>
> Your point still does not dispute that specifying the EAPI within the
> ebuild and outside the ebuild convey identical information (this is all
> I was trying to prove in the first place). For the case you bring up:
> If foo-1.23-rc1.ebuild is added, it must not be in any of the currently
> existing EAPIs, for if it were, it would be illegal. Thus, a package
> manager would open this file, get the sourcing EAPI in an EAPI
> independent way, realize it doesn't understand, and abort the sourcing
> of that ebuild. Changing the extension once insures current package
> managers don't try to do things they aren't capable of (I apologize for
> not putting this in my first mailing). Given this change, however, I
> still assert the statement of the two schemes have identical expressive
> power.
>
> For versioning, it has been pointed out (by you and others) that getting
> the latest version would require, under any implementation, opening N
> files in case 1, and reading N file names in case 2. I do not dispute
> this in any way. Instead, I would like to point out that moving the
> argument from features which are possible to support (which I still
> contend are essentially identical), to efficiency vs. a perceived
> prettiness would be significant progress. Indeed, at this point it would
> be possible to make a decision based on reference implementations for
> known common use cases, and an executive council decision about whether
> timing or extension consistency is more important. If it turns out that
> using a solution of type 1 takes minutes to resolve versions, than by
> all means, GLEP-55 is by far the best proposed solution. If, instead,
> the runtime difference in real use cases is negligible, then the pure
> philosophical arguments for using a single extension holds true (in my
> opinion).
>
> Nick Fortino

And we could probably switch between types if forced to do so.

Re: [gentoo-dev] The fallacies of GLEP55

[Ravi Pinjala]

Nick Fortino wrote:
> Such a transformation is possible, given the restrictions on arg, as
> well as ebuild format.

Isn't this a bit circular? The whole point of wanting to change the
extension is to get rid of exactly these restrictions; if you assume the
restrictions, then the whole thing is kind of pointless. :)

--Ravi

Re: [gentoo-dev] The fallacies of GLEP55

[Richard Freeman]

Ravi Pinjala wrote:
> Nick Fortino wrote:
>> Such a transformation is possible, given the restrictions on arg, as
>> well as ebuild format.
> 
> Isn't this a bit circular? The whole point of wanting to change the
> extension is to get rid of exactly these restrictions; if you assume the
> restrictions, then the whole thing is kind of pointless. :)
> 

What restrictions?  The restriction that EAPI be fixed on the 5th line 
of the build, or the restriction that EAPI be fixed in the filename.  I 
don't really see much difference between them.  What can the one do that 
the other can't.

The only thing that has been suggested is changing the package 
versioning scheme.  That is handled in a straightforward way - parse the 
EAPI before you try to extract the version from the filename.  Sure, 
that isn't compatible with older versions of portage, but if we start 
now I'm sure we can get there in the reasonably near future.

Personally, I'm not a fan of parsing ANYTHING out of the filename. 
Sure, keep the file naming convention for the sake of convenience, but I 
think a better design would be to field everything inside the file - 
including category, packagename, and version.  Then you no longer have 
to worry about whether a given hyphen is a separator or part of one of 
the components (among other things).  Sure, you can't just bump an 
ebuild by renaming it, but if we had been doing it this way all along 
then the versioning issue we're debating now would be a non-issue.

Re: [gentoo-dev] The fallacies of GLEP55

[Thomas Anderson]

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

On Sun, May 17, 2009 at 12:35:43AM -0400, Richard Freeman wrote:
> Ravi Pinjala wrote:
>> Nick Fortino wrote:
>>> Such a transformation is possible, given the restrictions on arg, as
>>> well as ebuild format.
>> Isn't this a bit circular? The whole point of wanting to change the
>> extension is to get rid of exactly these restrictions; if you assume the
>> restrictions, then the whole thing is kind of pointless. :)
>
> What restrictions?  The restriction that EAPI be fixed on the 5th line of 
> the build, or the restriction that EAPI be fixed in the filename.  I don't 
> really see much difference between them.  What can the one do that the 
> other can't.

The difference is that putting the EAPI in the filename has backwards
compatibility because package managers not knowing about this change
won't even look at the those ebuilds. Putting EAPI as the fifth line
completely loses this, so as far as backwards compatibility goes putting
EAPI 55 in the filename really is the cleanest.

-- 
---------
Thomas Anderson
Gentoo Developer
/////////
Areas of responsibility:
AMD64, Secretary to the Gentoo Council
---------

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

Re: [gentoo-dev] The fallacies of GLEP55

[Arun Raghavan]

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

On Sun, 2009-05-17 at 07:40 -0400, Thomas Anderson wrote:
[...]
> The difference is that putting the EAPI in the filename has backwards
> compatibility because package managers not knowing about this change
> won't even look at the those ebuilds. Putting EAPI as the fifth line
> completely loses this, so as far as backwards compatibility goes putting
> EAPI 55 in the filename really is the cleanest.

That's not very hard to overcome without polluting the file name, as
I've already pointed out.

-- Arun

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

[gentoo-dev] Re: The fallacies of GLEP55

[Duncan]

Nick Fortino <nfortino@gmail.com> posted 4A0F4EBC.5020706@gmail.com,
excerpted below, on  Sat, 16 May 2009 16:39:40 -0700:

> line 5 shall contain the string EAPI="arg"

Given the bash expansion properties associated with double-quotes, that's 
not really going to work as such.  What if "arg" contains $var, where 
$var is set in either line 3 or the environment?  Now a bash parsing 
results in something far different than the literal string.  Now that 
could be simply restricted out, or the more literal single-quote can be 
chosen instead.  That saves a lot of headaches right there.


As for ciaranm's argument that you're restricting changes to the version 
string, say allowing -rc where _rc is now required, one-time restriction 
of a year or two, yes.  However, if the spec is crafted such that the 
EAPI must be checked FIRST, then after the waiting period, changes in 
version-string in the filename should be allowed, because the magic 
string checking (lines 4 and 5 in your example) can then be relied upon 
to be verified FIRST (well, check the extension, ebuild, without checking 
the rest of the filename, THEN check EAPI, which gives rules for the 
rest, including the rest of the filename), setting the parameters for 
further parsing, including of the filename version-string.  That year or 
two one-time wait could be avoided with a single one-time extension 
change instead, if desired.

-- 
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: The fallacies of GLEP55

[Ciaran McCreesh]

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

On Sun, 17 May 2009 00:35:45 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:
> As for ciaranm's argument that you're restricting changes to the
> version string, say allowing -rc where _rc is now required, one-time
> restriction of a year or two, yes.  However, if the spec is crafted
> such that the EAPI must be checked FIRST

...then the package manager has to inspect the metadata for every
version of a package before it can do anything, rather than just
starting at the best version and working downwards until it finds
something usable, which is a pretty hefty price to pay.

-- 
Ciaran McCreesh

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

[gentoo-dev] Re: The fallacies of GLEP55

[Duncan]

Ciaran McCreesh <ciaran.mccreesh@googlemail.com> posted
20090517015039.2fa0468a@snowmobile, excerpted below, on  Sun, 17 May 2009
01:50:39 +0100:

> On Sun, 17 May 2009 00:35:45 +0000 (UTC) Duncan <1i5t5.duncan@cox.net>
> wrote:
>> As for ciaranm's argument that you're restricting changes to the
>> version string, say allowing -rc where _rc is now required, one-time
>> restriction of a year or two, yes.  However, if the spec is crafted
>> such that the EAPI must be checked FIRST
> 
> ...then the package manager has to inspect the metadata for every
> version of a package before it can do anything, rather than just
> starting at the best version and working downwards until it finds
> something usable, which is a pretty hefty price to pay.

I'd argue that uncached, certainly, it's a heavy price to pay, tho that's 
so slow as to be hardly workable anyway.

Cached, however, while it's certainly a bit of an increase over the 
current price, I don't believe it inordinately so.  Given that for EAPIs 
the PM doesn't understand it bales anyway, ignoring them, and that EAPI 
is defined as FIRST to be determined, it's an early-out in the can't-deal-
with-it case, and scaled against dependency calculation, grabbing the 
EAPI and establishing a proper ordering shouldn't be /that/ much of a 
cost increase, particularly when the alternative is establishing an 
order, then finding we can't deal with the EAPI of the top of the list 
anyway, so we have to reject it.  It's simply putting EAPI rejection 
earlier in the sequence, dealing with that before establishing order and 
immediately rejecting what we can't handle, rather than establishing 
order first, then checking EAPI and possibly rejecting some versions.

So I believe the cost to be quite reasonably managed, after all.  
Benchmarks would of course be needed to demonstrate that, but I believe 
it worth pursuing.

-- 
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: The fallacies of GLEP55

[Richard Freeman]

Duncan wrote:
> So I believe the cost to be quite reasonably managed, after all.  
> Benchmarks would of course be needed to demonstrate that, but I believe 
> it worth pursuing.
> 

Agreed.  Perhaps I'm just spoiled by RDBMS's at work or something, but 
it seems like we're trying to squeeze every ounce of speed out of a 
non-indexed flat file database and do everything we can to avoid 
actually putting all that metadata in something that actually is 
queryable no matter how lousy the final design ends up being.

Expressing the package database as a set of flat files works nicely - 
especially with cvs/git/etc.  Actually working with that data directly 
on a real system doesn't make sense at all.  Index it once and then only 
open the flat files on the rare occasion that you actually need to 
install one of them.  Such an index can be centrally distributed, or it 
could be maintained as packages are rsynced (and of course users should 
be able to update it on demand as well).

When the speed of your package management system depends on the 
performance of find vs grep -r, you are doing something wrong.  Neither 
works all that well.

Re: [gentoo-dev] Re: The fallacies of GLEP55

[Patrick Lauer]

On Sunday 17 May 2009 06:43:50 Richard Freeman wrote:
> Duncan wrote:
> > So I believe the cost to be quite reasonably managed, after all.
> > Benchmarks would of course be needed to demonstrate that, but I believe
> > it worth pursuing.
I thought we had agreed that (1) with GLEP55 you have to source the ebuild 
anyway (whereas the other proposal allows to just parse it to get at the EAPI 
value) and (2) you can cache it sanely so that performance isn't the issue?

> Agreed.  Perhaps I'm just spoiled by RDBMS's at work or something, but
> it seems like we're trying to squeeze every ounce of speed out of a
> non-indexed flat file database and do everything we can to avoid
> actually putting all that metadata in something that actually is
> queryable no matter how lousy the final design ends up being.

The performance is really not an issue - the current design is quite limited 
and would need some interesting tweaks to go a lot faster.  In terms of 
opening-and-looking-at files GLEP55 doesn't really offer a benefit, either you 
have a metadata cache which includes it (stat for existence of cache, stat for 
mtime of ebuild, open either ebuild or cache, source ebuild if cache is stale) 
or you have it in the filename (either the same sequence of operations if you 
cache it, or you source it because of the current restrictions in glep55)

In other words, looking at performance in this case is just a distraction.

> Expressing the package database as a set of flat files works nicely -
> especially with cvs/git/etc.  Actually working with that data directly
> on a real system doesn't make sense at all.  Index it once and then only
> open the flat files on the rare occasion that you actually need to
> install one of them.  Such an index can be centrally distributed, or it
> could be maintained as packages are rsynced (and of course users should
> be able to update it on demand as well).
That sounds like a funny idea. I propose putting such a cache into 
/usr/portage/metadata/cache and have it contain pregenerated metadata keys, 
like DEPEND, HOMEPAGE and EAPI.

> When the speed of your package management system depends on the
> performance of find vs grep -r, you are doing something wrong.  Neither
> works all that well.
And when the difference is 0.03s out of 0.5s in the hot-cache and 4 seconds 
out of 75 in the cold-cache case you can't really "optimize" anything without 
considering more powerful options to increase performance ...

Re: [gentoo-dev] Re: The fallacies of GLEP55

[David Leverton]

On Sunday 17 May 2009 08:29:31 Patrick Lauer wrote:
> I thought we had agreed that (1) with GLEP55 you have to source the ebuild
> anyway (whereas the other proposal allows to just parse it to get at the
> EAPI value) and (2) you can cache it sanely so that performance isn't the
> issue?

You don't /have/ to source the ebuild to get the EAPI for GLEP 55.  That 
section is only there to cover corner cases that some people wanted to be 
well-defined, and it could easily be removed if the consensus is that that 
isn't a problem.  On the other hand, it could equally well be added to 
whatever alternative solution you might suggest.

Consider the case where you have a foo-1.2.ebuild-4, and in the contents of 
the file it sets EAPI=5.  What should that mean?  There are three 
possibilities that I can think of:

1) It's illegal, don't do that.  Then there's no need to source the file to 
find the EAPI, because the corner case should never happen, and if it does, 
the behaviour can be left undefined.

2) It's legal, and the ebuild has EAPI 4.  Then there's no need to source the 
file to find the EAPI, because the EAPI in the filename always wins.

3) It's legal, and the ebuild has EAPI 5.  This requires sourcing the ebuild 
to find the EAPI, and it's what GLEP 55 currently says.

Now consider the alternative fixed-format "^EAPI=" suggestion.  What if we 
have a foo-1.2.ebuild, that sets EAPI=4 at the top, and then sets EAPI=5 
further down?  What should that mean?  The same three possibilities apply 
here as in the GLEP 55 case.  If you think it should be illegal, or that it 
should mean EAPI=4, then there's no need to source the ebuild just to find 
the EAPI.  If you think it should mean EAPI=5, then you do need to source the 
ebuild, exactly the same as in GLEP 55.

Either way, this isn't a valid reason to choose the fixed-format alternative 
over GLEP 55, because the same concerns do or do not apply to both.

Re: [gentoo-dev] Re: The fallacies of GLEP55

[Tiziano Müller]

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

Am Sonntag, den 17.05.2009, 01:50 +0100 schrieb Ciaran McCreesh:
> On Sun, 17 May 2009 00:35:45 +0000 (UTC)
> Duncan <1i5t5.duncan@cox.net> wrote:
> > As for ciaranm's argument that you're restricting changes to the
> > version string, say allowing -rc where _rc is now required, one-time
> > restriction of a year or two, yes.  However, if the spec is crafted
> > such that the EAPI must be checked FIRST
> 
> ...then the package manager has to inspect the metadata for every
> version of a package before it can do anything, rather than just
> starting at the best version and working downwards until it finds
> something usable, which is a pretty hefty price to pay.
> 

... if the cache can be parsed at all. With GLEP-55 we might even choose
to change the cache format.

-- 
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] Re: The fallacies of GLEP55

[Patrick Lauer]

On Sunday 17 May 2009 09:40:14 Tiziano Müller wrote:
> Am Sonntag, den 17.05.2009, 01:50 +0100 schrieb Ciaran McCreesh:
> > On Sun, 17 May 2009 00:35:45 +0000 (UTC)
> >
> > Duncan <1i5t5.duncan@cox.net> wrote:
> > > As for ciaranm's argument that you're restricting changes to the
> > > version string, say allowing -rc where _rc is now required, one-time
> > > restriction of a year or two, yes.  However, if the spec is crafted
> > > such that the EAPI must be checked FIRST
> >
> > ...then the package manager has to inspect the metadata for every
> > version of a package before it can do anything, rather than just
> > starting at the best version and working downwards until it finds
> > something usable, which is a pretty hefty price to pay.
>
> ... if the cache can be parsed at all. With GLEP-55 we might even choose
> to change the cache format.

We might actually decide to change the cache format with or without GLEP55. 
It's trivial to think of a situation where the cache location is changed so 
that older package managers don't see it at all, thus falling back to the slow 
but reliable sourcing strategy, whereas newer versions are aware of that 
format and will be able to use it.

Please stop mixing issues, it makes it hard to discuss things.

Re: [gentoo-dev] The fallacies of GLEP55

[Ciaran McCreesh]

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

On Sat, 16 May 2009 22:05:08 +0530
Arun Raghavan <ford_prefect@gentoo.org> wrote:
> So from all the debate that's going on, the current major issue seems
> to be being able to support '-scm' as per GLEP-54. What other
> restrictions in the version format are you referring to?

Have a look at every package using a MY_PV style thing. Group those
into "upstream's doing something dumb" and "upstream's being sensible
but our arbitrary restrictions on rules means we can't follow what they
do".

There are an awful lot of things in the second category. There's no
good reason, for example, that _alpha is legal but -alpha is not; both
are common.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] The fallacies of GLEP55

[Robert Buchholz]

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

On Saturday 16 May 2009, Ciaran McCreesh wrote:
> Have a look at every package using a MY_PV style thing. Group those
> into "upstream's doing something dumb" and "upstream's being sensible
> but our arbitrary restrictions on rules means we can't follow what
> they do".

I like the fact that our versioning rules are a fixed subset of the sum 
of all our upstream's versioning rules. It provides a more consistent 
user experience.
As a user, I know it's always "_rc" and never "-rc". Gentoo developers 
take care of mapping all upstream versions onto an easy-to-remember set 
of ebuild versions.

The file extension change makes changing versioning rules possible. From 
a developer PoV, this might relieve me from fiddling with MY_PV. 
However, I have to take care of additional fuzz with file extensions 
(As pointed out by klausman).

Bottom line: I see no gain for me as a developer, and a loss of
consistency for users.


Robert

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

Re: [gentoo-dev] The fallacies of GLEP55

[Ciaran McCreesh]

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

On Sat, 16 May 2009 20:38:30 +0200
Robert Buchholz <rbu@gentoo.org> wrote:
> I like the fact that our versioning rules are a fixed subset of the
> sum of all our upstream's versioning rules. It provides a more
> consistent user experience.
>
> As a user, I know it's always "_rc" and never "-rc". Gentoo
> developers take care of mapping all upstream versions onto an
> easy-to-remember set of ebuild versions.

As a user, you don't need to worry. Since 1-rc1 and 1_rc1 would be
defined as equivalent, as a user you can use either and get the same
results. This is already how things work for existing equivalent but
not stringwise-equal versions.

> Bottom line: I see no gain for me as a developer, and a loss of
> consistency for users.

The only impact upon users is that the package manager will be more
likely to give them accurate output when showing versions.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] The fallacies of GLEP55

[Marijn Schouten (hkBst)]

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

Ciaran McCreesh wrote:
> On Fri, 15 May 2009 14:43:29 -0500
> William Hubbs <williamh@gentoo.org> wrote:
>> On Thu, May 14, 2009 at 10:53:37PM +0100, Ciaran McCreesh wrote:
>>> It can't, because it doesn't know the EAPI until it's sourced the
>>> thing using bash. Using things like += in global scope will break
>>> older bash versions to the point that they can't reliably extract
>>> EAPI.
>>  
>> I just figured out a line in bash that will get an EAPI without
>> sourcing the ebuild:
>>
>> eval `grep '^EAPI=' ebuildfile | head -n 1`
>>
>> will set EAPI in the current scope to EAPI in the ebuild, without
>> sourcing it, unless the issue with something like this would be its
>> use of grep and head, but these are both in the system set, so unless
>> you don't want to depend on the system set, I don't know what the
>> objection would be.
> 
> The objection is that your code doesn't work. It's entirely legal to
> do, say:
> 
>     export EAPI="1"
> 
> or:
> 
>     inherit versionator
> 
>     if version_is_at_least 2 ; then
>         EAPI="2"
>     else
>         EAPI="0"
>     fi
> 
> Besides, if we were able to do what your code does, we'd just code it
> natively, not use external programs.

How is it possible to do these things encoded in the filename?

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

iEYEARECAAYFAkoOhxcACgkQp/VmCx0OL2wXqACfSkZVqv2hcskm7Yw7vyizeh5r
UnIAn1npT5j6CcN23WE3yG6p8WDZiF9D
=bI9e
-----END PGP SIGNATURE-----

Re: [gentoo-dev] The fallacies of GLEP55

[David Leverton]

On Saturday 16 May 2009 10:27:51 Marijn Schouten (hkBst) wrote:
> How is it possible to do these things encoded in the filename?

For the export example, it's just a matter of using a different bash syntax 
from what the magic regex expects, which is completely irrelevant if it goes 
in the filename instead.  For the versionator one, you would change the 
extension at the same time that you changed the version, removing the need to 
modify the file contents.

But the point isn't that we want to be able to do those things.  The point is 
that if the EAPI is in the filename, it's blatantly obvious that it has to be 
static, but adding strange and unintuitive restrictions on which shell 
constructs can be used is, well, strange and unintuitive.

Re: [gentoo-dev] The fallacies of GLEP55

[Ben de Groot]

David Leverton wrote:
> But the point isn't that we want to be able to do those things.  The point is 
> that if the EAPI is in the filename, it's blatantly obvious that it has to be 
> static, but adding strange and unintuitive restrictions on which shell 
> constructs can be used is, well, strange and unintuitive.

Except that we aren't talking about strange and unintuitive. All we are
saying is basically documenting current usage: put a line with EAPI=
near the top. That's very straighforward and intuitive. Plus, it works.

Cheers,
-- 
Ben de Groot
Gentoo Linux developer (qt, media, lxde, desktop-misc)
Gentoo Linux Release Engineering PR liaison
______________________________________________________

Re: [gentoo-dev] The fallacies of GLEP55

[William Hubbs]

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

On Sat, May 16, 2009 at 01:11:34PM +0200, Ben de Groot wrote:
> David Leverton wrote:
> > But the point isn't that we want to be able to do those things.  The point is 
> > that if the EAPI is in the filename, it's blatantly obvious that it has to be 
> > static, but adding strange and unintuitive restrictions on which shell 
> > constructs can be used is, well, strange and unintuitive.
> 
> Except that we aren't talking about strange and unintuitive. All we are
> saying is basically documenting current usage: put a line with EAPI=
> near the top. That's very straighforward and intuitive. Plus, it works.

Agreed.  The way I have always usedEAPI is, you set it once at the top
of the EBUILD and you are done with it.  As far as I know, there is no
reason to change EAPI once it is set, and eclasses shouldn't be changing
it.

- -- 
William Hubbs
gentoo accessibility team lead
williamh@gentoo.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkoPAX8ACgkQblQW9DDEZTizJACfarJ8hZh4WQ7GC0kuraqTba9u
FhkAn29jolc1O5D/jMWWA6TJaJcUZtbQ
=529O
-----END PGP SIGNATURE-----

Re: [gentoo-dev] The fallacies of GLEP55

[Ciaran McCreesh]

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

On Sat, 16 May 2009 13:10:07 -0500
William Hubbs <williamh@gentoo.org> wrote:
> Agreed.  The way I have always usedEAPI is, you set it once at the top
> of the EBUILD and you are done with it.  As far as I know, there is no
> reason to change EAPI once it is set, and eclasses shouldn't be
> changing it.

But eclasses have tried changing it. This is something people have
done, not some hypothetical.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] The fallacies of GLEP55

[William Hubbs]

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

On Sat, May 16, 2009 at 07:14:00PM +0100, Ciaran McCreesh wrote:
> On Sat, 16 May 2009 13:10:07 -0500
> William Hubbs <williamh@gentoo.org> wrote:
> > Agreed.  The way I have always usedEAPI is, you set it once at the top
> > of the EBUILD and you are done with it.  As far as I know, there is no
> > reason to change EAPI once it is set, and eclasses shouldn't be
> > changing it.
> 
> But eclasses have tried changing it. This is something people have
> done, not some hypothetical.
 
 I see that as an issue with those eclasses then; they need to be fixed
 so they don't change the EAPI.  They can test for it, but that is all
 they should do.  Maybe that needs to be documented somewhere if it
 isn't already.


- -- 
William Hubbs
gentoo accessibility team lead
williamh@gentoo.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkoPBGAACgkQblQW9DDEZThZ8ACdHK+5d2xjzAONo/IcuVPR3D5j
rTkAoLm4c3o7IVxh2kq3SD8aTUaB4ROb
=NjOq
-----END PGP SIGNATURE-----

[gentoo-dev] Re: The fallacies of GLEP55

[Duncan]

David Leverton <levertond@googlemail.com> posted
200905161059.53706.levertond@googlemail.com, excerpted below, on  Sat, 16
May 2009 10:59:53 +0100:

> But the point isn't that we want to be able to do those things.  The
> point is that if the EAPI is in the filename, it's blatantly obvious
> that it has to be static, but adding strange and unintuitive
> restrictions on which shell constructs can be used is, well, strange and
> unintuitive.

Has it really come down to this?

I mean, for the longest time, the main (among many) boosting claim seemed 
to be that the speed difference between in-file and in-filename made the 
former prohibitive in practice.  Perhaps the benchmarks the council asked 
for are disproving this.  I don't know but I know I sure see a lot less 
of that claim, call it a deemphasis if you will, now, only that the 
filename method (i.e. glep55) isn't slower. <shrug>

Now, the main argument seems to be that glep55 filename based eapis are 
"more intuitive".  

The argument was originally made that a simple highly specified EAPI= 
declaration in the file itself was too restrictive of all the ways it 
could be specified now -- until it began to be pointed out every time the 
argument was made that the filename method was very similarly 
restricted.  

Now that argument has been debunked and no longer works as it did, so it 
seems the reasons now being presented are what they have left, that the 
filename restriction is "blatantly obvious", while the in-file EAPI= 
restrictions are "unintuitive".

I'd argue no, it's no more unintuitive than any other format definition 
choice.  It's the basic format definition, using the long accepted method 
of "magic values" at a "magic location" to define the format version.  
That's very basic definitional, restricted only to the degree necessary 
for practical application of the definition.  Therefore, it's not 
unintuitive, or at least, certainly no more so than arbitrarily defining 
it to be in the filename instead, because "intuitive" now gets defined by 
the format definition at an extremely basic level, well below the level 
at which all the "intuitive or not" fancy stuff gets addressed.

Regardless, the practical effect is the same, (relatively) severe 
restrictions from the extremely loose definition we have now.  The 
restrictions are even similar.  Thus, it's only an argument over how 
"intuitive" it is, and, well, a stable "base" definition that's 
unchanging is certainly going to look more "intuitive" than say, what 
features are in each EAPI, the much more difficult and "unintuitive" 
thing devs are already trying to track.

Anyway, if it has come down to arguing how intuitive the two opposing 
options may be, that's GOOD news indeed!  It means the important 
questions are, one way or another, getting resolved.  After that, 
ultimately, it's a council judgment call, and we're actually getting 
close!

Unfortunately, "close" is a relative term. =:^(  Realistically?
I'm not sure it's going to resolve by the end of this council's term, but 
provided the elections don't shake things up too badly, it actually looks 
possible to do so reasonably within the /next/ council's term.  We've 
never actually had it (realistically) that close before!

-- 
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: The fallacies of GLEP55

[Ciaran McCreesh]

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

On Sat, 16 May 2009 12:14:23 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:
> I mean, for the longest time, the main (among many) boosting claim
> seemed to be that the speed difference between in-file and
> in-filename made the former prohibitive in practice.  Perhaps the
> benchmarks the council asked for are disproving this.  I don't know
> but I know I sure see a lot less of that claim, call it a deemphasis
> if you will, now, only that the filename method (i.e. glep55) isn't
> slower. <shrug>

Uhm. No it hasn't. That is completely and utterly wrong.

The main argument has always been that it's the only solution that
allows the full variety of changes.

The performance thing is a side note on a sub argument that's got
nothing to do with the main point. Unfortunately, since GLEP 55 is
clearly the only answer when you consider the variety of changes
argument, people refuse to talk about it.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Re: The fallacies of GLEP55

[David Leverton]

On Saturday 16 May 2009 13:14:23 Duncan wrote:
> I mean, for the longest time, the main (among many) boosting claim seemed
> to be that the speed difference between in-file and in-filename made the
> former prohibitive in practice.

No, performance was never the point of GLEP 55.  People like to talk about it 
because, as we all know, Gentoo is for ricers, but it's not relevant and 
never has been, except to the extent that we don't want to make performance 
worse than it is now.

> The argument was originally made that a simple highly specified EAPI=
> declaration in the file itself was too restrictive of all the ways it
> could be specified now -- until it began to be pointed out every time the
> argument was made that the filename method was very similarly
> restricted.

No, no-one has ever claimed that the restricted EAPI= method is bad because 
they /want/ to be able to set it using weird bash tricks.  The problem is 
that, if it appears as a bash assignment you /can/ set it using weird bash 
tricks, and making the PM's own parsing accept a subset of what can happen 
when the ebuild /is/ eventually sourced is going to make a mess.

> I'd argue no, it's no more unintuitive than any other format definition
> choice.  It's the basic format definition, using the long accepted method
> of "magic values" at a "magic location" to define the format version.
> That's very basic definitional, restricted only to the degree necessary
> for practical application of the definition.  Therefore, it's not
> unintuitive, or at least, certainly no more so than arbitrarily defining
> it to be in the filename instead, because "intuitive" now gets defined by
> the format definition at an extremely basic level, well below the level
> at which all the "intuitive or not" fancy stuff gets addressed.

"The format definition at an extremely basic level" is bash, which has no such 
restrictions.

For comparson, another alternative that some people have suggested is putting 
it in a specially formatted comment.  This avoids the issue I mentioned 
because bash doesn't try to parse those at all, so the only rules are those 
that specify what format the comment should be in.  On the other hand, this 
isn't backwards compatible with current package managers.

Re: [gentoo-dev] Re: The fallacies of GLEP55

[Joe Peterson]

David Leverton wrote:
> For comparson, another alternative that some people have suggested is putting 
> it in a specially formatted comment.  This avoids the issue I mentioned 
> because bash doesn't try to parse those at all, so the only rules are those 
> that specify what format the comment should be in.  On the other hand, this 
> isn't backwards compatible with current package managers.

Actually, I prefer the out-of-band approach, as well.  She-bangs are
pretty standard in Linux/Unix (for example).  But either out-of-band or
restricted in-band solutions are preferable to filename extension hacks.

						-Joe

Re: [gentoo-dev] Re: The fallacies of GLEP55

[Denis Dupeyron]

Joe !

How are you doing ? I've been meaning to call you but I've been busy
as hell due to the move. Do you want to have a beer or lunch sometime
?

Denis.

Re: [gentoo-dev] Re: The fallacies of GLEP55

[Denis Dupeyron]

Oops, that was supposed to be sent to him directly. Sorry about that.

Denis.

On Sat, May 16, 2009 at 2:11 PM, Denis Dupeyron <calchan@gentoo.org> wrote:
> Joe !
>
> How are you doing ? I've been meaning to call you but I've been busy
> as hell due to the move. Do you want to have a beer or lunch sometime
> ?
>
> Denis.
>

Re: [gentoo-dev] The fallacies of GLEP55

[Alistair Bush]

Ben de Groot wrote:
> Patrick Lauer wrote:
>> For quite some time (over a year, actually) we've been discussing the
>> mysterious and often misunderstood GLEP55. 
>> [http://www.gentoo.org/proj/en/glep/glep-0055.html]
>>
>> The proposed solution to a problem that is never refined, 
> 
> This, in my opinion, is the crux of the matter. Most of us apparently
> are not sufficiently convinced that there actually is a problem. Until
> the problem is explained with clarity, the rest of the proposal is useless.
> 
>> "Obviously you don't understand the issue, because if you did you'd support 
>> it!"
> 
> I concur that speaking for myself, I don't understand the issue. And it
> looks like many others don't either. So if anyone wants to promote this
> GLEP, their job is clear: make people understand what the issue is here,
> and convince them it is actually an issue. (Examples, scenarios usually
> work well, indeed a lot better than calling people names.)

Is it really necessary to convince the entire community for every GLEP?
 I thought that the reason we have the council is so they can make
decisions. You know specialization of decision making.  If the council
is going to expect anyone else, besides themselves, to understand an
issue then why have the council.

> 
>> And maybe we can now spend the same amount of
>> council-time (it has been eating time for over a year!) to get important 
>> things done ...
> 
> I want to call on the Council to reject this GLEP in its current form,
> as the problem has been insufficiently clarified. We should not waste
> more time on it.

I would like the Council to either accept, reject or send the GLEP back
to be clarified if _THEY_ believe it has been insufficiently clarified
to enable _THEM_ to understand the GLEP.

> 
> Cheers,

Re: [gentoo-dev] The fallacies of GLEP55

[Richard Freeman]

Alistair Bush wrote:
> 
> Is it really necessary to convince the entire community for every GLEP?
>  I thought that the reason we have the council is so they can make
> decisions. You know specialization of decision making.  If the council
> is going to expect anyone else, besides themselves, to understand an
> issue then why have the council.
> 

They are a representative body.  OF COURSE they should care what the 
community thinks.  They weren't elected SOLELY for technical ability.

Sure, they should use their own judgment as well.  However, GLEPs should 
certainly be debated by the community before they are adopted, and the 
opinions expressed on-list should certainly be taken into account.

Now, does that mean that every decision requires unanimous community 
agreement?  Of course not!  However, the vigorous debate that GLEP55 
seems to inspire suggests that there are more than just a few "hold-outs."

[gentoo-dev] Re: The fallacies of GLEP55

[Mark Bateman]

Patrick Lauer <patrick <at> gentoo.org> writes:

> 
> For quite some time (over a year, actually) we've been discussing the
> mysterious and often misunderstood GLEP55. 
> [http://www.gentoo.org/proj/en/glep/glep-0055.html]
> 
> The proposed solution to a problem that is never refined, in short, is to add
> the EAPI into the ebuild filename "to make things easier". Which is a rather
> unsubstantiated idea that doesn't really add up if you look at it ... and it 
> adds some artifacts that we've been laughing about for a decade because 
> microsoft did the exact same thing (binding the executable-ness of a file to 
> the filename).
> 

The problem isn't GLEP55 (as such), it is a bit more subtle then that and runs 
deeper then just this GLEP.

For starters it is the whole GLEP process
GLEP [Gentoo Linux Enhancement Proposals] is meant as a central place to pull 
*proposals* that provide enhancements to Gentoo.
Some are quite self-apparent (GLEP08)
others are a bit more... lacking (GLEP55)
Why is GLEP55 lacking? because it providing a "solution" to a problem that is 
not actually defined
"The current way of specifying the EAPI in ebuilds is flawed"
That is not defining the problem, that is an opening statement.

"In order to get the EAPI the package manager needs to source the ebuild, which 
itself needs the EAPI in the first place."
It then describes "a" mechanism utilising an ebuild (source /usr/portage...) to 
obtain the EAPI from within the ebuild (EAPI=...). Using this method the entire 
content of GLEP55 is accurate. 

However, this is not the only method to determine the EAPI of an ebuild that 
exists and as such the viability of GLEP55 as the best solution is brought into 
question
Where is it defined that the ebuild must be sourced 1st?
Why does the ebuild have to be sourced 1st?


This then results in ml participants taking this GLEP as the *only* solution 
(to a problem that hasn't actually been defined...) with statements like 
"That's *obviously* completely wrong" 
If something was so obvious this GLEP would have been approved/rejected by now, 
but it hasn't because the problem isn't defined "because it is obvious"

If a problem cannot be describe then the problem is not understood by the one 
writing about the problem.


The GLEP process needs to be refined such that some means of initially raising 
a problem (be it a GLEP itself) that describes the problem in as much detail as 
possible. Once said GLEP has been accepted, ie the problem is acknowledged, 
(sub) GLEP's can be submitted providing possible solutions to the problem.

This way the problems encounted with this particular GLEP, a GLEP that keeps on 
re-surfacing, would be minimised

GLEP55 explicitly states that the EAPI to be recorded in the file extension, 
while, as this thread has shown, a number of methods can be used to source the 
EAPI version of the ebuild *without* the need of actually source'ing the ebuild
(grep, sed, metacache) all of which are viable solutions to the problem, the 
problem that is so obvious it doesn't actually have to be defined


Thing is the package manager *needs* to know the EAPI that the ebuild complies 
to before it can source it to ensure 
1) the correct EAPI-specific eclass is inherited
2) Package manager needs to protect itself from ebuild syntax that earlier 
system packages (eg bash) would fail with 


So please just reject GLEP55, not because its wrong but because it is 
incomplete
reject GLEP55 and have a GLEP62 submitted which defines the problem, then 
request GLEP62-{1,2,3...} be submitted providing possible solutions to the 
problem. GLEP55 can then be submitted as a possible solution. Then 
developers/council can vote on the sub-GLEP's to choose which solution is the 
best technically as well as what is best for the users (dev's and general 
users)


Traceability of issues and solutions is needed, traceability that extends 
beyond mailing-lists and irc logs (discussion mediums which are good for 
instantaneous discussion of issues, but are rubbish for returning to an issue a 
few years down the line, no matter how many logs exist). Report the problem 
better

How clear is it from the stored infomation available whether EAPI's when they 
were 1st conceived and added to portage/paludis/pkgcore was the best solution 
to the problem of expanding on ebuild capability. Or more to the point was how 
it was done partly responsible for the mess we are in now? 

If the problem on ebuild expansion was better documented and defined, maybe 
this GLEP wouldn't even exist, we may have been already using *.ebuild-3 
because it was the best solution

Re: [gentoo-dev] Re: The fallacies of GLEP55

[Ciaran McCreesh]

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

On Sat, 16 May 2009 21:58:10 +0000 (UTC)
Mark Bateman <couldbe@soon.com> wrote:
> "The current way of specifying the EAPI in ebuilds is flawed"
> That is not defining the problem, that is an opening statement.

That is the problem.

> "In order to get the EAPI the package manager needs to source the
> ebuild, which itself needs the EAPI in the first place."
> It then describes "a" mechanism utilising an ebuild
> (source /usr/portage...) to obtain the EAPI from within the ebuild
> (EAPI=...). Using this method the entire content of GLEP55 is
> accurate. 
> 
> However, this is not the only method to determine the EAPI of an
> ebuild that exists and as such the viability of GLEP55 as the best
> solution is brought into question

Yes, it is the only method.

> Where is it defined that the ebuild must be sourced 1st?
> Why does the ebuild have to be sourced 1st?

Such things are obviously true to anyone with a basic understanding of
the domain.

> GLEP55 explicitly states that the EAPI to be recorded in the file
> extension, while, as this thread has shown, a number of methods can
> be used to source the EAPI version of the ebuild *without* the need
> of actually source'ing the ebuild (grep, sed, metacache) all of which
> are viable solutions to the problem, the problem that is so obvious
> it doesn't actually have to be defined

Except that that isn't true. With the current rules, an ebuild has to
be sourced to get EAPI. And you can't just say "use the metadata
cache", since the package manager has to know how to generate the
metadata cache in the first place.

Please make sure you're familiar with the basics of how metadata works
before commenting any further.

-- 
Ciaran McCreesh

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

[gentoo-dev] Re: The fallacies of GLEP55

[Mark Bateman]

Ciaran McCreesh <ciaran.mccreesh <at> googlemail.com> writes:

> 
> On Sat, 16 May 2009 21:58:10 +0000 (UTC)
> Mark Bateman <couldbe <at> soon.com> wrote:
> > "The current way of specifying the EAPI in ebuilds is flawed"
> > That is not defining the problem, that is an opening statement.
> 
> That is the problem.
No, that is a summary of the problem. Not once has the actual problem been 
described or documented. It has been requested multiple times by multiple 
people and yet a description detailing the problem has yet to materialise.
Repeated use of *problem* doesn't suddenly expand on the definition of the word 
*problem* to encompass details needed in a technical proposal within a GLEP.
If you do not understand the problems associated with determining the EAPI of 
an ebuild before sourcing it, please stop championing this GLEP until someone 
does provide a complete breakdown of the process.

Until such information is provided continued discussion of this GLEP is not 
going to progress since words like *obviously* are substituted for actual 
facts, a substitution which does not provide anything new to this discussion
 
> > "In order to get the EAPI the package manager needs to source the
> > ebuild, which itself needs the EAPI in the first place."
> > It then describes "a" mechanism utilising an ebuild
> > (source /usr/portage...) to obtain the EAPI from within the ebuild
> > (EAPI=...). Using this method the entire content of GLEP55 is
> > accurate. 
> > 
> > However, this is not the only method to determine the EAPI of an
> > ebuild that exists and as such the viability of GLEP55 as the best
> > solution is brought into question
> 
> Yes, it is the only method.
No it is the only method you are willing to accept, there is a big difference. 
Many people have mentioned in passing other means of determining the EAPI of 
an ebuild pre-sourcing (thus allowing the PM to source the correct eclass
or flag up warnings...) YET they have just been shot down with no 
actual technical reason, except "they do not involve coding the EAPI 
into the filename". Please provide detailed technical description of 
the problem, as has been requested by a number of people, as well as 
providing details of why in-filename encoding of EAPI is technically 
as well as practically the best solution.



> 
> > Where is it defined that the ebuild must be sourced 1st?
> > Why does the ebuild have to be sourced 1st?
> 
> Such things are obviously true to anyone with a basic understanding of
> the domain.
So you are unable to actually reference any credible source of information to 
back up your claims then.

> 
> > GLEP55 explicitly states that the EAPI to be recorded in the file
> > extension, while, as this thread has shown, a number of methods can
> > be used to source the EAPI version of the ebuild *without* the need
> > of actually source'ing the ebuild (grep, sed, metacache) all of which
> > are viable solutions to the problem, the problem that is so obvious
> > it doesn't actually have to be defined
> 
> Except that that isn't true. With the current rules, an ebuild has to
> be sourced to get EAPI. And you can't just say "use the metadata
> cache", since the package manager has to know how to generate the
> metadata cache in the first place.
> 
> Please make sure you're familiar with the basics of how metadata works
> before commenting any further.
> 
What has my understanding or lack of understanding of "metadata" have to do 
with my statement that other means exist to determine the EAPI of an ebuild 
before sourcing said ebuild? This is meant to be a discussion about "The 
fallacies of GLEP55" 

Refusal to accept any other possible solution as well as refusal to discuss any 
other solution to the problem, all wrapped up in an awe of supremacy on the 
matter (without ONCE providing details) is not beneficial to Gentoo in finding 
the best solution.

Simple fact is there are many methods available to determine the EAPI of an 
ebuild without having to encode it in the filename (or its extension).
In fact you yourself have mentioned that eclasses change the EAPI
http://article.gmane.org/gmane.linux.gentoo.devel/61255
"But eclasses have tried changing it. This is something people have
done, not some hypothetical." 
So the need to have it actually encoded in the filename is not needed, since 
other method's of actually setting the EAPI exist and work.

Blindly dismissing a solution without actually providing any technical 
information of the problem AS well as why a *proposed* solution isn't the best 
is of no benefit to solving the problem

For instance SheBangs are very useful

FILE:test1.py
#!/usr/bin/python2.5
#-*- coding: utf-8 -*-
def bin(number,count):
    return '0b'+"".join([str((number >> y) & 1) for y in range(count-1,-1,-1)])

print 'hello world ',bin(170,8)

FILE:test2.py
#!/usr/bin/python2.6
#-*- coding: utf-8 -*-
print('hello world',bin(170))


executing ./test1  and ./test2 both work WHILE "python2.5 test2.py" fails on 
NameError.
There is no need for the python version to be encoded into the filename (like 
*.py-2.6) and yet it still works.

Re: [gentoo-dev] Re: The fallacies of GLEP55

[Ciaran McCreesh]

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

On Sun, 17 May 2009 04:07:18 +0000 (UTC)
Mark Bateman <couldbe@soon.com> wrote:
> > On Sat, 16 May 2009 21:58:10 +0000 (UTC)
> > Mark Bateman <couldbe <at> soon.com> wrote:
> > > "The current way of specifying the EAPI in ebuilds is flawed"
> > > That is not defining the problem, that is an opening statement.
> > 
> > That is the problem.
> No, that is a summary of the problem. Not once has the actual problem
> been described or documented.

...except where it's described right at the start of the GLEP, under
the 'Problem' section.

> Until such information is provided continued discussion of this GLEP
> is not going to progress since words like *obviously* are substituted
> for actual facts, a substitution which does not provide anything new
> to this discussion 

You are expected to have a basic understanding of the material under
discussion before joining in. Although it might be nice to live in
magic fairy land where everyone has time to explain every single issue
at a level sufficient for a three year old who does not speak English
to be able to understand it, in reality we have to expect you to
understand the basics before getting involved.

> > > However, this is not the only method to determine the EAPI of an
> > > ebuild that exists and as such the viability of GLEP55 as the best
> > > solution is brought into question
> > 
> > Yes, it is the only method.
> No it is the only method you are willing to accept, there is a big
> difference. Many people have mentioned in passing other means of
> determining the EAPI of an ebuild pre-sourcing (thus allowing the PM
> to source the correct eclass or flag up warnings...) YET they have
> just been shot down with no actual technical reason, except "they do
> not involve coding the EAPI into the filename".

Uhm. Please go back and re-read both the GLEP and the threads. Claiming
"no actual technical reason" when actual technical reasons have been
provided is not helping anyone.

> > > Where is it defined that the ebuild must be sourced 1st?
> > > Why does the ebuild have to be sourced 1st?
> > 
> > Such things are obviously true to anyone with a basic understanding
> > of the domain.
> So you are unable to actually reference any credible source of
> information to back up your claims then.

Uhm. No. Go and look at how any of the package managers work. Go and
read PMS. Notice how, by the very definition of EAPI, the only way you
can get EAPI at present is to source the ebuild.

> > Please make sure you're familiar with the basics of how metadata
> > works before commenting any further.
> > 
> What has my understanding or lack of understanding of "metadata" have
> to do with my statement that other means exist to determine the EAPI
> of an ebuild before sourcing said ebuild? This is meant to be a
> discussion about "The fallacies of GLEP55" 

Uhm. EAPI is, at present, a metadata variable. If you don't even know
that, what on earth are you doing talking in this thread? Please stop
wasting everyone's time.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Re: The fallacies of GLEP55

[Patrick Lauer]

On Sunday 17 May 2009 18:35:29 Ciaran McCreesh wrote:
> Please stop wasting everyone's time.

Yes, please do. Your replies are full of emotional arguments and ad hominem 
attacks. If you are unable to keep to the technical aspects of a discussion 
you should reconsider answering to every email (which is also extremely 
tiresome by volume alone).

Now if we can please keep this a discussion (which means tolerating other 
peoples opinions) we might be able to reach some results. That also means that 
we do not know a priori how to solve the problem and that there may be more 
than one solution, mmmmkay?