Re: [gentoo-dev] The fallacies of GLEP55

2009-05-21 Thread 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 nfort...@gmail.com wrote:
  Given the above, it should be clear that any argument which states
  some future improvement to the ebuild format  will be impossible based
  upon making the wrong choice between proposal 1 and proposal 2 must be
  invalid, as they have the same expressive power. Note that allowable
  algorithms for which the proof works includes caching and version
  ordering as well as the simple execution of the ebuild.
 
  Unfortunately, your argument is entirely wrong, as can be illustrated
  by a simple counter-example that you would already know about, had you
  read the GLEP or the thread.
 
  With EAPI in a fixed format, it is impossible to allow extensions to the
  version format in future EAPIs. Even given a fixed format and a constant
  extension, adding foo-1.23-rc1.ebuild will cause breakage, but adding
  foo-1.23-rc1.ebuild-4 will not.
 
  This has already been covered at length, and is explained in the GLEP.
  Why did you disregard this when posting your 'proof'?

 I didn't intentionally disregard that case, but I see your point. I made
 the assumption that package mangers wouldn't try to source ebuilds with
 a sourcing EAPI they didn't understand. I concede this is a terrible
 assumption, unless such a thing is specified in the PMS itself. It is
 still fixed by a single extension change, as opposed to a whole set.
 Once this is done, simply state that all package managers should ignore
 EAPIs they don't understand (a requirement of GLEP-55 as well).

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

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

 Nick Fortino

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




Re: [gentoo-dev] The fallacies of GLEP55

2009-05-17 Thread 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

2009-05-17 Thread 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

2009-05-17 Thread 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

2009-05-17 Thread 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

2009-05-16 Thread 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

2009-05-16 Thread Marijn Schouten (hkBst)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

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

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

 will set EAPI in the current scope to EAPI in the ebuild, without
 sourcing it, unless the issue with something like this would be its
 use of grep and head, but these are both in the system set, so unless
 you don't want to depend on the system set, I don't know what the
 objection would be.
 
 The objection is that your code doesn't work. It's entirely legal to
 do, say:
 
 export EAPI=1
 
 or:
 
 inherit versionator
 
 if version_is_at_least 2 ; then
 EAPI=2
 else
 EAPI=0
 fi
 
 Besides, if we were able to do what your code does, we'd just code it
 natively, not use external programs.

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

Marijn

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

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

iEYEARECAAYFAkoOhxcACgkQp/VmCx0OL2wXqACfSkZVqv2hcskm7Yw7vyizeh5r
UnIAn1npT5j6CcN23WE3yG6p8WDZiF9D
=bI9e
-END PGP SIGNATURE-



Re: [gentoo-dev] The fallacies of GLEP55

2009-05-16 Thread 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

2009-05-16 Thread 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

2009-05-16 Thread Ciaran McCreesh
On Sat, 16 May 2009 11:27:10 +0200
Tobias Klausmann klaus...@gentoo.org wrote:
 Change the spec, then.

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

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

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

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

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

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] The fallacies of GLEP55

2009-05-16 Thread Tobias Klausmann
Hi! 

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

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

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

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

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

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

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

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



Re: [gentoo-dev] The fallacies of GLEP55

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

That doesn't let us do version format changes.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] The fallacies of GLEP55

2009-05-16 Thread Tobias Klausmann
Hi! 

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

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

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

Regards,
Tobias

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



Re: [gentoo-dev] The fallacies of GLEP55

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

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

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] The fallacies of GLEP55

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

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

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

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

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] The fallacies of GLEP55

2009-05-16 Thread Tobias Klausmann
Hi! 

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

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

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

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

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

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

I meant further as in not discussed yet.

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



Re: [gentoo-dev] The fallacies of GLEP55

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

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

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

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

It also means an end to nice incremental updates.

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

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

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

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

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

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] The fallacies of GLEP55

2009-05-16 Thread 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

2009-05-16 Thread 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 klaus...@gentoo.org wrote:
   That doesn't let us do version format changes.
  
  Or are we talking about the *ebuild* versions? I see that as
  different matter. Plus: You could change the version format with
  the changed extension. I sure do hope there are no plans on
  making those changes as often as new EAPIs.
 
 Yes, those. The current rules include some pointless arbitrary
 restrictions that are only there for historical reasons and that mean
 people have to mess with convoluted MY_PV things.

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

-- Arun


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


Re: [gentoo-dev] The fallacies of GLEP55

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

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

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

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

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

.ebuild-? is not complicated.

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

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

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

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

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] The fallacies of GLEP55

2009-05-16 Thread 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 klaus...@gentoo.org wrote:
That doesn't let us do version format changes.
   
   Or are we talking about the *ebuild* versions? I see that as
   different matter. Plus: You could change the version format with
   the changed extension. I sure do hope there are no plans on
   making those changes as often as new EAPIs.
  
  Yes, those. The current rules include some pointless arbitrary
  restrictions that are only there for historical reasons and that mean
  people have to mess with convoluted MY_PV things.
 
 So from all the debate that's going on, the current major issue seems to
 be being able to support '-scm' as per GLEP-54. What other restrictions
 in the version format are you referring to?
 
 -- Arun

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

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




Re: [gentoo-dev] The fallacies of GLEP55

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

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

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

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] The fallacies of GLEP55

2009-05-16 Thread 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

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

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

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] The fallacies of GLEP55

2009-05-16 Thread 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

2009-05-16 Thread Tobias Klausmann
Hi! 

On Sat, 16 May 2009, Ciaran McCreesh wrote:

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

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

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

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

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

Oh, it adds a variable portion to something that's otherwise
static. 
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

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

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

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

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

   My point is this: from experience I suspect having a hard change
   once and having easy progress on either side of it is preferable
   to having mid-range complications all the time.
  
  .ebuild-? is not complicated.
 
 Oh, it adds a variable portion to something that's otherwise
 static. 
 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

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

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

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] The fallacies of GLEP55

2009-05-16 Thread 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

2009-05-16 Thread Tobias Klausmann
Hi! 

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

I'm unable to parse this sentence. 

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

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

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

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

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

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

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

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

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

Regards,
Tobias

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



Re: [gentoo-dev] The fallacies of GLEP55

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

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

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

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

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

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

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

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

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

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

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] The fallacies of GLEP55

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

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

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

We only have one viable solution.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] The fallacies of GLEP55

2009-05-16 Thread 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

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

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

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] The fallacies of GLEP55

2009-05-16 Thread 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 willi...@gentoo.org wrote:
  Agreed.  The way I have always usedEAPI is, you set it once at the top
  of the EBUILD and you are done with it.  As far as I know, there is no
  reason to change EAPI once it is set, and eclasses shouldn't be
  changing it.
 
 But eclasses have tried changing it. This is something people have
 done, not some hypothetical.
 
 I see that as an issue with those eclasses then; they need to be fixed
 so they don't change the EAPI.  They can test for it, but that is all
 they should do.  Maybe that needs to be documented somewhere if it
 isn't already.


- -- 
William Hubbs
gentoo accessibility team lead
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

2009-05-16 Thread 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

2009-05-16 Thread Ciaran McCreesh
On Sat, 16 May 2009 20:38:30 +0200
Robert Buchholz r...@gentoo.org wrote:
 I like the fact that our versioning rules are a fixed subset of the
 sum of all our upstream's versioning rules. It provides a more
 consistent user experience.

 As a user, I know it's always _rc and never -rc. Gentoo
 developers take care of mapping all upstream versions onto an
 easy-to-remember set of ebuild versions.

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

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

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

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] The fallacies of GLEP55

2009-05-16 Thread 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

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

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

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

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

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] The fallacies of GLEP55

2009-05-16 Thread Nick Fortino
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ciaran McCreesh wrote:
 On Sat, 16 May 2009 22:39:46 +0530
 Arun Raghavan ford_pref...@gentoo.org wrote:
  
 On Sat, 2009-05-16 at 17:59 +0100, Ciaran McCreesh wrote:

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

 No, let's fix it so we don't have to do the whole thing again in
 another year or two.
  
 I see nothing about the current problem that merits the fooling around
 with the ebuild extension. I've listened to and considered all the
 arguments that have been made, and I still stand by my opinion that it
 an unclean solution (meaning, we don't need to rehash those arguments
 again here).


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


  

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

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

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

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

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

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

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

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

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


Nick Fortino

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

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

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

[4] If this is unclear, consider the following (inefficient)
construction of a set of ebuilds of type 2 and a 

Re: [gentoo-dev] The fallacies of GLEP55

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

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

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

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

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] The fallacies of GLEP55

2009-05-16 Thread 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

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

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

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

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

   
I didn't intentionally disregard that case, but I see your point. I made
the assumption that package mangers wouldn't try to source ebuilds with
a sourcing EAPI they didn't understand. I concede this is a terrible
assumption, unless such a thing is specified in the PMS itself. It is
still fixed by a single extension change, as opposed to a whole set.
Once this is done, simply state that all package managers should ignore
EAPIs they don't understand (a requirement of GLEP-55 as well).

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

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

Nick Fortino



Re: [gentoo-dev] The fallacies of GLEP55

2009-05-16 Thread 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

2009-05-16 Thread 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

2009-05-16 Thread 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

2009-05-15 Thread 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

2009-05-15 Thread Richard Freeman

Ciaran McCreesh wrote:

On Thu, 14 May 2009 20:06:51 +0200
Patrick Lauer patr...@gentoo.org wrote:

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


Uh, so horribly utterly and obviously wrong.

inherit foo
EAPI=4

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



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


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


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


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


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


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




Re: [gentoo-dev] The fallacies of GLEP55

2009-05-15 Thread 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 patr...@gentoo.org wrote:
  Let EAPI be defined as (the part behind the = of) the first line of
  the ebuild starting with EAPI=
 
  Uh, so horribly utterly and obviously wrong.
 
  inherit foo
  EAPI=4
 
  where foo is both a global and a non-global eclass that sets metadata.

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

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

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

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

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

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

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






Re: [gentoo-dev] The fallacies of GLEP55

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

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

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] The fallacies of GLEP55

2009-05-15 Thread 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

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

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

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

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] The fallacies of GLEP55

2009-05-15 Thread 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

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

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

export EAPI=1

or:

inherit versionator

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

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

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


[gentoo-dev] The fallacies of GLEP55

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

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

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

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

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

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

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

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

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

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

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

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


A few words in closing - 

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

hth,

Patrick the bonsaikitten


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



Re: [gentoo-dev] The fallacies of GLEP55

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

Uh, so horribly utterly and obviously wrong.

inherit foo
EAPI=4

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

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

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

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

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

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

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

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

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

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

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

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] The fallacies of GLEP55

2009-05-14 Thread 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 maybeing it for eternity.

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

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

Aside from -scm (below), there are 

Re: [gentoo-dev] The fallacies of GLEP55

2009-05-14 Thread 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

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

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

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] The fallacies of GLEP55

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

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

-Jeremy



Re: [gentoo-dev] The fallacies of GLEP55

2009-05-14 Thread 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 patr...@gentoo.org wrote:

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

Uh, so horribly utterly and obviously wrong.

inherit foo
EAPI=4

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


Interesting, but quite subtly wrong. I'm surprised that you try to slip such 
an obvious logical mistake in in an attempt to save your arguments.


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



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


And glep55 doesn't solve the problem either. It's neither formal nor correct, 
plus in this case ... what on earth are you trying to communicate?


Again, see my previous comment.


We can encode all the relevant info in the first line of the ebuild
starting with EAPI=

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

It's obviously quite specifically not. Can you show any case where that fails 
or where adding this restriction removes relevant functionality?


Both of you need to explain your opinions here.


Just my thoughts,
R.



Re: [gentoo-dev] The fallacies of GLEP55

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

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

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



Re: [gentoo-dev] The fallacies of GLEP55

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

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

so with glep55 caching it is actually slower!

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

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

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

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] The fallacies of GLEP55

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

so with glep55 caching it is actually slower!

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

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] The fallacies of GLEP55

2009-05-14 Thread Patrick Lauer
On Thursday 14 May 2009 21:20:18 Ciaran McCreesh wrote:
 On Thu, 14 May 2009 13:17:24 -0600

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

 so with glep55 caching it is actually slower!

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


Ah. I was not precise enough.

Let me rephrase it in less ambiguous terms then - 


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

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



Re: [gentoo-dev] The fallacies of GLEP55

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

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

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] The fallacies of GLEP55

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

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

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

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] The fallacies of GLEP55

2009-05-14 Thread 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

2009-05-14 Thread Peter Alfredsen
On Thu, 14 May 2009 22:03:22 +0200
Ben de Groot yng...@gentoo.org wrote:

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

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

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

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

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

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

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

/loki_val



Re: [gentoo-dev] The fallacies of GLEP55

2009-05-14 Thread William Hubbs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

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

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

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

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

- -- 
William Hubbs
gentoo accessibility team lead
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

2009-05-14 Thread Patrick Lauer
On Thursday 14 May 2009 23:53:37 Ciaran McCreesh wrote:
 On Thu, 14 May 2009 16:49:09 -0500

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

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

Trying to pull a Goebbels, eh?

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

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

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

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



Re: [gentoo-dev] The fallacies of GLEP55

2009-05-14 Thread George Prowse

Ciaran McCreesh wrote:

On Thu, 14 May 2009 20:06:51 +0200
Patrick Lauer patr...@gentoo.org wrote:

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

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


Uh, so horribly utterly and obviously wrong.

inherit foo
EAPI=4

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

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


It's slower!
The theory here being that a stat() is needed if it is encoded in the 
filename, but a stat() followed by an open() to parse it from the

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


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


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


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

A few words in closing - 


We can encode all the relevant info in the first line of the ebuild
starting with EAPI=


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


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


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

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

Having countered those four points I guess you agree with the other five 
then. Over 50% success rate (by your definition) is hardly being 
ignorant or trolling