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

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

Re: [gentoo-dev] The fallacies of GLEP55

[Arun Raghavan]

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


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] The fallacies of GLEP55

[Thomas Anderson]

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
-


pgpTTGoJ1MWDK.pgp
Description: PGP signature

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

[Arun Raghavan]

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.


signature.asc
Description: This is a digitally signed message part

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

[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

[Nick Fortino]

Ciaran McCreesh wrote:
> On Sat, 16 May 2009 16:39:40 -0700
> Nick Fortino  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

[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

[Ciaran McCreesh]

On Sat, 16 May 2009 16:39:40 -0700
Nick Fortino  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


signature.asc
Description: PGP signature

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

Re: [gentoo-dev] The fallacies of GLEP55

[Ciaran McCreesh]

On Sun, 17 May 2009 00:42:58 +0530
Arun Raghavan  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


signature.asc
Description: PGP signature

Re: [gentoo-dev] The fallacies of GLEP55

[Arun Raghavan]

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


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] The fallacies of GLEP55

[Ciaran McCreesh]

On Sat, 16 May 2009 20:38:30 +0200
Robert Buchholz  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


signature.asc
Description: PGP signature

Re: [gentoo-dev] The fallacies of GLEP55

[Robert Buchholz]

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


signature.asc
Description: This is a digitally signed message part.

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  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
willi...@gentoo.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)

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

Re: [gentoo-dev] The fallacies of GLEP55

[Ciaran McCreesh]

On Sat, 16 May 2009 13:10:07 -0500
William Hubbs  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


signature.asc
Description: PGP signature

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
willi...@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]

On Sat, 16 May 2009 22:39:46 +0530
Arun Raghavan  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


signature.asc
Description: PGP signature

Re: [gentoo-dev] The fallacies of GLEP55

[Ciaran McCreesh]

On Sat, 16 May 2009 19:13:21 +0200
Tobias Klausmann  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


signature.asc
Description: PGP signature

Re: [gentoo-dev] The fallacies of GLEP55

[Tobias Klausmann]

Hi! 

On Sat, 16 May 2009, Ciaran McCreesh wrote:
> Tobias Klausmann  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

[Arun Raghavan]

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


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] The fallacies of GLEP55

[Ciaran McCreesh]

On Sat, 16 May 2009 22:24:04 +0530
Arun Raghavan  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


signature.asc
Description: PGP signature

Re: [gentoo-dev] The fallacies of GLEP55

[Ciaran McCreesh]

On Sat, 16 May 2009 18:54:41 +0200
Tobias Klausmann  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. 
> globregex
> 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


signature.asc
Description: PGP signature

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

[Arun Raghavan]

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


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] The fallacies of GLEP55

[Ciaran McCreesh]

On Sat, 16 May 2009 22:14:30 +0530
Arun Raghavan  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


signature.asc
Description: PGP signature

Re: [gentoo-dev] The fallacies of GLEP55

[Arun Raghavan]

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


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] The fallacies of GLEP55

[Ciaran McCreesh]

On Sat, 16 May 2009 22:05:08 +0530
Arun Raghavan  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


signature.asc
Description: PGP signature

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

[Ciaran McCreesh]

On Sat, 16 May 2009 18:31:38 +0200
Tobias Klausmann  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


signature.asc
Description: PGP signature

Re: [gentoo-dev] The fallacies of GLEP55

[Arun Raghavan]

On Sat, 2009-05-16 at 16:49 +0100, Ciaran McCreesh wrote:
> On Sat, 16 May 2009 17:43:32 +0200
> Tobias Klausmann  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


signature.asc
Description: This is a digitally signed message part

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]

On Sat, 16 May 2009 18:15:58 +0200
Tobias Klausmann  wrote:
> On Sat, 16 May 2009, Ciaran McCreesh wrote:
> > Tobias Klausmann  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


signature.asc
Description: PGP signature

Re: [gentoo-dev] The fallacies of GLEP55

[Tobias Klausmann]

Hi! 

On Sat, 16 May 2009, Ciaran McCreesh wrote:
> Tobias Klausmann  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]

On Sat, 16 May 2009 17:55:01 +0200
Tobias Klausmann  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


signature.asc
Description: PGP signature

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

On Sat, 16 May 2009 17:43:32 +0200
Tobias Klausmann  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


signature.asc
Description: PGP signature

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  wrote:
> > On Sat, 16 May 2009, Ciaran McCreesh wrote:
> > > On Sat, 16 May 2009 11:27:10 +0200
> > > Tobias Klausmann  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]

On Sat, 16 May 2009 17:32:24 +0200
Tobias Klausmann  wrote:
> On Sat, 16 May 2009, Ciaran McCreesh wrote:
> > On Sat, 16 May 2009 11:27:10 +0200
> > Tobias Klausmann  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


signature.asc
Description: PGP signature

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

On Sat, 16 May 2009 11:27:10 +0200
Tobias Klausmann  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


signature.asc
Description: PGP signature

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

[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

[Marijn Schouten (hkBst)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ciaran McCreesh wrote:
> On Fri, 15 May 2009 14:43:29 -0500
> William Hubbs  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
, #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

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

Re: [gentoo-dev] The fallacies of GLEP55

[Ciaran McCreesh]

On Fri, 15 May 2009 14:43:29 -0500
William Hubbs  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


signature.asc
Description: PGP signature

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
willi...@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]

On Sat, 16 May 2009 00:28:36 +0530
Arun Raghavan  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


signature.asc
Description: PGP signature

Re: [gentoo-dev] The fallacies of GLEP55

[Arun Raghavan]

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


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] The fallacies of GLEP55

[Ciaran McCreesh]

On Fri, 15 May 2009 11:16:11 -0500
"Robert R. Russell"  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


signature.asc
Description: PGP signature

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

[Richard Freeman]

Ciaran McCreesh wrote:

On Thu, 14 May 2009 20:06:51 +0200
Patrick Lauer  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

[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

[George Prowse]

Ciaran McCreesh wrote:

On Thu, 14 May 2009 20:06:51 +0200
Patrick Lauer  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

[Patrick Lauer]

On Thursday 14 May 2009 23:53:37 Ciaran McCreesh wrote:
> On Thu, 14 May 2009 16:49:09 -0500
>
> William Hubbs  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

[Ciaran McCreesh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, 14 May 2009 16:49:09 -0500
William Hubbs  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

[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 ):
 
 

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

[Peter Alfredsen]

On Thu, 14 May 2009 22:03:22 +0200
Ben de Groot  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

[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

[Ciaran McCreesh]

On Thu, 14 May 2009 21:24:14 +0200
Patrick Lauer  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


signature.asc
Description: PGP signature

Re: [gentoo-dev] The fallacies of GLEP55

[Ciaran McCreesh]

On Thu, 14 May 2009 14:15:28 -0500
Jeremy Olexa  wrote:
> On Thu, May 14, 2009 at 2:06 PM, David Leverton
>  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


signature.asc
Description: PGP signature

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  wrote:
> > On Thu, May 14, 2009 at 13:11, Ciaran McCreesh
> >
> >  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]

On Thu, 14 May 2009 13:17:24 -0600
RB  wrote:
> On Thu, May 14, 2009 at 13:11, Ciaran McCreesh
>  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


signature.asc
Description: PGP signature

Re: [gentoo-dev] The fallacies of GLEP55

[Ciaran McCreesh]

On Thu, 14 May 2009 21:09:58 +0200
Tomáš Chvátal  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


signature.asc
Description: PGP signature

Re: [gentoo-dev] The fallacies of GLEP55

[RB]

On Thu, May 14, 2009 at 13:11, Ciaran McCreesh
 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

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

Re: [gentoo-dev] The fallacies of GLEP55

[Jeremy Olexa]

On Thu, May 14, 2009 at 2:06 PM, David Leverton
 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]

On Thu, 14 May 2009 21:05:52 +0200
Patrick Lauer  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


signature.asc
Description: PGP signature

Re: [gentoo-dev] The fallacies of GLEP55

[Tomáš Chvátal]

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


signature.asc
Description: This is a digitally signed message part.

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 t

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

On Thu, 14 May 2009 20:06:51 +0200
Patrick Lauer  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


signature.asc
Description: PGP signature

[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