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

[Tiziano Müller]

Am Dienstag, den 24.02.2009, 22:58 + schrieb Ciaran McCreesh:
> On Tue, 24 Feb 2009 23:48:27 +0100
> Luca Barbato  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.
> 
Well, you could theoretical consider everything in the cache valid
within the current scope, find the eapi within the cache or the ebuild
and then reconsider things.
But the problem with this approach (besides performance, etc.) is that
it is not possible to make a pm robust enough to not fail completely
when parsing the cache entry.

The point is: Since the cache format is part of the eapi (since we store
eapi-dependant information in there), the eapi must be known before
parsing the cache data.

Would it be possible to change the cache-format with with G55?
Meaning: Have the current cache-format for the current *.ebuild and
another for *.ebuild-N (where I mean by cache-format the contents of the
cache-files)?



signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

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

[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] Collecting opinions about GLEP 55 and alternatives

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

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

[Jeroen Roovers]

On Wed, 25 Feb 2009 00:21:23 +0200
Petteri Räty  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

[Alec Warner]

> On Tue, Feb 24, 2009 at 2:21 PM, 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-
>- ignored by current Portage
>  b) ..ebuild
>- current Portage does not work with this
>  c) ..
>- 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) 
>  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

[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-
> - ignored by current Portage
>   b) ..ebuild
> - current Portage does not work with this
>   c) ..
> - 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) 
>   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

[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-
> - ignored by current Portage
>   b) ..ebuild
> - current Portage does not work with this
>   c) ..
> - 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) 

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] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

[Luca Barbato]

Ciaran McCreesh wrote:

On Tue, 24 Feb 2009 18:16:54 +0100
Luca Barbato  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

[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-
- ignored by current Portage
  b) ..ebuild
- current Portage does not work with this
  c) ..
- 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) 
  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

[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

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

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

[Ryan Hill]

On Wed, 25 Feb 2009 00:21:23 +0200
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-
> - 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) ..ebuild
> - current Portage does not work with this

#2

>   c) ..
> - 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) 
>   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] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

[Ciaran McCreesh]

On Tue, 24 Feb 2009 23:48:27 +0100
Luca Barbato  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

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

[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] Collecting opinions about GLEP 55 and alternatives

[Ferris McCormick]

On Wed, 25 Feb 2009 00:21:23 +0200
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-
> - 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) ..ebuild
> - current Portage does not work with this
>   c) ..
> - 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) 

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) 
Developer, Gentoo Linux (Sparc, Userrel, Trustees)


signature.asc
Description: PGP signature

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

[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

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

[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-
- ignored by current Portage
  b) ..ebuild
- current Portage does not work with this
  c) ..
- 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) 
  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] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

[Ciaran McCreesh]

On Tue, 24 Feb 2009 22:11:47 +
Roy Bamford  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

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

[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  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] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

[Ciaran McCreesh]

On Tue, 24 Feb 2009 22:46:17 +0100
Luca Barbato  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] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

[Luca Barbato]

Ciaran McCreesh wrote:

On Tue, 24 Feb 2009 15:17:01 -0500
Richard Freeman  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] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

[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] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

[Ciaran McCreesh]

On Tue, 24 Feb 2009 21:17:57 +
Roy Bamford  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)

[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] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

[Jim Ramsay]

Ciaran McCreesh  wrote:
> On Tue, 24 Feb 2009 15:37:36 -0500
> Jim Ramsay  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] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

[Ciaran McCreesh]

On Tue, 24 Feb 2009 15:37:36 -0500
Jim Ramsay  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] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

[Robert Bridge]

Ciaran McCreesh wrote:
> On Tue, 24 Feb 2009 09:36:29 -0700
> Joe Peterson  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)

[Jim Ramsay]

Ciaran McCreesh  wrote:
> On Tue, 24 Feb 2009 15:07:29 -0500
> Jim Ramsay  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] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

[Ciaran McCreesh]

On Tue, 24 Feb 2009 15:17:01 -0500
Richard Freeman  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)

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

[Ciaran McCreesh]

On Tue, 24 Feb 2009 15:07:29 -0500
Jim Ramsay  wrote:
> Ciaran McCreesh  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)

[Jim Ramsay]

Ciaran McCreesh  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)

[Ciaran McCreesh]

On Tue, 24 Feb 2009 20:28:43 +0100
Alexis Ballier  wrote:
> On Tue, 24 Feb 2009 18:24:16 +
> Ciaran McCreesh  wrote:
> > On Tue, 24 Feb 2009 18:16:54 +0100
> > Luca Barbato  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)

[Alexis Ballier]

On Tue, 24 Feb 2009 18:24:16 +
Ciaran McCreesh  wrote:

> On Tue, 24 Feb 2009 18:16:54 +0100
> Luca Barbato  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)

[Ciaran McCreesh]

On Tue, 24 Feb 2009 14:08:45 -0500
Jim Ramsay  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)

[Jim Ramsay]

Ciaran McCreesh  wrote:
> On Tue, 24 Feb 2009 12:25:27 -0500
> Jim Ramsay  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

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

[Ryan Hill]

Alec Warner  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] Gentoo Council Reminder for February 26

[Santiago M. Mola]

On Tue, Feb 24, 2009 at 6:47 PM, Brian Harring  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

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

[Ciaran McCreesh]

On Tue, 24 Feb 2009 18:16:54 +0100
Luca Barbato  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

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

[Ciaran McCreesh]

On Tue, 24 Feb 2009 12:25:27 -0500
Jim Ramsay  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] Gentoo Council Reminder for February 26

[Brian Harring]

On Sun, Feb 22, 2009 at 11:26:48PM -0800, 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) !

Informal request, but it would be useful to get an idea of the 
councils views on portage overlay compatibility issues.

Specifically, when it comes to gentoo repositories, there is one, and 
only one definition of what that is- pms's repo spec.  The problem 
here is that the only repository truly conformant to that spec is 
gentoo-x86, for the rest of the repositories (overlays realistically) 
whatever portage supports seems to be the eventual standard they grow 
towards.

Problem with this is that there is *zero* way to spot these non-pms 
repositories as it stands.  Simplest example, under portage overlays 
can unmask pkgs globally (gnome overlay reverting masks in 
gentoo-x86), package.unmask exists/works, package.keywords 
exists/works, and package.mask can be a directory.

I've not traced through the mess of config's __init__ to verify 
*every* pms noncompliance there, but I'd assume there are definitely a 
couple more hanging around to blow up in alt managers faces.

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.

Either way, I'd be curious about the councils *informal* opinion on 
the overlay issue.

thanks,
~harring


pgpFTL9Srx0V9.pgp
Description: PGP signature

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

[Jim Ramsay]

Ciaran McCreesh  wrote:
> On Tue, 24 Feb 2009 10:46:30 -0500
> Richard Freeman  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.

Those would all land in the category of "backwards compatibility"
mentioned below, as they would all break current sourcing rules.

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

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

[Luca Barbato]

Ciaran McCreesh wrote:

On Tue, 24 Feb 2009 17:04:28 +0100
Luca Barbato  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.


I see words, not numbers.


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.



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.


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?


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

lu

--

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

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

[Ciaran McCreesh]

On Tue, 24 Feb 2009 08:42:44 -0800
Alec Warner  wrote:
> On Tue, Feb 24, 2009 at 8:37 AM, Ciaran McCreesh
>  wrote:
> > On Tue, 24 Feb 2009 08:33:19 -0800
> > Alec Warner  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] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

[Ciaran McCreesh]

On Tue, 24 Feb 2009 09:45:44 -0700
Joe Peterson  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] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

[Ciaran McCreesh]

On Tue, 24 Feb 2009 21:59:39 +0530
Nirbheek Chauhan  wrote:
> On Tue, Feb 24, 2009 at 9:26 PM, Ciaran McCreesh
>  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)

[Joe Peterson]

Ciaran McCreesh wrote:
>> 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 already have - look back at my posts; very similar to Rich0's idea.
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.

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

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

-Joe

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

[Ciaran McCreesh]

On Tue, 24 Feb 2009 09:36:29 -0700
Joe Peterson  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] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

[Alec Warner]

On Tue, Feb 24, 2009 at 8:37 AM, Ciaran McCreesh
 wrote:
> On Tue, 24 Feb 2009 08:33:19 -0800
> Alec Warner  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)

[Ciaran McCreesh]

On Tue, 24 Feb 2009 08:33:19 -0800
Alec Warner  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] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

[Nirbheek Chauhan]

On Tue, Feb 24, 2009 at 9:26 PM, Ciaran McCreesh
 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)

[Joe Peterson]

Ciaran McCreesh wrote:
> On Tue, 24 Feb 2009 09:24:48 -0700
> Joe Peterson  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] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

[Alec Warner]

On Tue, Feb 24, 2009 at 8:23 AM, Ciaran McCreesh
 wrote:
> On Tue, 24 Feb 2009 08:21:25 -0800
> Alec Warner  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)

[Ciaran McCreesh]

On Tue, 24 Feb 2009 09:24:48 -0700
Joe Peterson  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)

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

[Ciaran McCreesh]

On Tue, 24 Feb 2009 08:21:25 -0800
Alec Warner  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)

[Ciaran McCreesh]

On Tue, 24 Feb 2009 09:15:59 -0700
Joe Peterson  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)

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

[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] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

[Ciaran McCreesh]

On Tue, 24 Feb 2009 17:04:28 +0100
Luca Barbato  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] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

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

[Ciaran McCreesh]

On Tue, 24 Feb 2009 10:46:30 -0500
Richard Freeman  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] Re: bash-4.0 regression heads up (escaped semicolons in subshells)

[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] Re: bash-4.0 regression heads up (escaped semicolons in subshells)

[Daniel Gryniewicz]

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.  I can understand how confusion would occur.

Dan

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

[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: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

[Ciaran McCreesh]

On Mon, 23 Feb 2009 20:49:02 -0500
Richard Freeman  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)

[Ciaran McCreesh]

On Tue, 24 Feb 2009 08:08:23 +0100
Luca Barbato  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)

[Serkan Kaba]

2009/2/24 Ferris McCormick 

> On Mon, 2009-02-23 at 22:19 +, Ciaran McCreesh wrote:
> > On Mon, 23 Feb 2009 16:15:25 -0600
> > Ryan Hill  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) 
> 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] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

[Ferris McCormick]

On Mon, 2009-02-23 at 22:19 +, Ciaran McCreesh wrote:
> On Mon, 23 Feb 2009 16:15:25 -0600
> Ryan Hill  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) 
Developer, Gentoo Linux (Sparc, Userrel, Trustees)


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

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

[Petteri Räty]

Jan Kundrát wrote:
> See the patch.
> 

applied



signature.asc
Description: OpenPGP digital signature

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

[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] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

[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] [RFC] global useflags

[Timothy Redaelli]

Il martedì 24 febbraio 2009 00:00:26 Markus Meier ha scritto:

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


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)

[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] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

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

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

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

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