Re: [gentoo-dev] Gentoo Council Reminder for February 26

2009-02-24 Thread Santiago M. Mola
On Tue, Feb 24, 2009 at 6:47 PM, Brian Harring ferri...@gmail.com wrote:

 At the very least I'm after having the non-pms repos marked in some
 fashion so that alt implementations don't have to assume the portage
 standard (rather then the *agreed to* pms standard) to avoid
 exploding, but that's a rather short sighted solution- something is
 needed long term.


And/or make Portage noisy on PMS violations.

Regards,
-- 
Santiago M. Mola
Jabber ID: cooldw...@gmail.com



[gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-24 Thread Ryan Hill
Alec Warner antarus at gentoo.org writes:

 Somewhat ironically, had everyone been less stubborn last year when
 discussing this topic we could have embedded the EAPI in line X of the
 ebuild in 2008 and be using it now; instead of still discussing it.
 
 I don't expect new novel ideas out of this thread.  I expect the
 council to defer it again because the arguments are the same as last
 time and last time they were not convincing enough.  I would prefer if
 the council went one way or the other so that when we are arguing
 about this in 2010 we can at least say hey we have support in
 $PACKAGE_MANAGERs for EAPI on line X since May 2009 so in 3 months we
 can just switch.  We don't have to make the switch; I'm just saying we
 should add support to hedge our bets.
 
 Thoughts?

Well I give up.  There have been exactly zero technical arguments against GLEP 
55 and plenty of rhetoric, but if that's enough to sway people then so be it.  
If we take EAPI extensions off the table, which of these would work the best 
(aka. gives people the warm fuzzies).

- eapi in the file name, still ends in .ebuild
-- no parsing needed
-- doesn't allow version suffix additions/changes
-- requires an initial wait period for PM's to implement support and be 
stabilized
-- still makes some people grumpy/threaten to leave

- eapi in the ebuild, on a predetermined line number
-- error prone, restrictive
-- doesn't require parsing
-- doesn't allow version suffix additions/changes

- eapi in the ebuild, anywhere
-- what we have now
-- currently requires sourcing the ebuild
-- sourcing the ebuild requires knowing the EAPI
-- doesn't allow version suffix additions/changes (actually, none of these do, 
so i'll stop repeating it)

- eapi in the ebuild, before any other assignments/commands
-- ie. if we hit inherit and no EAPI is defined, EAPI=0
-- restrictive (eapi must be a direct assignment, no conditionals, etc)
-- no per category/PN eapi's or eapi's set in eclasses
-- probably the next best solution (IMUO)

- eapi in metadata somewhere else
-- meh, i'll let the proponents of this argue for it

please fill your arguments for or against, or fix whatever i have wrong.

some other random ideas i've seen tossed around:
- #!/bin/env eapi-parser
- split EAPI into EAPI and some separate counter which would only be 
incremented on uncompatible changes to the ebuild format
- change .ebuild to .eb
- waffles (sorry, lunchtime)






Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-24 Thread Jim Ramsay
Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:
 On Tue, 24 Feb 2009 12:25:27 -0500
 Jim Ramsay l...@gentoo.org wrote:
   ...and it means we can't change name or version rules.
   
   ...and it means over doubling the best possible time to work out a
   dependency tree in the common case where the metadata cache is
   valid.
   
   ...and it means we can't make arbitrary format changes.
  
  Those would all land in the category of backwards compatibility
  mentioned below, as they would all break current sourcing rules.
 
 No, they're also future issues. Without glep 55, every time they come
 up we have to go through the whole mess again.

This minor/major EAPI scheme is exactly equivalent to glep 55 in
the ways that it addresses the non-implementation-specific
details - It could even be added as a caveat to glep-55 that says
something like:

You should not change filename extension (ie, major-EAPI version, or
EPARSE version, or whatever we want to call it...) except when you *have
to* because of changes such as name or version rules, arbitrary format
changes, or anything else that breaks the sourcing rules of the
existing filename extensions. Simpler feature improvements can be done
using whatever internal minor-EAPI version is defined by the major-EAPI
version.

This doesn't prevent you from changing the filename extension when you
have to do so, it just suggests that maybe you don't have to do it for
every single feature-set you may want to implement.

   Developers already have to stop and think and consult the
   conveniently available table of features for EAPIs. By splitting
   the EAPI concept in two you're doubling the amount of data to be
   learnt.
   
  I would think that this is a very small cost, and the benefit would
  be (I hope) that more people would agree on the solution and then
  we can go forward. Is that not a valid consideration?
 
 I'd expect to see changes that would warrant a major bump in every
 other EAPI or so anyway, so it's not really worth the complexity.

If that is indeed the case, then adding this caveat to glep-55 is
basically a nop.  If every EAPI includes a non-backwards-compatible
change that breaks existing PMs, the filename extension will be changed
every time.

But when you say worth the complexity, I'm not exactly sure what
your standards of worthiness are.

I don't think the human cognition of a 2-level versioning scheme is
that tricky, so I assume you must mean complexity in the internals of
package managers - but this should just be a Simple Matter Of
Programming.

I'll further qualify this response by mentioning that I am not a package
manager maintainer.  I don't know beans about metadata and cacheing and
what the tradeoffs may be between a two-level EAPI and a single-level
EAPI stored in the filename.  I understand that parsing two-level EAPI
is more expensive than a single-level stored in the filename.  I don't
however know how to figure out if it is too expensive, or whose
subjective scale we should use to measure this.

I personally feel the complexity that you say is too costly is a fair
tradeoff for a proposal that people will accept.

(Of course I have no idea if people actually would accept a two-level
EAPI any more than glep-55 as-is... I just think it addresses the
concerns I've heard in this thread in a way that does not break
the valid solutions to real problems presented in glep-55)

-- 
Jim Ramsay
Gentoo Developer (rox/fluxbox/gkrellm/vim)


signature.asc
Description: PGP signature


Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-24 Thread Ciaran McCreesh
On Tue, 24 Feb 2009 14:08:45 -0500
Jim Ramsay l...@gentoo.org wrote:
 But when you say worth the complexity, I'm not exactly sure what
 your standards of worthiness are.
 
 I don't think the human cognition of a 2-level versioning scheme is
 that tricky, so I assume you must mean complexity in the internals of
 package managers - but this should just be a Simple Matter Of
 Programming.

People are struggling with the one level scheme we have now. We're
already having to produce fancy tables and summaries for new EAPIs
because people can't keep track of when features came along. Two levels
just means no-one will remember any of it.

For the package manager, it's just a bit of added mess, not any major
difficulty.

 (Of course I have no idea if people actually would accept a two-level
 EAPI any more than glep-55 as-is... I just think it addresses the
 concerns I've heard in this thread in a way that does not break
 the valid solutions to real problems presented in glep-55)

People are opposed to 55 because of a knee-jerk reaction against
changing file extensions and against doing anything that comes from
the great Satan and all his little minions... If you're going to throw
an equivalent but supposedly compromising solution at people, go for
'.eapi3.eb' instead.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-24 Thread Alexis Ballier
On Tue, 24 Feb 2009 18:24:16 +
Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:

 On Tue, 24 Feb 2009 18:16:54 +0100
 Luca Barbato lu_z...@gentoo.org wrote:
   You're doubling the number of files that have to be read for an
   operation that's almost purely i/o bound. On top of that, you're
   introducing a whole bunch of disk seeks in what's otherwise a nice
   linear operation.
  
  I see words, not numbers.
 
 Number: double. That's a '2 times'.

That only means you're increasing the constant factor in the
complexity of the thing... which may very well be completely negligible
unless someone provides real benchmarks. I would be very surprised if
that 2 times factor happens to be true, because finding a string in a
file is an order of magnitude simpler than sourcing said file with
bash. Moreover this doesn't take into account disk and os cache.

Alexis.


signature.asc
Description: PGP signature


Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-24 Thread Ciaran McCreesh
On Tue, 24 Feb 2009 20:28:43 +0100
Alexis Ballier aball...@gentoo.org wrote:
 On Tue, 24 Feb 2009 18:24:16 +
 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:
  On Tue, 24 Feb 2009 18:16:54 +0100
  Luca Barbato lu_z...@gentoo.org wrote:
You're doubling the number of files that have to be read for an
operation that's almost purely i/o bound. On top of that, you're
introducing a whole bunch of disk seeks in what's otherwise a
nice linear operation.
   
   I see words, not numbers.
  
  Number: double. That's a '2 times'.
 
 That only means you're increasing the constant factor in the
 complexity of the thing... which may very well be completely
 negligible unless someone provides real benchmarks.

In the most common case where metadata is valid, around half of the
time it takes Paludis to work out a resolution set is spent grabbing
metadata for ebuilds.

 I would be very surprised if that 2 times factor happens to be true,
 because finding a string in a file is an order of magnitude simpler
 than sourcing said file with bash. Moreover this doesn't take into
 account disk and os cache.

No no no. *Opening* the file is the slow part, not searching. The file
wouldn't otherwise be opened at all.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-24 Thread Jim Ramsay
Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:
 People are struggling with the one level scheme we have now. We're
 already having to produce fancy tables and summaries for new EAPIs
 because people can't keep track of when features came along. Two
 levels just means no-one will remember any of it.

I disagree with your assertion that people are struggling - I think
things are very nicely documented in PMS and the devmanual, which are
where all EAPI changes should be documented in the future, regardless
if you specify the EAPI in the file, the extension, or both.

Two levels really just means that any fancy tables will have to have
one extra row (or perhaps a series of fancy tables) and any summaries
will have to have an extra section added whenever a new filename
extension becomes necessary.

 For the package manager, it's just a bit of added mess, not any major
 difficulty.

This is good to know, thank you for the clarification.

 People are opposed to 55 because of a knee-jerk reaction against
 changing file extensions and against doing anything that comes from
 the great Satan and all his little minions... If you're going to throw
 an equivalent but supposedly compromising solution at people, go for
 '.eapi3.eb' instead.

I can't speak to anyone's motivations or religious beliefs other than my
own here, but the opposition I have heard most often in this thread
is something like: I don't like it when the file extension changes so
often. Some people site historical president or the way other software
does things, or whatever - doesn't really matter.

What does matter is that some people don't like it when the file
extension changes very often. I think my solution is a valid compromise
because it balances, in my opinion, the two camps, whose arguments I
summarize as:

glep-55'ers: I don't care if the file extension changes all the time, I
just want a solution that works and is reasonably future-proof

Anti-55'ers: I don't want the file extension to change ever, but I
would agree that for major-enough changes it may be required
sometimes

If I understand the '.eapi3.eb' to which you make passing reference,
this is just a fancy hand-wavy way to say Look, the true .eb
extension won't ever change, just the .eapi3 part which isn't
technically the extension... which isn't a compromise at all - It's an
attempt to (cleverly?) obfuscate where in the filename the EAPI is
stored.

-- 
Jim Ramsay
Gentoo Developer (rox/fluxbox/gkrellm)


signature.asc
Description: PGP signature


Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-24 Thread Ciaran McCreesh
On Tue, 24 Feb 2009 15:07:29 -0500
Jim Ramsay l...@gentoo.org wrote:
 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:
  People are struggling with the one level scheme we have now. We're
  already having to produce fancy tables and summaries for new EAPIs
  because people can't keep track of when features came along. Two
  levels just means no-one will remember any of it.
 
 I disagree with your assertion that people are struggling - I think
 things are very nicely documented in PMS and the devmanual, which are
 where all EAPI changes should be documented in the future, regardless
 if you specify the EAPI in the file, the extension, or both.

They only ended up nicely documented after people moaned a lot that
they were having a hard time keeping track of EAPIs...

 Two levels really just means that any fancy tables will have to have
 one extra row (or perhaps a series of fancy tables) and any summaries
 will have to have an extra section added whenever a new filename
 extension becomes necessary.

It'll mean people will carry on having to use the tables, and won't
start remembering things as time goes on.

 If I understand the '.eapi3.eb' to which you make passing reference,
 this is just a fancy hand-wavy way to say Look, the true .eb
 extension won't ever change, just the .eapi3 part which isn't
 technically the extension... which isn't a compromise at all - It's
 an attempt to (cleverly?) obfuscate where in the filename the EAPI is
 stored.

Yup. And yet there're people who are perfectly happy with .eapi3.eb who
hate GLEP 55. That should tell you all you need to know about what's
going on here...

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-24 Thread Richard Freeman

Ciaran McCreesh wrote:


..and it means we can't change name or version rules.



Why?  Just parse the EAPI out of the file before you interpret the 
version and name from the filename.  Indeed - you could have a future 
EAPI remove the name and version from the filename entirely.  If a 
package manager doesn't understand the EAPI in a file it shouldn't do 
anything at all with it.



..and it means over doubling the best possible time to work out a
dependency tree in the common case where the metadata cache is valid.



I can see why it takes an extra pass - but does that mean a doubling of 
time?  Couldn't the EAPI be cached as well to reduce disk access?



..and it means we can't make arbitrary format changes.


Well, you would need to preserve the EAPI in the header, but other than 
that you could actually turn an ebuild into an otherwise completely 
binary file, or whatever.  Just how much more flexibility than that is 
needed?




Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-24 Thread Ciaran McCreesh
On Tue, 24 Feb 2009 15:17:01 -0500
Richard Freeman ri...@gentoo.org wrote:
 Why?  Just parse the EAPI out of the file before you interpret the 
 version and name from the filename.  Indeed - you could have a future 
 EAPI remove the name and version from the filename entirely.  If a 
 package manager doesn't understand the EAPI in a file it shouldn't do 
 anything at all with it.

Then you get into the mess of deciding what is or is not an ebuild...
Currently it's well defined; if you start making the package manager
look inside files things get very confusing...

  ..and it means over doubling the best possible time to work out a
  dependency tree in the common case where the metadata cache is
  valid.
 
 I can see why it takes an extra pass - but does that mean a doubling
 of time?  Couldn't the EAPI be cached as well to reduce disk access?

It means opening a file that would otherwise not be opened at all. And
if the EAPI is in the file, you have to fish inside that file to pull
it out before you can work out whether the cache entry that might
contain the EAPI already is valid.

(We don't have to do this currently because inherit hasn't changed
behaviour at all.)

  ..and it means we can't make arbitrary format changes.
 
 Well, you would need to preserve the EAPI in the header, but other
 than that you could actually turn an ebuild into an otherwise
 completely binary file, or whatever.  Just how much more flexibility
 than that is needed?

I remember hearing that years ago, except it was well you can't change
global scope behaviour for EAPIs, but just how much more flexibility
than that is needed?.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-24 Thread Jim Ramsay
Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:
 On Tue, 24 Feb 2009 15:07:29 -0500
 Jim Ramsay l...@gentoo.org wrote:
  I think
  things are very nicely documented in PMS and the devmanual, which
  are where all EAPI changes should be documented in the future,
  regardless if you specify the EAPI in the file, the extension, or
  both.
 
 They only ended up nicely documented after people moaned a lot that
 they were having a hard time keeping track of EAPIs...

You can't possibly be suggesting that everyone will be able to keep an
ever-increasing number of feature sets in his or her mind, or that
changing from a two-level to a one-level EAPI definition will remove
the need for documentation going forward, so I'm not sure what you mean
by this.

  Two levels really just means that any fancy tables will have to have
  one extra row (or perhaps a series of fancy tables) and any
  summaries will have to have an extra section added whenever a new
  filename extension becomes necessary.
 
 It'll mean people will carry on having to use the tables, and won't
 start remembering things as time goes on.

See comment above.  The need for documentation will only increase going
forward as new and varied EAPI definitions are created.

  If I understand the '.eapi3.eb' to which you make passing reference,
  this is just a fancy hand-wavy way to say Look, the true .eb
  extension won't ever change, just the .eapi3 part which isn't
  technically the extension... which isn't a compromise at all - It's
  an attempt to (cleverly?) obfuscate where in the filename the EAPI
  is stored.
 
 Yup. And yet there're people who are perfectly happy with .eapi3.eb
 who hate GLEP 55. That should tell you all you need to know about
 what's going on here...

Seriously?  That's scary.  But hey, if that's actually going to get
more people behind this, let's do it instead.

-- 
Jim Ramsay
Gentoo Developer (rox/fluxbox/gkrellm/vim)


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-24 Thread Robert Bridge
Ciaran McCreesh wrote:
 On Tue, 24 Feb 2009 09:36:29 -0700
 Joe Peterson lava...@gentoo.org wrote:
 2) it makes sense to have these in the filename, but not
 internal meta-data
 
 For those of us who understand the process, it makes sense to have EAPI
 in the filename too.

Which seems to be an enlightened few who... How did we manage before you
graced us with your presence?!

*humbly prostrates myself before this paragon of enlightenment*

Robbie



Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-24 Thread Ciaran McCreesh
On Tue, 24 Feb 2009 15:37:36 -0500
Jim Ramsay l...@gentoo.org wrote:
  They only ended up nicely documented after people moaned a lot that
  they were having a hard time keeping track of EAPIs...
 
 You can't possibly be suggesting that everyone will be able to keep an
 ever-increasing number of feature sets in his or her mind, or that
 changing from a two-level to a one-level EAPI definition will remove
 the need for documentation going forward, so I'm not sure what you
 mean by this.

That's exactly what I mean. Developers can probably just about keep up
with the two or three EAPIs they'll ever be working with on a regular
basis, but they probably can't keep up with that if you double it.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-24 Thread Jim Ramsay
Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:
 On Tue, 24 Feb 2009 15:37:36 -0500
 Jim Ramsay l...@gentoo.org wrote:
   They only ended up nicely documented after people moaned a lot
   that they were having a hard time keeping track of EAPIs...
  
  You can't possibly be suggesting that everyone will be able to keep
  an ever-increasing number of feature sets in his or her mind, or
  that changing from a two-level to a one-level EAPI definition will
  remove the need for documentation going forward, so I'm not sure
  what you mean by this.
 
 That's exactly what I mean. Developers can probably just about keep up
 with the two or three EAPIs they'll ever be working with on a regular
 basis, but they probably can't keep up with that if you double it.

Well, if you're assuming only two or three EAPIs in 'mental cache' at
any one time under glep-55, I'm not sure how this changes wrt. a
two-level system.  A two-level system doesn't change the number of
EAPIs in the tree or available to developers, it just changes how they
are named.

Regardless, this does not remove the need for documentation.  All
the EAPIs should be documented in both the PMS and the devmanual.  This
makes it possible for new developers to learn about the current
features available, and also helps existing devs who may need to
recover from 'mental page faults' from time to time.

-- 
Jim Ramsay
Gentoo Developer (rox/fluxbox/gkrellm/vim)


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-24 Thread Roy Bamford
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2009.02.24 16:48, Ciaran McCreesh wrote:
[snip]
 
 PN and PV are metadata, same as EAPI.
 
[snip]
 -- 
 Ciaran McCreesh
 

So we made a mistake with PN and PV and may compound it with EAPI.
How long before we *must* have other pieces of information in the 
filename?

When will the filename get so long as to become unwhieldy ?
Lets fix it properly now since it will be much more painful to put an 
extendable solution in place later.

It reminds me of other hacks in the history of the PC which we would do 
well not to repeat.
e.g. the MSDOS Partition Table, the Extended Partition, the High Memory 
Area.  

- -- 
Regards,

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

iEYEARECAAYFAkmkZAsACgkQTE4/y7nJvatrUwCgpEKpHAF0hdbkZIJavjwXtABT
eXAAoPlWbQ0B4+F3YFPjrjCXHjuwS2m1
=r7kn
-END PGP SIGNATURE-




Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-24 Thread Ciaran McCreesh
On Tue, 24 Feb 2009 21:17:57 +
Roy Bamford neddyseag...@gentoo.org wrote:
  PN and PV are metadata, same as EAPI.

 So we made a mistake with PN and PV and may compound it with EAPI.
 How long before we *must* have other pieces of information in the 
 filename?

Uh, never.

 When will the filename get so long as to become unwhieldy ?

Uh, never.

 Lets fix it properly now since it will be much more painful to put an 
 extendable solution in place later.

55 is the fix.

 It reminds me of other hacks in the history of the PC which we would
 do well not to repeat.
 e.g. the MSDOS Partition Table, the Extended Partition, the High
 Memory Area.  

Except that once we have EAPI in the file extension, we can change
anything we want in arbitrary ways without having to worry about
backwards compatibility, so we won't need silly hacks.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-24 Thread Robert Bridge
Ciaran McCreesh wrote:
 On Tue, 24 Feb 2009 21:17:57 +
 Except that once we have EAPI in the file extension, we can change
 anything we want in arbitrary ways without having to worry about
 backwards compatibility, so we won't need silly hacks.

Like the file name structure?



Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-24 Thread Luca Barbato

Ciaran McCreesh wrote:

On Tue, 24 Feb 2009 15:17:01 -0500
Richard Freeman ri...@gentoo.org wrote:
Why?  Just parse the EAPI out of the file before you interpret the 
version and name from the filename.  Indeed - you could have a future 
EAPI remove the name and version from the filename entirely.  If a 
package manager doesn't understand the EAPI in a file it shouldn't do 
anything at all with it.


Then you get into the mess of deciding what is or is not an ebuild...
Currently it's well defined; if you start making the package manager
look inside files things get very confusing...


an ebuild is something ending with .ebuild ...


It means opening a file that would otherwise not be opened at all. And
if the EAPI is in the file, you have to fish inside that file to pull
it out before you can work out whether the cache entry that might
contain the EAPI already is valid.


Keeping in mind that:
- if the cache is present you won't do it (so normal users aren't touched)
- you just need a way to upgrade portage and nothing else.

You:
- have to open them on regen, no matter what (you are adding it to portage)
- the cache entry has already the eapi value so there it is.


..and it means we can't make arbitrary format changes.

Well, you would need to preserve the EAPI in the header, but other
than that you could actually turn an ebuild into an otherwise
completely binary file, or whatever.  Just how much more flexibility
than that is needed?


I remember hearing that years ago, except it was well you can't change
global scope behaviour for EAPIs, but just how much more flexibility
than that is needed?.


Given that the fixed header gives you ALL the flexibility. You may give 
provision to consider the next bytes as any kind of serialization...


lu

--

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero




Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-24 Thread Ciaran McCreesh
On Tue, 24 Feb 2009 22:46:17 +0100
Luca Barbato lu_z...@gentoo.org wrote:
  It means opening a file that would otherwise not be opened at all.
  And if the EAPI is in the file, you have to fish inside that file
  to pull it out before you can work out whether the cache entry that
  might contain the EAPI already is valid.
 
 Keeping in mind that:
 - if the cache is present you won't do it (so normal users aren't
 touched)
 - you just need a way to upgrade portage and nothing else.

Not true. You don't know whether the cache is valid until you know what
the EAPI is.

 You:
 - have to open them on regen, no matter what (you are adding it to
 portage)
 - the cache entry has already the eapi value so there it is.

Can't use the cache until you know what the EAPI is.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-24 Thread Roy Bamford
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2009.02.24 21:23, Ciaran McCreesh wrote:
 On Tue, 24 Feb 2009 21:17:57 +
 Roy Bamford neddyseag...@gentoo.org wrote:
   PN and PV are metadata, same as EAPI.
 
  So we made a mistake with PN and PV and may compound it with EAPI.
  How long before we *must* have other pieces of information in the 
  filename?
 
 Uh, never.
 
  When will the filename get so long as to become unwhieldy ?
 
 Uh, never.
 
[snip]

 Except that once we have EAPI in the file extension, we can change
 anything we want in arbitrary ways without having to worry about
 backwards compatibility, so we won't need silly hacks.
 
 -- 
 Ciaran McCreesh
 
Ciaran,

Your response amounts to empty assertions.  Never is a long time.
It reminds me of a similar assertion that 640kB [of RAM] will be 
enough for anyone.

- -- 
Regards,

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

iEYEARECAAYFAkmkcKkACgkQTE4/y7nJvaujMwCdES699P2BXc6VBRKfG4S9As4o
CakAnAp8tsStf1NfKp1AEsGAQC8yxuoE
=zCeb
-END PGP SIGNATURE-




Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-24 Thread Ciaran McCreesh
On Tue, 24 Feb 2009 22:11:47 +
Roy Bamford neddyseag...@gentoo.org wrote:
  Except that once we have EAPI in the file extension, we can change
  anything we want in arbitrary ways without having to worry about
  backwards compatibility, so we won't need silly hacks.
 
 Your response amounts to empty assertions.  Never is a long time.
 It reminds me of a similar assertion that 640kB [of RAM] will be 
 enough for anyone.

Er, no. Think about it. If EAPI is in file extension, the only concern
for backwards compatibility is not reusing an existing valid extension.
All we have to do is use a new EAPI value, and then we can change
whatever we like because non-supporting package managers will ignore it.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


[gentoo-dev] Collecting opinions about GLEP 55 and alternatives

2009-02-24 Thread Petteri Räty
Let's try something new. I would like to get opinions from as many
people as possible about GLEP 55 and alternatives listed here in order
to get some idea what the general developer pool thinks. Everyone is
only allowed to post a single reply to this thread in order to make it
easy to read through. The existing thread should be used for actual
discussion about the GLEP and the alternatives. This should be a useful
experiment to see if we can control ourselves :)

My notes so far:

1) Status quo
  - does not allow changing inherit
  - bash version in global scope
  - global scope in general is quite locked down

2) EAPI in file extension
  - Allows changing global scope and the internal format of the ebuild
  a) .ebuild-eapi
- ignored by current Portage
  b) .eapi.ebuild
- current Portage does not work with this
  c) .eapi.new extension
- ignored by current Portage

3) EAPI in locked down place in the ebuild
  - Allows changing global scope
  - EAPI can't be changed in an existing ebuild so the PM can trust
the value in the cache
  - Does not allow changing versioning rules unless version becomes a
normal metadata variable
* Needs more accesses to cache as now you don't have to load older
  versions if the latest is not masked
  a) new extension
  b) new subdirectory like ebuilds/
  - we could drop extension all together so don't have to argue about
it any more
  - more directory reads to get the list of ebuilds in a repository
  c) .ebuild in current directory
  - needs one year wait

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-24 Thread Luca Barbato

Ciaran McCreesh wrote:

Not true. You don't know whether the cache is valid until you know what
the EAPI is.


If you are on the user scenario the cache is valid.
If the eapi changes the cache meaning you can always put the new cache 
in another place older portage won't look into.



You:
- have to open them on regen, no matter what (you are adding it to
portage)
- the cache entry has already the eapi value so there it is.


Can't use the cache until you know what the EAPI is.


The current cache holds all the current portage needs to know what to 
ignore, providing the cache in such format will make portage ignore any 
future change.


lu

--

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero




Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

2009-02-24 Thread Ferris McCormick
On Wed, 25 Feb 2009 00:21:23 +0200
Petteri Räty betelge...@gentoo.org wrote:

 Let's try something new. I would like to get opinions from as many
 people as possible about GLEP 55 and alternatives listed here in order
 to get some idea what the general developer pool thinks. Everyone is
 only allowed to post a single reply to this thread in order to make it
 easy to read through. The existing thread should be used for actual
 discussion about the GLEP and the alternatives. This should be a useful
 experiment to see if we can control ourselves :)
 
 My notes so far:
 
 1) Status quo
   - does not allow changing inherit
   - bash version in global scope
   - global scope in general is quite locked down
 
 2) EAPI in file extension
   - Allows changing global scope and the internal format of the ebuild
   a) .ebuild-eapi
 - ignored by current Portage

This is GLEP-55 I think, and it is my preference.  It seems to solve
the problem that the glep sets out to solve and has no effect on
current portage.I don't claim that it's beautiful or perfect, but I
have not seen a better alternative, either.  It also has going for it
the fact that some number of people have already thought through it and
Piotr went to the effort of writing it up as a proposal, so it has had
more thought put into it than alternatives.  I do not find the
arguments against it persuasive, so I'd say do this and be done with
it.  We can argue forever for better alternatives, but I don't see that
we are getting very far with that approach.  Just my opinion, of course.

   b) .eapi.ebuild
 - current Portage does not work with this
   c) .eapi.new extension
 - ignored by current Portage

This one's OK with me, too, if people prefer it.

 
 3) EAPI in locked down place in the ebuild

I generally dislike this sort of thing, and I think it puts more of a
strain of the ebuild developers.  But then, I'm not an package
developer, so my opinion with respect to this is not worth much.  I'd
just rather see the EAPI visible in the file name than have to read the
ebuild to find it, and I guess the overhead argument is that it's
easier on portage not to have to do that, too.

   - Allows changing global scope
   - EAPI can't be changed in an existing ebuild so the PM can trust
 the value in the cache
   - Does not allow changing versioning rules unless version becomes a
 normal metadata variable
 * Needs more accesses to cache as now you don't have to load older
   versions if the latest is not masked
   a) new extension

I don't see why this is better than the glep 55 proposal???

   b) new subdirectory like ebuilds/

Yuch.

   - we could drop extension all together so don't have to argue about
 it any more
   - more directory reads to get the list of ebuilds in a repository
   c) .ebuild in current directory
   - needs one year wait
 
 Regards,
 Petteri
 

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


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-24 Thread Luca Barbato

Ryan Hill wrote:

some other random ideas i've seen tossed around:
- #!/bin/env eapi-parser
- split EAPI into EAPI and some separate counter which would only be 
incremented on uncompatible changes to the ebuild format

- change .ebuild to .eb
- waffles (sorry, lunchtime)


Yummy!

--

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero




Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-24 Thread Ciaran McCreesh
On Tue, 24 Feb 2009 23:48:27 +0100
Luca Barbato lu_z...@gentoo.org wrote:
 Ciaran McCreesh wrote:
  Not true. You don't know whether the cache is valid until you know
  what the EAPI is.
 
 If you are on the user scenario the cache is valid.

Uh. Wrong.

  Can't use the cache until you know what the EAPI is.
 
 The current cache holds all the current portage needs to know what to 
 ignore, providing the cache in such format will make portage ignore
 any future change.

Uh. Wrong.

The information used to validate a cache entry is only usable if you
know the behaviour of 'inherit' that was used to create the entry.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


[gentoo-dev] Re: Collecting opinions about GLEP 55 and alternatives

2009-02-24 Thread Ryan Hill
On Wed, 25 Feb 2009 00:21:23 +0200
Petteri Räty betelge...@gentoo.org wrote:

 Let's try something new. I would like to get opinions from as many
 people as possible about GLEP 55 and alternatives listed here in order
 to get some idea what the general developer pool thinks. Everyone is
 only allowed to post a single reply to this thread in order to make it
 easy to read through. The existing thread should be used for actual
 discussion about the GLEP and the alternatives. This should be a
 useful experiment to see if we can control ourselves :)
 
 My notes so far:
 
 1) Status quo
   - does not allow changing inherit
   - bash version in global scope
   - global scope in general is quite locked down
 
 2) EAPI in file extension
   - Allows changing global scope and the internal format of the ebuild
   a) .ebuild-eapi
 - ignored by current Portage

#1

Though I also wouldn't mind separate EAPI and ebuild-format versions,
EAPI limited to the stuffing and EBV for the bird.  I'd expect the
number of times we'll need to make global changes will be few.
(fewer than EAPI changes anyways)

   b) .eapi.ebuild
 - current Portage does not work with this

#2

   c) .eapi.new extension
 - ignored by current Portage

This would be #2 if I could think of a better extension than .ebuild

.esh
.gentoo
.rebuild
.fbuild
.eawesomeness

(not seriously)

 3) EAPI in locked down place in the ebuild
   - Allows changing global scope
   - EAPI can't be changed in an existing ebuild so the PM can trust
 the value in the cache
   - Does not allow changing versioning rules unless version becomes a
 normal metadata variable
 * Needs more accesses to cache as now you don't have to load older
   versions if the latest is not masked
   a) new extension
   b) new subdirectory like ebuilds/
   - we could drop extension all together so don't have to argue about
 it any more
   - more directory reads to get the list of ebuilds in a repository
   c) .ebuild in current directory
   - needs one year wait

#3

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


signature.asc
Description: PGP signature


Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

2009-02-24 Thread Richard Freeman

Petteri Räty wrote:

3) EAPI in locked down place in the ebuild
  - Allows changing global scope
  - EAPI can't be changed in an existing ebuild so the PM can trust
the value in the cache


I don't see how this follows.  The PM can compare the mtime on the file 
with the time the cache was updated and refresh if needed.  Or we could 
require users to manually refresh the cache if they modify an ebuild.



  - Does not allow changing versioning rules unless version becomes a
normal metadata variable


I don't see how this follows.  You can put any version in the filename 
that you like just as with the EAPI in the filename approach.  A package 
manager won't process the filename if it doesn't understand the EAPI. 
The order of processing for a package manager would be:

1.  Scan for files named *.ebuild.
2.  Scan the nth line inside to obtain the EAPI.
3.  Take further action in accordance with the EAPI - possibly including 
obtaining the package name/version from the filename, or maybe somewhere 
else entirely.



* Needs more accesses to cache as now you don't have to load older
  versions if the latest is not masked


Why wouldn't you cache every version of a package with its EAPI for 
reference?  I don't follow why this needs more cache hits.  However, 
even if you had to hit the cache more often I don't see why a cache 
lookup would be expensive.  Isn't it stored in a sensible format for 
rapid random access?


My preference is obviously for embedding the EAPI inside the file in 
some manner.  My second preference would be for only changing the file 
extension on rare occasions that are individually approved by the 
Council when things need to change dramatically, as opposed to any time 
the EAPI changes.




Re: [gentoo-dev] Issues regarding glep-55

2009-02-24 Thread Petteri Räty
Also one point worth nothing here is that migrating from EAPI in the
file name to having it in a special place in the file can be scripted so
the change should be quite easy to do at a later point in time for the
main repository if wanted.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

2009-02-24 Thread Jeremy Olexa

Petteri Räty wrote:

Let's try something new. I would like to get opinions from as many
people as possible about GLEP 55 and alternatives listed here in order
to get some idea what the general developer pool thinks. Everyone is
only allowed to post a single reply to this thread in order to make it
easy to read through. The existing thread should be used for actual
discussion about the GLEP and the alternatives. This should be a useful
experiment to see if we can control ourselves :)

My notes so far:

1) Status quo
  - does not allow changing inherit
  - bash version in global scope
  - global scope in general is quite locked down

2) EAPI in file extension
  - Allows changing global scope and the internal format of the ebuild
  a) .ebuild-eapi
- ignored by current Portage
  b) .eapi.ebuild
- current Portage does not work with this
  c) .eapi.new extension
- ignored by current Portage

3) EAPI in locked down place in the ebuild
  - Allows changing global scope
  - EAPI can't be changed in an existing ebuild so the PM can trust
the value in the cache
  - Does not allow changing versioning rules unless version becomes a
normal metadata variable
* Needs more accesses to cache as now you don't have to load older
  versions if the latest is not masked
  a) new extension
  b) new subdirectory like ebuilds/
  - we could drop extension all together so don't have to argue about
it any more
  - more directory reads to get the list of ebuilds in a repository
  c) .ebuild in current directory
  - needs one year wait

Regards,
Petteri



Thanks for gathering input from the dev community. I do not wish to 
respond to the monster thread (and won't).


Personally, I don't need the flexibility that glep55 provides for *my* 
ebuilds. The current scheme doesn't bother me. And actually, after doing 
some testing, I found that at least one of that packages/projects that I 
am involved in will need updating every time the extension changes (or 
some more broad change - I don't have time to investigate too much tbh). 
So, I would prefer that the file extension did not change [much/every 
eapi]. However, I can roll with the punches if it truely is needed. I 
also understand that some change is good in the long run even if it has 
some upfront cost to it.


However, in case that this discussion gets deferred until later, I would 
like to express that the Council should request (not demand) that 
portage adds support for the leading 2 ideas that result from the 
current discussion. This will allow us to not wait even longer when we 
are having this discussion in 2010 (hypothetically).


Thanks for listening, Petteri.
-Jeremy




Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-24 Thread Luca Barbato

Ciaran McCreesh wrote:

On Tue, 24 Feb 2009 18:16:54 +0100
Luca Barbato lu_z...@gentoo.org wrote:

You're doubling the number of files that have to be read for an
operation that's almost purely i/o bound. On top of that, you're
introducing a whole bunch of disk seeks in what's otherwise a nice
linear operation.

I see words, not numbers.


Number: double. That's a '2 times'.


given that the simplest thing is hacking ebuild.sh and extract eapi with 
a simple C program (you can use pcre or ragel if you want) exactly 
before the ebuild source:


Index: bin/ebuild.sh
===
--- bin/ebuild.sh   (revision 12704)
+++ bin/ebuild.sh   (working copy)
@@ -1848,6 +1848,7 @@
# eclasses, they need to be unset before this process of
# interaction begins.
unset DEPEND RDEPEND PDEPEND IUSE
+   EAPI=$(eapitool ${EBUILD})
source ${EBUILD} || die error sourcing ebuild

if [ ${EBUILD_PHASE} != depend ] ; then

I think your numbers are a bit pessimistic, this is when you get EAPI in 
portage, post source ${EBUILD}, opening the file before source would 
just put in the cache one line earlier.



You don't know whether the cache is valid until you know the EAPI. It
only works currently because EAPIs don't change inherit behaviour.


There were already discussions about switching cache format, if we want 
to change the inherit behaviour we could just switch at the same time 
the cache format and leave dummy entry for compatibility with legacy 
portage.



So you have patches for Portage? Please show them.


Up there what's enough to check the viability for the solution.

the bash subst I wrote before could be used instead of the call to get 
the eapi in extension behaviour.



unknown isn't unsupported?


Huh? Please explain what you mean.


mv cat/pkg-version.ebuild cat/pkg-version_foo.ebuild

emerge -vp pkg

portage will warn about not knowing pkg-version_foo and will ignore it.

lu

--

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero




Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

2009-02-24 Thread Dawid Węgliński
On Tuesday 24 of February 2009 23:21:23 Petteri Räty wrote:
 Let's try something new. I would like to get opinions from as many
 people as possible about GLEP 55 and alternatives listed here in order
 to get some idea what the general developer pool thinks. Everyone is
 only allowed to post a single reply to this thread in order to make it
 easy to read through. The existing thread should be used for actual
 discussion about the GLEP and the alternatives. This should be a useful
 experiment to see if we can control ourselves :)

 My notes so far:

 1) Status quo
   - does not allow changing inherit
   - bash version in global scope
   - global scope in general is quite locked down

 2) EAPI in file extension
   - Allows changing global scope and the internal format of the ebuild
   a) .ebuild-eapi
 - ignored by current Portage
   b) .eapi.ebuild
 - current Portage does not work with this
   c) .eapi.new extension
 - ignored by current Portage

All of this are ok for me, though the first shot is my preffered one since 
it's the most human readable and the rest would be mostly seen as the package 
version.


 3) EAPI in locked down place in the ebuild
   - Allows changing global scope
   - EAPI can't be changed in an existing ebuild so the PM can trust
 the value in the cache
   - Does not allow changing versioning rules unless version becomes a
 normal metadata variable
 * Needs more accesses to cache as now you don't have to load older
   versions if the latest is not masked
   a) new extension

I don't see this as the best solution.

   b) new subdirectory like ebuilds/
   - we could drop extension all together so don't have to argue about
 it any more
   - more directory reads to get the list of ebuilds in a repository

Nah. Scanning portage tree in this place would be more painful than it's 
currently.

   c) .ebuild in current directory
   - needs one year wait

 Regards,
 Petteri





Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

2009-02-24 Thread Alistair Bush


Petteri Räty wrote:
 Let's try something new. I would like to get opinions from as many
 people as possible about GLEP 55 and alternatives listed here in order
 to get some idea what the general developer pool thinks. Everyone is
 only allowed to post a single reply to this thread in order to make it
 easy to read through. The existing thread should be used for actual
 discussion about the GLEP and the alternatives. This should be a useful
 experiment to see if we can control ourselves :)
 

Thank you Petteri. I knew there was a reason I voted for you.

 
 2) EAPI in file extension
   - Allows changing global scope and the internal format of the ebuild
   a) .ebuild-eapi
 - ignored by current Portage
   b) .eapi.ebuild
 - current Portage does not work with this
   c) .eapi.new extension
 - ignored by current Portage

a) then c).  I personally think b) is a bad idea that will just slow the
implementation of this even more.

 
 3) EAPI in locked down place in the ebuild
   - Allows changing global scope
   - EAPI can't be changed in an existing ebuild so the PM can trust
 the value in the cache
   - Does not allow changing versioning rules unless version becomes a
 normal metadata variable
 * Needs more accesses to cache as now you don't have to load older
   versions if the latest is not masked
   a) new extension
   b) new subdirectory like ebuilds/
   - we could drop extension all together so don't have to argue about
 it any more
   - more directory reads to get the list of ebuilds in a repository
   c) .ebuild in current directory
   - needs one year wait

If it really comes to it  b)?  Tho it leaves a bad taste in my mouth.

 
 Regards,
 Petteri
 



Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

2009-02-24 Thread Alec Warner
 On Tue, Feb 24, 2009 at 2:21 PM, Petteri Räty betelge...@gentoo.org wrote:
 Let's try something new. I would like to get opinions from as many
 people as possible about GLEP 55 and alternatives listed here in order
 to get some idea what the general developer pool thinks. Everyone is
 only allowed to post a single reply to this thread in order to make it
 easy to read through. The existing thread should be used for actual
 discussion about the GLEP and the alternatives. This should be a useful
 experiment to see if we can control ourselves :)

 My notes so far:

 1) Status quo
  - does not allow changing inherit
  - bash version in global scope
  - global scope in general is quite locked down

 2) EAPI in file extension
  - Allows changing global scope and the internal format of the ebuild
  a) .ebuild-eapi
- ignored by current Portage
  b) .eapi.ebuild
- current Portage does not work with this
  c) .eapi.new extension
- ignored by current Portage

 3) EAPI in locked down place in the ebuild
  - Allows changing global scope
  - EAPI can't be changed in an existing ebuild so the PM can trust
the value in the cache
  - Does not allow changing versioning rules unless version becomes a
normal metadata variable
* Needs more accesses to cache as now you don't have to load older
  versions if the latest is not masked
  a) new extension
  b) new subdirectory like ebuilds/
  - we could drop extension all together so don't have to argue about
it any more
  - more directory reads to get the list of ebuilds in a repository
  c) .ebuild in current directory
  - needs one year wait

I'm adding stuff to this; but its in my copy of glep-55.txt which I
will probably send out later.  I basically see this as a mix of
options and requirements and thats how I would expect the council to
make their decision.
For instance; if we don't care about backwards compatibility with
older managers than we can enable a number of other solutions that
would otherwise be excluded.  If we want to be able to swap versions
of bash as a requirement; that automatically excludes specific
solutions that don't handle that case.  So in my rewrite of glep55 I'm
attempting to make a list similar to yours and try to convey what
requirements are togglable for each thing.  In the end I expect the
council to:

 - Choose requirements that make the most sense for Gentoo.
 - Look at the solutions that are left that meet said requirements and pick one.

dev.gentoo.org/~antarus/projects/gleps/glep-0055.html for the updated GLEP.

-A


 Regards,
 Petteri





Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

2009-02-24 Thread Jeroen Roovers
On Wed, 25 Feb 2009 00:21:23 +0200
Petteri Räty betelge...@gentoo.org wrote:

 Let's try something new. I would like to get opinions [...]

A multitude of leaves on every branch of the tree. That could be a
multiple of the current tree size - maybe talk to infra about this.

It's also a multitude of complexity - as an arch security liaison, I
get to see how difficult it is already to figure out which revision to
test and mark, and figuring out why a certain revision isn't ready yet
is tantamount to figuring out what EAPI=foo actually means.

As an ebuild developer I get to see how difficult it is to figure out
which EAPI is ready enough to write ebuilds for - Changing filename
extensions is to me like a Windows 95 way of opening a file and it
doesn't at all tell me what I can and cannot put into that file.

Either as an arch, or as ebuild dev pur sang, I don't care about EAPIs
that much until I want to use a new feature - I don't want to maintain
EAPI=N branches of testing and stabling systems to test stuff either
before it's published or when it's time for stabilisation. Stamping
EAPIs down in filename extensions is just another way to point out the
cruft.

As a bug wrangler, it doesn't solve current problems of stale overlays
with too novel or too old ebuilds.

To users, it doesn't matter at all - which seems to bring about the
question of the use case everyone's clamouring for. What developers
will benefit this at all, how large are the branches this will affect,
how many developers will have to rewrite tools, and so on?


Kind regards,
  jer



Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

2009-02-24 Thread Ulrich Mueller
 On Wed, 25 Feb 2009, Petteri Räty wrote:

 Let's try something new. I would like to get opinions from as many
 people as possible about GLEP 55 and alternatives listed here in order
 to get some idea what the general developer pool thinks.

I've already commented on this in December 2007 [1], and my opinion
hasn't changed.

 1) Status quo
 2) EAPI in file extension
 3) EAPI in locked down place in the ebuild
   a) new extension
   b) new subdirectory like ebuilds/
   c) .ebuild in current directory

Acceptable for me would be 1) and 3c).

   - needs one year wait

Please state more precisely, what events would mark the beginning and
end of this time period?

Ulrich

[1] 
http://archives.gentoo.org/gentoo-dev/msg_81b3eeb61186874caa291b66e728348c.xml



Re: [gentoo-dev] Gentoo Council Reminder for February 26

2009-02-24 Thread Donnie Berkholz
On 23:26 Sun 22 Feb , Donnie Berkholz wrote:
 This is your friendly reminder! Same bat time (typically the 2nd  4th 
 Thursdays at 2000 UTC / 1600 EST), same bat channel (#gentoo-council @ 
 irc.freenode.net) !
 
 If you have something you'd wish for us to chat about, maybe even vote 
 on, let us know! Simply reply to this e-mail for the whole Gentoo dev 
 list to see.

Here's the preliminary agenda. I'm running a bit behind on -dev, so it's 
a little out of date re GLEPs 54/55. People including lu_zero, cardoe, 
dev-zero, and tanderson should fill us in on things below that they've 
taken responsibility for. Anyone else can chime in anywhere!


Open council spot
-

leio is next on the list. He's willing to join the council. A few of us 
already voted to confirm him on-list, and we're waiting on the others.

Goal: Vote to confirm him, if necessary.


GLEP 55 / bash version
--

Crazy amounts of discussion on-list. Cardoe  Tiziano, you took 
responsibility for this -- can you sum up the current state of things? 
Pending something better, here's what I'd like to see happen on-list (or 
on the wiki, whatever) before the meeting:

Goal: Come up with 3 things:
1) Agreement that this is a problem we need to solve now;
2) Come up with a list of potential implementations;
3) Come up with pros  cons for each.

At that point, we should have enough information to at least rank them 
and decide out whether the top-ranked one has the right approach. We 
should then clearly define any problems with it and suggest 
improvements.


GLEP 54: handling code from SCMs better
---

Some discussion on list. Luca, can you sum up the state of things?


PMS compliance in Gentoo-hosted trees besides gentoo-x86


ferringb requested this. We need some discussion on-list before we talk 
about it during a meeting, so please chip in and reply to his post.


Suggestions are welcome, as are any summaries from our new secretary. =)

-- 
Thanks,
Donnie

Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com


pgpOy07KQWstu.pgp
Description: PGP signature


Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-24 Thread Alistair Bush
Luca Barbato wrote:
 Luca Barbato wrote:
 Ciaran McCreesh wrote:
 Because your proposal addresses none of the underlying problems which
 GLEP 55 was created to solve.
 
 let's get some numbers to have an idea of the dimension of the problem.
 

I just don't think those numbers tell us anything and that should be
obvious from anyone who has read GLEP 55[1],  we ain't really attempting
to solve a problem that exists within the tree currently (well the bash
issue does, in a way ). We are trying to solve issues that ware stopping
the tree moving forward.  Lets evaluate GLEP 55 in the problems it is
attempting to solve.

[1]
Problem

The current way of specifying the EAPI in ebuilds is flawed. In order to
get the EAPI the package manager needs to source the ebuild, which
itself needs the EAPI in the first place. Otherwise it imposes a serious
limitation, namely every ebuild, using any of the future EAPIs, will
have to be source'able by old package managers and hence there is no way
to do any of the following:

* Change the behaviour of inherit in any way (for example, to
extend or change eclass functionality).
* Add new global scope functions in any sane way.
* Extend versioning rules in an EAPI - for example, addition of
the scm suffix - GLEP54 [1].



Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-24 Thread George Shapovalov
(Ok this thread grew too long, so I gotta chime in :))

We could start using extended attributes or mandate reiser4 for portage dir or 
some other special in between (the inside of file and its name) feature..

Sorry for the noise and insane implementation suggestion :)..

George

PS
Actually, come to think of it, reizer4 might be just the right tool for the 
job (for keeping the volatile info split into bunch of small entries), 
hypothetically of course..


Tuesday, 24. February 2009, Luca Barbato Ви написали:
 Luca Barbato wrote:
  Ciaran McCreesh wrote:
  Because your proposal addresses none of the underlying problems which
  GLEP 55 was created to solve.

 let's get some numbers to have an idea of the dimension of the problem.
[skip]

 Please come up with other numbers or saner implementations to compare.

 lu



Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-24 Thread Luca Barbato

Alistair Bush wrote:

I just don't think those numbers tell us anything and that should be
obvious from anyone who has read GLEP 55[1],  we ain't really attempting
to solve a problem that exists within the tree currently (well the bash
issue does, in a way ). We are trying to solve issues that ware stopping
the tree moving forward.  Lets evaluate GLEP 55 in the problems it is
attempting to solve.


I'm afraid you missed the whole point...

- what is in the proposal is a solution looking for a problem: nobody 
updated the glep with the required sections, nobody put up a list of 
bugs/rfe from bugzilla it helps to solve. Vague leading to the future 
change declaration aren't what I'd expect.


- Assuming there is an actual reason to move forward (by digging 
bugzilla yourself or deciding to do so as academic exercise) you could 
think about the problem and its solutions (my the email starting this 
thread on dev)


- Given all you need is just to have a way to get the information about 
EAPI before you actually parse the ebuild since the eapi defines how you 
parse it, you can come up with various solutions, the simplest being 
first extract the eapi, being it in a fixed place, and then do the parse.


- Extracting such information could have different costs depending on 
where to place it.


- I started to check if the proposal about having the fixed position as 
the end of the filename is really much more viable than having it at the 
top of the file.


lu


--

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero




Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-24 Thread Alistair Bush
George Shapovalov wrote:
 (Ok this thread grew too long, so I gotta chime in :))
 
 We could start using extended attributes or mandate reiser4 for portage dir 
 or 
 some other special in between (the inside of file and its name) feature..

No.
1) I wouldn't use reiser4 so that would be the end of that.
2) how well do rsync and cvs support xattr's.  How about linux support
verses bsd, or windows even.
3) It is just a bad solution

 
 Sorry for the noise and insane implementation suggestion :)..

At least you realise it :)



Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-24 Thread Alistair Bush


Luca Barbato wrote:
 Alistair Bush wrote:
 I just don't think those numbers tell us anything and that should be
 obvious from anyone who has read GLEP 55[1],  we ain't really attempting
 to solve a problem that exists within the tree currently (well the bash
 issue does, in a way ). We are trying to solve issues that ware stopping
 the tree moving forward.  Lets evaluate GLEP 55 in the problems it is
 attempting to solve.
 
 I'm afraid you missed the whole point...
 
 - what is in the proposal is a solution looking for a problem: nobody
 updated the glep with the required sections, nobody put up a list of
 bugs/rfe from bugzilla it helps to solve. Vague leading to the future
 change declaration aren't what I'd expect.
 

So im mean't to start committing ebuilds into the tree that expect a
certain unimplemented functionality, only to file bugs against portage
for it not supporting them?  Or can we be smart enough to realise that
there are limitation to the current standard and then attempt to fix
them before they become a problem.  Plus we already know of at least one
case where we will encounter a problem in the future,  why?  because we
have already.  Not sure if there is a open bug about it tho.

This actually eats at me,  your basically saying GLEP's should only be
reactive.  Why don't we all just roll over and die.

 - Assuming there is an actual reason to move forward (by digging
 bugzilla yourself or deciding to do so as academic exercise) you could
 think about the problem and its solutions (my the email starting this
 thread on dev)

I have already considered the problems, and believe GLEP 55 is the
**best** solution to them.  Is it perfect, no.  But I have yet to see
anything better.

 
 - Given all you need is just to have a way to get the information about
 EAPI before you actually parse the ebuild since the eapi defines how you
 parse it, you can come up with various solutions, the simplest being
 first extract the eapi, being it in a fixed place, and then do the parse.
 

Yes exactly,  you need to know the EAPI before you __parse__ the ebuild.
 At least we agree that nothing should have to read the contents of the
file to determine EAPI (doing so would be parsing now wouldn't it).  So
seeing that we agree with that,  where should we stick the EAPI.
m

1)  How about in a flat txt file:   That would become a developers
nightmare.
2)  In an xml file.  Package managers would have to support xml.  Not
the best thing in the world. also could be a nightmare,  adding an entry
for every ebuild.
3)  As an xattr.  Well this idea is novel.  I bet it would make the tree
nice and stable too.  Lets not forget how annoying it will be for devs.
4) Parsing the ebuild.  But what are we parsing?,  lets not limit
ourselves to bash,  we might want to change languages completely.  If it
is bash,  what version, what if EAPI is set multiple times,  what if its
set in an eclass.
5)  M...On the file name sounds like a good idea.  especially as an
extension.  provides information to a package manager, person,
script/program without them needing to open anything.  identifies the
contents just like .txt, .c, .o, .jpeg, etc

 - Extracting such information could have different costs depending on
 where to place it.

I believe it being on the filename would be the least costly,  in terms
of processor/io at least.



Re: [gentoo-dev] [RFC] global useflags

2009-02-24 Thread Timothy Redaelli
Il martedì 24 febbraio 2009 00:00:26 Markus Meier ha scritto:
cut
 proposals:

 custom-cflags: Build with user-specified CFLAGS (unsupported)
 as custom-cxxflags has been added (w/o discussion here)
cut

I asked it some times ago [1].
I hope we can have custom-c{xx,}flags in global useflags soon

[1] http://comments.gmane.org/gmane.linux.gentoo.devel/46118

-- 
Timothy `Drizzt` Redaelli
FreeSBIE Developer, Gentoo Developer, GUFI Staff
There are two major products that come out of Berkeley: LSD and UNIX.
We don't believe this to be a coincidence.  -- Jeremy S. Anderson


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


Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-24 Thread Luca Barbato

Alistair Bush wrote:


Luca Barbato wrote:

Alistair Bush wrote:

I just don't think those numbers tell us anything and that should be
obvious from anyone who has read GLEP 55[1],  we ain't really attempting
to solve a problem that exists within the tree currently (well the bash
issue does, in a way ). We are trying to solve issues that ware stopping
the tree moving forward.  Lets evaluate GLEP 55 in the problems it is
attempting to solve.

I'm afraid you missed the whole point...

- what is in the proposal is a solution looking for a problem: nobody
updated the glep with the required sections, nobody put up a list of
bugs/rfe from bugzilla it helps to solve. Vague leading to the future
change declaration aren't what I'd expect.



So im mean't to start committing ebuilds into the tree that expect a
certain unimplemented functionality, only to file bugs against portage
for it not supporting them?


Apparently you missed rfe or that it does mean =\


Plus we already know of at least one case where we will encounter a
problem in the future,  why?  because we have already.
Not sure if there is a open bug about it tho.


Do you know that a problem means nothing, bug #number means something?
Do you know that improvement and enhancement can be requested on 
bugzilla as well?



This actually eats at me,  your basically saying GLEP's should only be
reactive.  Why don't we all just roll over and die.


I'm afraid you are getting quite emotional for no reason.


I have already considered the problems, and believe GLEP 55 is the
**best** solution to them.  Is it perfect, no.  But I have yet to see
anything better.


YOU, other did and consider what is proposed on that trash. Mediation is 
needed apparently. What is sure is that the glep proposal is lacking 
lots of details and apparently none of the proponents are even willing 
to try to cope with that.



Yes exactly,  you need to know the EAPI before you __parse__ the ebuild.


You have to extract the eapi before doing the parsing the eapi defines, 
but you can parse the ebuild just to get the eapi and then do something 
or nothing depending on that value...



1)  How about in a flat txt file:   That would become a developers
nightmare.
2)  In an xml file.  Package managers would have to support xml.  Not
the best thing in the world. also could be a nightmare,  adding an entry
for every ebuild.
3)  As an xattr.  Well this idea is novel.  I bet it would make the tree
nice and stable too.  Lets not forget how annoying it will be for devs.
4) Parsing the ebuild.  But what are we parsing?,  lets not limit
ourselves to bash,  we might want to change languages completely.  If it
is bash,  what version, what if EAPI is set multiple times,  what if its
set in an eclass.


What if is exactly something you cannot use, it's a slippery slope 
that leads to qbits frozen objects from the outher space or other insane 
stuff that may or may not happen.



5)  M...On the file name sounds like a good idea.  especially as an
extension.  provides information to a package manager, person,
script/program without them needing to open anything.  identifies the
contents just like .txt, .c, .o, .jpeg, etc


So for normal multimedia file I'd have to have myfile.mov-aac-h264-ass 
 as extension? strange, mplayer is perfectly fine even if it is called 
myfile and file(1) usually can tell me what's inside it in term of 
codec and sometimes even it's params.



- Extracting such information could have different costs depending on
where to place it.


I believe it being on the filename would be the least costly,  in terms
of processor/io at least.


try yourself, I did and that's what I found regarding the case of cache 
regen (that, as I wrote earlier, is the interesting case) is in one of 
the previous emails as well...


btw it's also quite easy plant both proposals in portage and see what 
happen if you really like, but I preferred give something everybody can 
try in bash.


lu

--

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero




Re: [gentoo-dev] Re: bzr.eclass

2009-02-24 Thread Brian Harring
On Mon, Feb 23, 2009 at 08:45:28PM +0100, Christian Faulhammer wrote:
  if [[ ${EBZR_REPO_URI} == */* ]]; then
  repository=${EBZR_REPO_URI}/${EBZR_BRANCH}
  elif [[ -n ${EBZR_BRANCH} ]] ; then
  ...
  else
  ...
  fi
  
  If I see this correctly, this appends EBZR_BRANCH if there is a slash
  in the REPO_URI ... what kind of guess is this supposed to be? I
  think, the second test (append iff EBZR_BRANCH is set) should be
  sufficient.
 
  Not sure, though I will investigate (and likely drop it).

Kindly drop that; the REPO_URI/BRANCH seperation that is in use there 
really isn't all that useful for bzr ebuilds in my experience- more 
often then not it winds up biting me in the ass rather then being 
useful.

My usage (and understanding of bzr), there isn't a scenario where 
seperation of the repo and branch applies- you only need the branch 
uri, that encompasses it all (unlike cvs, where this probably was 
inherited from).

So... any reason to even have the var seperation like that?

~harring


pgp8CQZmktJ1j.pgp
Description: PGP signature


Re: [gentoo-dev] Fwd: News item: Generation 1 deprecation

2009-02-24 Thread Petteri Räty
Jan Kundrát wrote:
 See the patch.
 

applied



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-24 Thread Serkan Kaba
2009/2/24 Ferris McCormick fmc...@gentoo.org

 On Mon, 2009-02-23 at 22:19 +, Ciaran McCreesh wrote:
  On Mon, 23 Feb 2009 16:15:25 -0600
  Ryan Hill dirtye...@gentoo.org wrote:
   Can we ban eclasses from setting EAPI?  Is there any case where it
   would be sane?
 
  It's already banned from a QA perspective, but from a package manager
  perspective people have done it in the past and possibly still do do
  it, and the spec doesn't forbid it.
 

 For what it's worth, no eclass in the gentoo-x86/eclass tree sets EAPI.
 I don't know about anyplace else.

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

lucene-contrib eclass in java-experimental [1] sets EAPI to 1 to use slot
deps. And I think that's a valid usage.

1:
http://overlays.gentoo.org/proj/java/browser/java-experimental/eclass/lucene-contrib.eclass


Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-24 Thread Ciaran McCreesh
On Tue, 24 Feb 2009 08:08:23 +0100
Luca Barbato lu_z...@gentoo.org wrote:
 Is there any technical merit in putting eapi in the file extension
 while we could restrict the format the same way in file and have
 about the same, negligible, performance hit? (I used warm cache since
 you need the file anyway so you don't spend time to look it up twice
 or put it in cache twice)

Uh, your benchmarks are nonsense. That is not how metadata checks work.
By parsing the ebuilds you're talking doubling the number of file reads
required to get the job done, and massively increasing the number of
seeks required.

But that isn't even the main issue. The main issue is that even if you
retroactively pretend that all ebuilds are in a format they're not, and
ignore the breakage, and then wait for a year for package managers to
try to parse your new format, you *still* can't change name or
versioning rules.

Again, these are all things that have been discussed at length
previously. Please either come up with a legitimate technical
objection, or admit that you've seen the light.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-24 Thread Ciaran McCreesh
On Mon, 23 Feb 2009 20:49:02 -0500
Richard Freeman ri...@gentoo.org wrote:
  and it doesn't let you change name or version rules.
 
 Neither does putting the EAPI in the filename as far as I can tell.

Name or versioning rules are things like allowing new suffixes or
altering the restrictions upon formatting.

Currently, package managers assume that they can handle anything named
pkg-$anything.ebuild, and $anything has to be a valid version spec by
the current rules.

Version rules have changed at least twice in the past, and it's been
messy every time. 55 allows version changes to be done safely (although
not carelessly...).

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-24 Thread Richard Freeman

Alistair Bush wrote:

4) Parsing the ebuild.  But what are we parsing?,  lets not limit
ourselves to bash,  we might want to change languages completely.  If it
is bash,  what version, what if EAPI is set multiple times,  what if its
set in an eclass.


How do you do this if you're getting EAPI from the filename?  How do you 
set it multiple times?  How do you set it in an eclass if you're getting 
it from the filename?


It seems like when we're talking about just putting the EAPI in a 
comment line on line x of the ebuild we're barraged with 47 ways that it 
will limit us, but when we're talking about EAPI in the filename 
suddenly we're not concerned with those limitations.  If it helps maybe 
we need to split EAPI into two records - one that deals with how to 
fundamentally parse the file and find out the EAPI, and the other that 
implements everything else the EAPI does.


I will certainly concede that putting it inside the ebuild potentially 
breaks compatibility with existing package managers.  That is certainly 
a downside to this approach.  However, none of the other objections that 
have been raised appear to hold water.  An EAPI in a filename is a blob 
of text that needs to be parsed out in one particular way with one set 
of system calls.  An EAPI embedded in the file is a blob of text that 
needs to be parsed out in one particular way with one set of system calls.


And if backwards compatibility were a serious issue you could define a 
new .ebuild2 file spec that incorporates the EAPI inside the file and 
current package managers would ignore it.  Then you're not changing the 
file extension every time a new EAPI comes along, and the need to do so 
could be handled via future GLEPs.  Or we could just delay 
implementation and clean up existing package managers and tell users to 
migrate.




Re: [gentoo-dev] Re: bash-4.0 regression heads up (escaped semicolons in subshells)

2009-02-24 Thread Daniel Gryniewicz
On Sat, 2009-02-21 at 19:44 -0500, Mike Frysinger wrote:

snip

  
   i'll tweak the eclasses to use quoting for now

 
 no one suggested doing any of this crap you're talking about.  if you want to 
 get all retarded, dont install the masked ebuild.  i gave a heads up to 
 people 
 who might want to experiment so they wouldnt have to figure out weird errors. 
  
 in the mean time, i tweaked a few common files so people wouldnt hit errors 
 and could investigate even further.
 
 i guess in the future i simply wont post heads up so i dont have to listen to 
 people whine about non-existent issues.


I personally took the quoted line above to indicate that changes would
be made to the tree.  I can understand how confusion would occur.

Dan




Re: [gentoo-dev] Re: bash-4.0 regression heads up (escaped semicolons in subshells)

2009-02-24 Thread Mike Frysinger
On Tuesday 24 February 2009 10:52:55 Daniel Gryniewicz wrote:
 On Sat, 2009-02-21 at 19:44 -0500, Mike Frysinger wrote:
i'll tweak the eclasses to use quoting for now
 
  no one suggested doing any of this crap you're talking about.  if you
  want to get all retarded, dont install the masked ebuild.  i gave a heads
  up to people who might want to experiment so they wouldnt have to figure
  out weird errors. in the mean time, i tweaked a few common files so
  people wouldnt hit errors and could investigate even further.
 
  i guess in the future i simply wont post heads up so i dont have to
  listen to people whine about non-existent issues.

 I personally took the quoted line above to indicate that changes would
 be made to the tree.

that's because i did make changes to the tree.  for now.  temporal clauses 
change the meaning significantly which is why the whole sentence needs to be 
digested rather than scraping a few bits.
-mike



Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-24 Thread Ciaran McCreesh
On Tue, 24 Feb 2009 10:46:30 -0500
Richard Freeman ri...@gentoo.org wrote:
 I will certainly concede that putting it inside the ebuild
 potentially breaks compatibility with existing package managers.
 That is certainly a downside to this approach.  However, none of the
 other objections that have been raised appear to hold water.

...and it means we can't change name or version rules.

...and it means over doubling the best possible time to work out a
dependency tree in the common case where the metadata cache is valid.

...and it means we can't make arbitrary format changes.

 And if backwards compatibility were a serious issue you could define
 a new .ebuild2 file spec that incorporates the EAPI inside the file
 and current package managers would ignore it.  Then you're not
 changing the file extension every time a new EAPI comes along, and
 the need to do so could be handled via future GLEPs.

Developers already have to stop and think and consult the conveniently
available table of features for EAPIs. By splitting the EAPI concept in
two you're doubling the amount of data to be learnt.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-24 Thread Luca Barbato

Ciaran McCreesh wrote:

On Tue, 24 Feb 2009 08:08:23 +0100
Uh, your benchmarks are nonsense.


Provide your nonsensical ones.


That is not how metadata checks work.


Explain how they work, regen works that way...


By parsing the ebuilds you're talking doubling the number of file reads
required to get the job done, and massively increasing the number of
seeks required.


Apparently it doesn't impact anything.


But that isn't even the main issue. The main issue is that even if you
retroactively pretend that all ebuilds are in a format they're not, and
ignore the breakage, and then wait for a year for package managers to
try to parse your new format, you *still* can't change name or
versioning rules.


why? when portage would breanch if I put an ebuild with a wacky version 
AND there is a valid cache for that telling its eapi 99 ?



Again, these are all things that have been discussed at length
previously. Please either come up with a legitimate technical
objection, or admit that you've seen the light.


the glep doesn't show any of those nor reference to it, as I said 
before, do your homework and probably more people will be happier with 
your proposals.


lu

--

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero




Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-24 Thread Ciaran McCreesh
On Tue, 24 Feb 2009 17:04:28 +0100
Luca Barbato lu_z...@gentoo.org wrote:
 Ciaran McCreesh wrote:
  On Tue, 24 Feb 2009 08:08:23 +0100
  Uh, your benchmarks are nonsense.
 
 Provide your nonsensical ones.

You're doubling the number of files that have to be read for an
operation that's almost purely i/o bound. On top of that, you're
introducing a whole bunch of disk seeks in what's otherwise a nice
linear operation.

  That is not how metadata checks work.
 
 Explain how they work, regen works that way...

If metadata is valid, ebuilds aren't opened at all. An optimal
implementation can slurp up the entire directory in one go and then
start pulling out cache entries as it needs them, not having to go back
to the ebuild directory or read its contents at all. Then it can open
and read cache files in a carefully selected order to avoid having to
do any more opens than necessary.

  By parsing the ebuilds you're talking doubling the number of file
  reads required to get the job done, and massively increasing the
  number of seeks required.
 
 Apparently it doesn't impact anything.

Please show the patch you created (for Paludis, since Portage doesn't
yet do a lot of the optimisations it could here) that demonstrates this.

  But that isn't even the main issue. The main issue is that even if
  you retroactively pretend that all ebuilds are in a format they're
  not, and ignore the breakage, and then wait for a year for package
  managers to try to parse your new format, you *still* can't change
  name or versioning rules.
 
 why? when portage would breanch if I put an ebuild with a wacky
 version AND there is a valid cache for that telling its eapi 99 ?

Because it has to parse that version. Also, the package manager can't
tell whether or not a cache entry is valid if it doesn't recognise the
EAPI in the cache entry.

  Again, these are all things that have been discussed at length
  previously. Please either come up with a legitimate technical
  objection, or admit that you've seen the light.
 
 the glep doesn't show any of those nor reference to it, as I said 
 before, do your homework and probably more people will be happier
 with your proposals.

Why should it? The C++ standard doesn't explain why you should use it
instead of Java...

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-24 Thread Joe Peterson
Richard Freeman wrote:
 I still don't see why we need to be encoding metadata in filenames.

Correct.  GLEP 55 tries to solve a technical implementation issue by
exposing meta data in the filename.  Extremely bad form/design, IMHO.

 PERL doesn't care what a file extension is, python doesn't care, bzip2 
 doesn't care, tar doesn't care, gzip doesn't care, and even ld-linux.so 
 doesn't care.  I'm sure that in at least some of these cases they end up 
 parsing parts of the file twice - once to figure out what it is, and the 
 second time to actually handle it.  I'm actually hard pressed to think 
 of any unix-based software that uses the filename to store a mandatory 
 file format versioning specifier of some kind.

All good points.  I cannot believe there exists no other way to solve
this technical issue other than resorting to such a non-Unix-like idea.
Obviously all of the software packages cited above endeavor to avoid
such nastiness.

I do not understand why anyone is willing to accept putting version info
in the filename/extension.  It is inelegant and, frankly, very ugly.  I
have written more in the past on why I think it is a terrible idea, so I
won't repeat it here.

Suffice to say, if something like GLEP 55 is implemented, I will lose a
lot of faith in Gentoo's design, so much so that I will likely join the
ranks of those who abandon it, not only as a dev, but also as a user.

 This seems to me to be a solved problem.  You put a header in a file 
 that tells you how to read the file.  Headers are split into fields and 
 if a program doesn't know what to do with a field it ignores it (or if 
 the header so instructs it doesn't even try to parse the file).  This 
 should be easy to do and keep the file bash-compatible.  Just stick a 
 comment line close to the top of the file and put whatever you want on 
 it.  You could also stick something in metadata.xml (although this makes 
 working with ebuilds outside of a repository more difficult).  You run 
 the file through an algorithm to find out what the EAPI is, and then 
 source it if appropriate.
 
 Sure, if you make some major change analogous to switching from the .rpm 
 to the .deb package format then maybe an extension change would make 
 sense.  But, why expose the inner workings of the package file format to 
 the filesystem?

+100

-Joe



Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-24 Thread Alec Warner
Somewhat ironically, had everyone been less stubborn last year when
discussing this topic we could have embedded the EAPI in line X of the
ebuild in 2008 and be using it now; instead of still discussing it.

I don't expect new novel ideas out of this thread.  I expect the
council to defer it again because the arguments are the same as last
time and last time they were not convincing enough.  I would prefer if
the council went one way or the other so that when we are arguing
about this in 2010 we can at least say hey we have support in
$PACKAGE_MANAGERs for EAPI on line X since May 2009 so in 3 months we
can just switch.  We don't have to make the switch; I'm just saying we
should add support to hedge our bets.

Thoughts?

-A



Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-24 Thread Ciaran McCreesh
On Tue, 24 Feb 2009 09:15:59 -0700
Joe Peterson lava...@gentoo.org wrote:
 Richard Freeman wrote:
  I still don't see why we need to be encoding metadata in filenames.
 
 Correct.  GLEP 55 tries to solve a technical implementation issue by
 exposing meta data in the filename.  Extremely bad form/design, IMHO.

We already expose metadata in the filename. The version's there and the
name's there.

 All good points.  I cannot believe there exists no other way to solve
 this technical issue other than resorting to such a non-Unix-like
 idea. Obviously all of the software packages cited above endeavor to
 avoid such nastiness.

Then why don't you come up with a viable solution?

 I do not understand why anyone is willing to accept putting version
 info in the filename/extension.  It is inelegant and, frankly, very
 ugly.  I have written more in the past on why I think it is a
 terrible idea, so I won't repeat it here.

For the same reason they're willing to accept the package name and
version in the filename.

 Suffice to say, if something like GLEP 55 is implemented, I will lose
 a lot of faith in Gentoo's design, so much so that I will likely join
 the ranks of those who abandon it, not only as a dev, but also as a
 user.

If you paint the bikeshed, I shall throw my toys out of the pram and
run off crying..

Why don't you propose a viable alternative instead of making threats?

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-24 Thread Ciaran McCreesh
On Tue, 24 Feb 2009 08:21:25 -0800
Alec Warner anta...@gentoo.org wrote:
 Somewhat ironically, had everyone been less stubborn last year when
 discussing this topic we could have embedded the EAPI in line X of the
 ebuild in 2008 and be using it now; instead of still discussing it.

...and we wouldn't be able to change the version rules, and we would be
suffering a substantial performance hit.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-24 Thread Joe Peterson
Richard Freeman wrote:
 The dynamic linker doesn't need to consult the filename to figure out 
 how to parse a shared object.  It only consults the filename to figure 
 out which shared object is needed.  That is actually analogous to 
 putting the package name/version in the ebuild filename.

Right.  Plus, if the linker *did* consult the filename, imagine what
would happen if someone renamed the file (even by accident) and changed
the version?  The parser should not be able to be so easily fooled -
could cause great confusion and or nasty and weird bugs - seems very
fragile to me.  Having the version *in* the file is much safer, since
monkeying with that would require editing it the file, rather than
renaming it.

-Joe



Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-24 Thread Ciaran McCreesh
On Tue, 24 Feb 2009 09:24:48 -0700
Joe Peterson lava...@gentoo.org wrote:
 Right.  Plus, if the linker *did* consult the filename, imagine what
 would happen if someone renamed the file (even by accident) and
 changed the version?  The parser should not be able to be so easily
 fooled - could cause great confusion and or nasty and weird bugs -
 seems very fragile to me.  Having the version *in* the file is much
 safer, since monkeying with that would require editing it the file,
 rather than renaming it.

You could use the same absurd argument to say that PN and PV shouldn't
be in the filename...

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-24 Thread Alec Warner
On Tue, Feb 24, 2009 at 8:23 AM, Ciaran McCreesh
ciaran.mccre...@googlemail.com wrote:
 On Tue, 24 Feb 2009 08:21:25 -0800
 Alec Warner anta...@gentoo.org wrote:
 Somewhat ironically, had everyone been less stubborn last year when
 discussing this topic we could have embedded the EAPI in line X of the
 ebuild in 2008 and be using it now; instead of still discussing it.

 ...and we wouldn't be able to change the version rules, and we would be
 suffering a substantial performance hit.

Hey I never said its a perfect solution; but I'm a fan of the 'it
covers 80%'.   Sometimes you can't have your cake and eat it too;
sometimes requirements get dropped.

-A


 --
 Ciaran McCreesh




Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-24 Thread Joe Peterson
Ciaran McCreesh wrote:
 On Tue, 24 Feb 2009 09:24:48 -0700
 Joe Peterson lava...@gentoo.org wrote:
 Right.  Plus, if the linker *did* consult the filename, imagine what
 would happen if someone renamed the file (even by accident) and
 changed the version?  The parser should not be able to be so easily
 fooled - could cause great confusion and or nasty and weird bugs -
 seems very fragile to me.  Having the version *in* the file is much
 safer, since monkeying with that would require editing it the file,
 rather than renaming it.
 
 You could use the same absurd argument to say that PN and PV shouldn't
 be in the filename...

No...!

They are needed because:

1) versions of the *content*, not the *format* are needed for uniqueness
2) it makes sense to have these in the filename, but not internal meta-data



Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-24 Thread Nirbheek Chauhan
On Tue, Feb 24, 2009 at 9:26 PM, Ciaran McCreesh
ciaran.mccre...@googlemail.com wrote:
 ...and it means we can't change name or version rules.


And has such a case come to light recently where it was *essential* to
do so? Why solve problems that don't exist?

 ...and it means over doubling the best possible time to work out a
 dependency tree in the common case where the metadata cache is valid.


This is a valid cause. Perhaps the only valid cause.

 ...and it means we can't make arbitrary format changes.


What? Why are we over-engineering this? Does anyone seriously want to
convert ebuilds to XML? I honestly think anything beyond incremental
changes is not relevant for Gentoo

 Developers already have to stop and think and consult the conveniently
 available table of features for EAPIs. By splitting the EAPI concept in
 two you're doubling the amount of data to be learnt.


That's a documentation problem.


-- 
~Nirbheek Chauhan



Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-24 Thread Ciaran McCreesh
On Tue, 24 Feb 2009 08:33:19 -0800
Alec Warner anta...@gentoo.org wrote:
 Hey I never said its a perfect solution; but I'm a fan of the 'it
 covers 80%'.   Sometimes you can't have your cake and eat it too;
 sometimes requirements get dropped.

We can cover 100% with a solution with less of an impact. There's no
need to compromise here.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-24 Thread Alec Warner
On Tue, Feb 24, 2009 at 8:37 AM, Ciaran McCreesh
ciaran.mccre...@googlemail.com wrote:
 On Tue, 24 Feb 2009 08:33:19 -0800
 Alec Warner anta...@gentoo.org wrote:
 Hey I never said its a perfect solution; but I'm a fan of the 'it
 covers 80%'.   Sometimes you can't have your cake and eat it too;
 sometimes requirements get dropped.

 We can cover 100% with a solution with less of an impact. There's no
 need to compromise here.

Two years to argue and implement a solution certainly shouts compromise to me.

-A


 --
 Ciaran McCreesh




Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-24 Thread Ciaran McCreesh
On Tue, 24 Feb 2009 09:36:29 -0700
Joe Peterson lava...@gentoo.org wrote:
  You could use the same absurd argument to say that PN and PV
  shouldn't be in the filename...
 
 No...!
 
 They are needed because:
 
 1) versions of the *content*, not the *format* are needed for
 uniqueness

So why's PN in there then?

 2) it makes sense to have these in the filename, but not
 internal meta-data

For those of us who understand the process, it makes sense to have EAPI
in the filename too.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-24 Thread Ciaran McCreesh
On Tue, 24 Feb 2009 21:59:39 +0530
Nirbheek Chauhan nirbh...@gentoo.org wrote:
 On Tue, Feb 24, 2009 at 9:26 PM, Ciaran McCreesh
 ciaran.mccre...@googlemail.com wrote:
  ...and it means we can't change name or version rules.
 
 And has such a case come to light recently where it was *essential* to
 do so? Why solve problems that don't exist?

Because they do exist, which is why name and version rules have been
changed the hard way at least twice previously. The version format is
still considerably less flexible than what upstreams use, and a lot of
the current limitations on its format are purely historical.

  ...and it means we can't make arbitrary format changes.
 
 What? Why are we over-engineering this? Does anyone seriously want to
 convert ebuilds to XML? I honestly think anything beyond incremental
 changes is not relevant for Gentoo

You appear to be confusing arbitrary format changes with doing a Zynot.
The two are not the same.

  Developers already have to stop and think and consult the
  conveniently available table of features for EAPIs. By splitting
  the EAPI concept in two you're doubling the amount of data to be
  learnt.
 
 That's a documentation problem.

No, it's a design problem. Good design looks for ways to minimise the
amount of unnecessary arbitrary information the user has to remember.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-24 Thread Ciaran McCreesh
On Tue, 24 Feb 2009 09:45:44 -0700
Joe Peterson lava...@gentoo.org wrote:
  Then why don't you come up with a viable solution?
 
 I already have - look back at my posts; very similar to Rich0's idea.

No, I said viable.

 And I tire of the argument that if one doesn't have a perfect solution
 now, we should adopt a half-brained one.  The point of this is to spur
 discussion to come up with a better solution.

We have a perfect solution.

  For the same reason they're willing to accept the package name and
  version in the filename.
 
 The fact that you think this is the same thing as having the EAPI in
 the filename is odd.

PN and PV are metadata, same as EAPI.

  If you paint the bikeshed, I shall throw my toys out of the pram
  and run off crying..
  
  Why don't you propose a viable alternative instead of making
  threats?
 
 Not a threat.  And this will be my last post on the topic.  I will not
 take your bate and continue to argue, creating more noise on this
 list - I've expressed how I feel.

This isn't about how you feel. It's about what you rationally think,
based upon a full understanding of the issues at hand.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-24 Thread Ciaran McCreesh
On Tue, 24 Feb 2009 08:42:44 -0800
Alec Warner anta...@gentoo.org wrote:
 On Tue, Feb 24, 2009 at 8:37 AM, Ciaran McCreesh
 ciaran.mccre...@googlemail.com wrote:
  On Tue, 24 Feb 2009 08:33:19 -0800
  Alec Warner anta...@gentoo.org wrote:
  Hey I never said its a perfect solution; but I'm a fan of the 'it
  covers 80%'.   Sometimes you can't have your cake and eat it too;
  sometimes requirements get dropped.
 
  We can cover 100% with a solution with less of an impact. There's no
  need to compromise here.
 
 Two years to argue and implement a solution certainly shouts
 compromise to me.

Strange. To me it shouts leadership problem.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-24 Thread Ciaran McCreesh
On Tue, 24 Feb 2009 12:25:27 -0500
Jim Ramsay l...@gentoo.org wrote:
  ...and it means we can't change name or version rules.
  
  ...and it means over doubling the best possible time to work out a
  dependency tree in the common case where the metadata cache is
  valid.
  
  ...and it means we can't make arbitrary format changes.
 
 Those would all land in the category of backwards compatibility
 mentioned below, as they would all break current sourcing rules.

No, they're also future issues. Without glep 55, every time they come
up we have to go through the whole mess again.

  Developers already have to stop and think and consult the
  conveniently available table of features for EAPIs. By splitting
  the EAPI concept in two you're doubling the amount of data to be
  learnt.
  
 I would think that this is a very small cost, and the benefit would be
 (I hope) that more people would agree on the solution and then we can
 go forward. Is that not a valid consideration?

I'd expect to see changes that would warrant a major bump in every
other EAPI or so anyway, so it's not really worth the complexity.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-24 Thread Ciaran McCreesh
On Tue, 24 Feb 2009 18:16:54 +0100
Luca Barbato lu_z...@gentoo.org wrote:
  You're doubling the number of files that have to be read for an
  operation that's almost purely i/o bound. On top of that, you're
  introducing a whole bunch of disk seeks in what's otherwise a nice
  linear operation.
 
 I see words, not numbers.

Number: double. That's a '2 times'.

  That is not how metadata checks work.
  Explain how they work, regen works that way...
  
  If metadata is valid, ebuilds aren't opened at all. An optimal
  implementation can slurp up the entire directory in one go and then
  start pulling out cache entries as it needs them, not having to go
  back to the ebuild directory or read its contents at all. Then it
  can open and read cache files in a carefully selected order to
  avoid having to do any more opens than necessary.
 
 So? if the cache is valid then you don't have to source them at all.
 If you have to regen it, well you have to read everything.

You don't know whether the cache is valid until you know the EAPI. It
only works currently because EAPIs don't change inherit behaviour.

  By parsing the ebuilds you're talking doubling the number of file
  reads required to get the job done, and massively increasing the
  number of seeks required.
  Apparently it doesn't impact anything.
  
  Please show the patch you created (for Paludis, since Portage
  doesn't yet do a lot of the optimisations it could here) that
  demonstrates this.
 
 Paludis isn't portage.

So you have patches for Portage? Please show them.

  But that isn't even the main issue. The main issue is that even if
  you retroactively pretend that all ebuilds are in a format they're
  not, and ignore the breakage, and then wait for a year for package
  managers to try to parse your new format, you *still* can't change
  name or versioning rules.
  why? when portage would breanch if I put an ebuild with a wacky
  version AND there is a valid cache for that telling its eapi 99 ?
 
  Because it has to parse that version. Also, the package manager
  can't tell whether or not a cache entry is valid if it doesn't
  recognise the EAPI in the cache entry.
 
 unknown isn't unsupported?

Huh? Please explain what you mean.

  Again, these are all things that have been discussed at length
  previously. Please either come up with a legitimate technical
  objection, or admit that you've seen the light.
  the glep doesn't show any of those nor reference to it, as I said 
  before, do your homework and probably more people will be happier
  with your proposals.
  
  Why should it? The C++ standard doesn't explain why you should use
  it instead of Java...
 
 In fact many people do wonderful things with java and many more just
 do over engineered mess with C++?

Your trolling is going rapidly downhill.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature