[gentoo-dev] Council meeting summary for 10 July 2008

[gentoo-dev] Council meeting summary for 10 July 2008

[Donnie Berkholz]

[-- Attachment #1.1: Type: text/plain, Size: 254 bytes --]

Hi all,

Here is the summary from Thursday's council meeting. The complete log 
will show up at http://www.gentoo.org/proj/en/council/ shortly.

-- 
Thanks,
Donnie

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

[-- Attachment #1.2: 20080710-summary.txt --]
[-- Type: text/plain, Size: 4680 bytes --]

Quick summary
=============

GLEP 54: There were numerous questions that apparently were not brought 
         up on the mailing list in advance or were not addressed.

GLEP 55: On hold pending a concrete requirement for it. GLEP 54 may be, 
         but that's unclear until it's been revised.

GLEP 56: Approved. Cardoe will get repoman changes made, followed by a 
         server-side script to generate use.local.desc from 
         metadata.xml.


The meeting wrapped up in under 1 hour again. We still need to work 
harder to push more discussion and questions to the mailing list, 
though.


Topics
======

GLEP 54
-------
Preparation: Post your opinion to the -dev thread "A few questions to 
our nominees" 4+ hours before the meeting.

Last month: 
	dberkholz: http://archives.gentoo.org/gentoo-dev/msg_c6e4ba8293f50c1e0444e67d59cf85ea.xml
	lu_zero: http://archives.gentoo.org/gentoo-dev/msg_05614741b3942bfdfb21fd8ebb7955e0.xml

Goal: Status check at meeting to see who's ready to vote. Vote on-list 
no later than July 17.

<Betelgeuse@> dberkholz: with GLEP 55 EAPI X can add the support for scm
<Betelgeuse@> dberkholz: and older Portage versions work just fine

<Betelgeuse@> dberkholz: In general I oppose adding things to EAPI 0

<   lu_zero@> dberkholz problem: if you have -scm installed
<   lu_zero@> and then switch to a pm not knowing it
<   lu_zero@> you have a nice recipe for inconsistency

<   Halcy0n@> I would really like to see a list of features that we would 
                    end up having after implementing this GLEP.  The GLEP 
                    mentions possible enhancements, but I'd like to see what we 
                    would have planned if we go forward with this change.
<   Halcy0n@> Well, it only mentions one enhancement, I'd like to see 
                    what else we could do to judge if it is worth it.
Halcy0n@> Betelgeuse: yes, I know there are some things we could do,
                    but I'd like to see a more extensive list of possibilities, 
                    what are other possible ways of doing this (like a metadata 
                    tag for the ebuild), and why those other methods aren't 
                    sufficient.

< dberkholz@> i think the point here is that the glep should address what 
                    made its implementation superior to other possible ones, 
                    which it also describes

< dberkholz@> ok, i've noted the issues raised here
< dberkholz@> once they're address, the glep can be revised and we'll 
                    consider it again

Summary: Specific questions and requests are above.


GLEP 55
-------
Preparation: Post your opinion to the -dev thread "GLEP 55" 4+ hours 
before the meeting.

Last month:
	dberkholz: http://archives.gentoo.org/gentoo-dev/msg_c6e4ba8293f50c1e0444e67d59cf85ea.xml

Goal: Status check at meeting to see who's ready to vote. Vote on-list 
once we're ready.

<Betelgeuse@> But I don't see the use of accepting it before we a) 
                    Portage has something that would make use of it b) some 
                    other pkg manager is made official
<   Halcy0n@> So, can we vote on postponing a GLEP of this nature until 
                    another glep requires such changes?

Summary: On hold pending a concrete requirement for it. GLEP 54 may be, 
but that's unclear until it's been revised.


GLEP 56
-------
Preparation: Post your opinion to the -dev thread "[GLEP56] USE flag 
descriptions in metadata" 4+ hours before the meeting. (Cardoe: Did the 
requested updates ever get made?)

Last month:
	dberkholz: http://archives.gentoo.org/gentoo-dev/msg_54ee20d2b1d8122370afdd4b3d7aafc9.xml

Goal: Status check at meeting to see who's ready to vote. Vote on-list 
no later than July 17, if requested changes are made.

Requested changes were made: 
http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/glep/glep-0056.txt?r1=1.1&r2=1.2

<    Cardoe > Well the first step of making that portion happen is going 
                    to be to add a check to repoman that if use.local.desc is 
                    not present in the repo, do new QA check.
<    Cardoe > Once that's in place that developers can use, then the 
                    infra script will happen.
<    Cardoe > I've already discussed it with the Portage folks and the 
                    infra folks.

Summary: Approved.


Roll call
=========

(here, proxy [by whom] or slacker?)

betelgeuse  here
dberkholz   here
dertobi123  here
flameeyes   here
halcy0n     here
jokey       here
lu_zero     here

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

Re: [gentoo-dev] Council meeting summary for 10 July 2008

[Marius Mauch]

On Sun, 13 Jul 2008 00:11:18 -0700
Donnie Berkholz <dberkholz@gentoo.org> wrote:

> <Betelgeuse@> dberkholz: with GLEP 55 EAPI X can add the support for
> scm 
> <Betelgeuse@> dberkholz: and older Portage versions work just fine

I thought we established that EAPI (no matter how it's defined) only
controls ebuild _contents_ ...

Marius
-- 
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] Re: [gentoo-dev-announce] Council meeting summary for 10 July 2008

[Doug Goldstein]

Donnie Berkholz wrote:
> Hi all,
> 
> Here is the summary from Thursday's council meeting. The complete log 
> will show up at http://www.gentoo.org/proj/en/council/ shortly.
> 
> 

With regard to GLEP 56. I've posted the necessary DTD changes, some 
documentation changes (the old documentation patches need to be updated 
to whats currently in CVS because some commits occurred between when 
they were created and now), and the repoman patches to the bug [1].

My patches to repoman have already been committed to Portage trunk so 
they'll appear in 2.2_rc2. pkgcore is being updated this weekend for 
pcheck to support the new syntax according to ferringb. No one has 
gotten back to me on paludis so I'm not sure about that status.

With regard to the DTD, it's a small change to allow the <cat> tag, the 
rest are there already. As far as the docs team knows, neysx is the only 
one that can commit to them. He's gone until September. So we might need 
someone from infra to give another doc's team member the access to make 
that commit.

Betelgeuse is committing the documentation patches as I update them for 
the Gentoo Development Handbook. Halcy0n made a few requested updates to 
the Gentoo Developer Manual. So that front is moving forward well.

I'll be working with robbat2 when he gets some free time this week on 
getting the infra script I hacked up in place.

All and all I'd say we're moving forward on marking this GLEP as Final 
pretty soon.

Biggest project left for me is to copy the current use.local.desc bits 
into the respective metadata.xml's of each package. If maintainers want 
to help, that'd be awesome.

[1] http://bugs.gentoo.org/show_bug.cgi?id=199788

-- 
Doug Goldstein <cardoe@gentoo.org>
http://dev.gentoo.org/~cardoe/
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Council meeting summary for 10 July 2008

[Ciaran McCreesh]

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

On Sun, 13 Jul 2008 00:11:18 -0700
Donnie Berkholz <dberkholz@gentoo.org> wrote:
> GLEP 55: On hold pending a concrete requirement for it. GLEP 54 may
> be, but that's unclear until it's been revised.

Which part of the 'Problem' section in the GLEP didn't you understand?
Do you seriously consider not being able to add or change global scope
functions in future EAPIs to be a non-issue, or were you ignoring those
two bullet points?

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Council meeting summary for 10 July 2008

[Alec Warner]

On Sun, Jul 13, 2008 at 3:52 PM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Sun, 13 Jul 2008 00:11:18 -0700
> Donnie Berkholz <dberkholz@gentoo.org> wrote:
>> GLEP 55: On hold pending a concrete requirement for it. GLEP 54 may
>> be, but that's unclear until it's been revised.
>
> Which part of the 'Problem' section in the GLEP didn't you understand?
> Do you seriously consider not being able to add or change global scope
> functions in future EAPIs to be a non-issue, or were you ignoring those
> two bullet points?

I understood both.

As far as could be determined by the members at the meeting there no
compelling examples in Gentoo who to change or add global scope functions
in future EAPIs.  As such those problems as stated are not in scope for Gentoo
because Gentoo is not attempting to do those things at this time.

>
> --
> Ciaran McCreesh
>
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Council meeting summary for 10 July 2008

[Alec Warner]

On Sun, Jul 13, 2008 at 4:16 PM, Alec Warner <antarus@gentoo.org> wrote:
> On Sun, Jul 13, 2008 at 3:52 PM, Ciaran McCreesh
> <ciaran.mccreesh@googlemail.com> wrote:
>> On Sun, 13 Jul 2008 00:11:18 -0700
>> Donnie Berkholz <dberkholz@gentoo.org> wrote:
>>> GLEP 55: On hold pending a concrete requirement for it. GLEP 54 may
>>> be, but that's unclear until it's been revised.
>>
>> Which part of the 'Problem' section in the GLEP didn't you understand?
>> Do you seriously consider not being able to add or change global scope
>> functions in future EAPIs to be a non-issue, or were you ignoring those
>> two bullet points?
>
> I understood both.
>
> As far as could be determined by the members at the meeting there no
> compelling examples in Gentoo who to change or add global scope functions
> in future EAPIs.  As such those problems as stated are not in scope for Gentoo
> because Gentoo is not attempting to do those things at this time.

ugh, s/who//

>
>>
>> --
>> Ciaran McCreesh
>>
>
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Council meeting summary for 10 July 2008

[Ciaran McCreesh]

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

On Sun, 13 Jul 2008 16:16:23 -0700
"Alec Warner" <antarus@gentoo.org> wrote:
> As far as could be determined by the members at the meeting there no
> compelling examples in Gentoo who to change or add global scope
> functions in future EAPIs.  As such those problems as stated are not
> in scope for Gentoo because Gentoo is not attempting to do those
> things at this time.

You mean you don't want per-category/package eclasses, or eclasses that
can indicate that they only work with some EAPIs, or eclasses that can
indicate that they're being used incorrectly, or the death of
EXPORT_FUNCTIONS? All of these have been discussed as desirable future
extensions.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Council meeting summary for 10 July 2008

[Alec Warner]

On Sun, Jul 13, 2008 at 4:21 PM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Sun, 13 Jul 2008 16:16:23 -0700
> "Alec Warner" <antarus@gentoo.org> wrote:
>> As far as could be determined by the members at the meeting there no
>> compelling examples in Gentoo who to change or add global scope
>> functions in future EAPIs.  As such those problems as stated are not
>> in scope for Gentoo because Gentoo is not attempting to do those
>> things at this time.
>
> You mean you don't want per-category/package eclasses, or eclasses that
> can indicate that they only work with some EAPIs, or eclasses that can
> indicate that they're being used incorrectly, or the death of
> EXPORT_FUNCTIONS? All of these have been discussed as desirable future
> extensions.

I don't require any of those things, but maybe other people do and If
so; they should probably come
to the meeting or otherwise make themselves known because they were
not at the previous meeting.

The GLEP as written is not convincing; it doesn't say 'I am trying to
do X with Gentoo and cannot because of this
restriction.'  It says 'In the future someone may want to do X and
they won't be able to because of this restriction so lets
try to remove the restriction now.'  This is an admirable goal mind
you; but it is my opinion that there are more concrete features
that we could implement for benefits now rather than talk about what could be.

I chatted briefly with peper on IRC about this (as he was the original
GLEP author) so when he gets time he said he had some examples to
provide.

>
> --
> Ciaran McCreesh
>
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Council meeting summary for 10 July 2008

[Ciaran McCreesh]

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

On Sun, 13 Jul 2008 16:37:35 -0700
"Alec Warner" <antarus@gentoo.org> wrote:
> I don't require any of those things, but maybe other people do and If
> so; they should probably come
> to the meeting or otherwise make themselves known because they were
> not at the previous meeting.

http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-libs/glibc/files/eblits/

I presume you're aware of that. People are already doing those other
things, and doing them badly, because there's currently no other option.
This isn't some hypothetical future requirement.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Council meeting summary for 10 July 2008

[Jeroen Roovers]

On Mon, 14 Jul 2008 00:43:06 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> People are already doing those other things, and doing them badly,
> because there's currently no other option. This isn't some
> hypothetical future requirement.

When you wrote "doing them badly", did you mean to imply doing
something else than GLEP 55, or were you just slagging off whoever
implemented eblits in sys-libs/glibc?

In other words perhaps, is it your opinion that GLEP 55 needs to be
implemented because sys-libs/glibc requires an immediate rewrite? Are
there any bug reports that would be good examples of why this new
implementation is warranted?


     JeR
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Council meeting summary for 10 July 2008

[Ciaran McCreesh]

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

On Mon, 14 Jul 2008 03:13:44 +0200
Jeroen Roovers <jer@gentoo.org> wrote:
> On Mon, 14 Jul 2008 00:43:06 +0100
> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > People are already doing those other things, and doing them badly,
> > because there's currently no other option. This isn't some
> > hypothetical future requirement.
> 
> When you wrote "doing them badly", did you mean to imply doing
> something else than GLEP 55, or were you just slagging off whoever
> implemented eblits in sys-libs/glibc?

As much as you like to try to find some way of taking offence at
everything I write, no, there's no slagging off in there.

As you know fine well, implementing what clearly should be package
manager provided functionality as hacks in an ebuild is never going to
give a nice, elegant solution. However, if package manager
functionality isn't available and can't become available quickly, it
might be the only solution until such functionality can come along. And
making sure such functionality can come along is at least partly the
Council's responsibility.

> In other words perhaps, is it your opinion that GLEP 55 needs to be
> implemented because sys-libs/glibc requires an immediate rewrite? Are
> there any bug reports that would be good examples of why this new
> implementation is warranted?

GLEP 55 wouldn't even allow an immediate rewrite of glibc because new
EAPIs can't easily be used on system packages. So no. Instead, GLEP 55
would allow a future EAPI to introduce a proper per-package eclass-like
solution at the package manager level, which could then over time be
phased into glibc, and over less time be phased into other packages
that would make use of it. That's the nice thing about the GLEP -- it
allows the phased introduction of a larger class improvements without
major upheaval.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Council meeting summary for 10 July 2008

[Jeroen Roovers]

On Mon, 14 Jul 2008 02:22:35 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Mon, 14 Jul 2008 03:13:44 +0200
> Jeroen Roovers <jer@gentoo.org> wrote:
> > On Mon, 14 Jul 2008 00:43:06 +0100
> > Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > > People are already doing those other things, and doing them badly,
> > > because there's currently no other option. This isn't some
> > > hypothetical future requirement.
> > 
> > When you wrote "doing them badly", did you mean to imply doing
> > something else than GLEP 55, or were you just slagging off whoever
> > implemented eblits in sys-libs/glibc?
> 
> As much as you like to try to find some way of taking offence at
> everything I write, no, there's no slagging off in there.

I'm sorry to say this, but I actually do take offence at most things you
write.

> As you know fine well, implementing what clearly should be

Please stop assuming people know everything you know and/or that people
should know everything you know. This is a public forum where you should
undertake to explain yourself fully instead of referring vaguely to an
unknown set of morals and then suggesting another party should address
whatever conflicts with that. It is a particularly subtle variant of
the classic straw man that you regularly wield, and it is one of those
things that often makes me take offence at what you write.

> package manager provided functionality as hacks in an ebuild is never
> going to give a nice, elegant solution. However, if package manager
> functionality isn't available and can't become available quickly, it
> might be the only solution until such functionality can come along.

So it's not "doing them badly", it's currently the only solution and
you haven't provided any arguments against this only solution as yet.

> And making sure such functionality can come along is at least partly
> the Council's responsibility.

So that's one count of "nice, elegant", and apparently that is what you
feel opposes "doing them badly"?

> > In other words perhaps, is it your opinion that GLEP 55 needs to be
> > implemented because sys-libs/glibc requires an immediate rewrite?
> > Are there any bug reports that would be good examples of why this
> > new implementation is warranted?
> 
> GLEP 55 wouldn't even allow an immediate rewrite of glibc because new
> EAPIs can't easily be used on system packages.

Oh. You just shot down your only real world example (eblit versus GLEP
55). If you have any more, I'd happily have a look at them, as would
anyone else worrying about the consequences of having GLEP 55
implemented.

> So no. Instead, GLEP 55 would allow a future EAPI to introduce a
> proper per-package eclass-like solution at the package manager level,
> which could then over time be phased into glibc, and over less time
> be phased into other packages that would make use of it. That's the
> nice thing about the GLEP -- it allows the phased introduction of a
> larger class improvements without major upheaval.

[Class _of_ improvements, I guess.]

Please provide an example of what that process would look like. You've
always been good at these "we have ebuild 1, then ebuild 2 comes along,
depending on ebuild 3 [...]" games, so please explain what we'd end
up with in a hypothetical GLEP 55 compliant gentoo-x86/sys-libs/glibc,
with "build files" (formerly ebuilds) getting added, removed,
keyworded, package.masked and so on.

What _I_ envision now is a motley crew of EAPI suffixed "build files"
processing through gentoo-x86/sys-libs/glibc over time. Surely it
would look a right mess every time you needed to go into that
directory (particularly not in a role as any package manager's user or
developer, but as a "build file" developer browsing through those
files).

What GLEP 55 fails to address right now is the very development process
it is seemingly supposed to alleviate. It addresses the issue of EAPI
implementation from the viewpoint of the package manager's developer,
but it doesn't begin to address the viewpoint of the package
maintainer or architecture developer at all. It looks to me like a lot
of problems are moved out of the package manager(s) and into this
already huge tree of files, with different EAPI-suffixed files
addressing different problems, and that indicate be a non-trivial
increase in the number of files in the tree - files which would
address the equal purpose of installing exactly one =cat/pkg-ver.

In other words, disregarding its other real world deficiencies like an
immediate goal, GLEP 55 fails to describe a keywording policy for
architecture developers and it fails to describe a "build file"
addition (bump) policy for package maintainers.

I grant you that on the surface it really does look nice and elegant.


     JeR
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Council meeting summary for 10 July 2008

[Santiago M. Mola]

On Mon, Jul 14, 2008 at 5:32 AM, Jeroen Roovers <jer@gentoo.org> wrote:
>
> What GLEP 55 fails to address right now is the very development process
> it is seemingly supposed to alleviate. It addresses the issue of EAPI
> implementation from the viewpoint of the package manager's developer,
> but it doesn't begin to address the viewpoint of the package
> maintainer or architecture developer at all. It looks to me like a lot
> of problems are moved out of the package manager(s) and into this
> already huge tree of files, with different EAPI-suffixed files
> addressing different problems, and that indicate be a non-trivial
> increase in the number of files in the tree - files which would
> address the equal purpose of installing exactly one =cat/pkg-ver.

GLEP 55 says:
"Note that it is still not permitted to have more than one ebuild with
equal category, package name, and version."

> In other words, disregarding its other real world deficiencies like an
> immediate goal, GLEP 55 fails to describe a keywording policy for
> architecture developers

Keywording policy wouldn't change.

Regards,
-- 
Santiago M. Mola
Jabber ID: cooldwind@gmail.com
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Council meeting summary for 10 July 2008

[Ciaran McCreesh]

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

On Mon, 14 Jul 2008 05:32:58 +0200
Jeroen Roovers <jer@gentoo.org> wrote:
> I'm sorry to say this, but I actually do take offence at most things
> you write.

Perhaps you should consider what that indicates about yourself, rather
than about me.

> > As you know fine well, implementing what clearly should be
> 
> Please stop assuming people know everything you know and/or that
> people should know everything you know. This is a public forum where
> you should undertake to explain yourself fully instead of referring
> vaguely to an unknown set of morals and then suggesting another party
> should address whatever conflicts with that. It is a particularly
> subtle variant of the classic straw man that you regularly wield, and
> it is one of those things that often makes me take offence at what
> you write.

All I'm assuming is that people have read and understood the GLEP, and
in any places where they don't understand, they ask. Is that assuming
too much?

> > package manager provided functionality as hacks in an ebuild is
> > never going to give a nice, elegant solution. However, if package
> > manager functionality isn't available and can't become available
> > quickly, it might be the only solution until such functionality can
> > come along.
> 
> So it's not "doing them badly", it's currently the only solution and
> you haven't provided any arguments against this only solution as yet.

No, it is doing it badly. A square wheel is bad, even if it was
necessary because the round one was unattainable.

> > > In other words perhaps, is it your opinion that GLEP 55 needs to
> > > be implemented because sys-libs/glibc requires an immediate
> > > rewrite? Are there any bug reports that would be good examples of
> > > why this new implementation is warranted?
> > 
> > GLEP 55 wouldn't even allow an immediate rewrite of glibc because
> > new EAPIs can't easily be used on system packages.
> 
> Oh. You just shot down your only real world example (eblit versus GLEP
> 55). If you have any more, I'd happily have a look at them, as would
> anyone else worrying about the consequences of having GLEP 55
> implemented.

Uh. Future versions of glibc? Read what I wrote.

> > So no. Instead, GLEP 55 would allow a future EAPI to introduce a
> > proper per-package eclass-like solution at the package manager
> > level, which could then over time be phased into glibc, and over
> > less time be phased into other packages that would make use of it.
> > That's the nice thing about the GLEP -- it allows the phased
> > introduction of a larger class improvements without major upheaval.
> 
> [Class _of_ improvements, I guess.]
> 
> Please provide an example of what that process would look like. You've
> always been good at these "we have ebuild 1, then ebuild 2 comes
> along, depending on ebuild 3 [...]" games, so please explain what
> we'd end up with in a hypothetical GLEP 55 compliant
> gentoo-x86/sys-libs/glibc, with "build files" (formerly ebuilds)
> getting added, removed, keyworded, package.masked and so on.

New, experimental glibc versions that aren't expected to go stable
quickly use the new EAPI. Existing versions and any "will need to go
stable soon" bumps stay using the old EAPI. After the next release
(which is *only* an issue for dependencies of the package manager)
all new glibc versions use the new EAPI.

> What _I_ envision now is a motley crew of EAPI suffixed "build files"
> processing through gentoo-x86/sys-libs/glibc over time. Surely it
> would look a right mess every time you needed to go into that
> directory (particularly not in a role as any package manager's user or
> developer, but as a "build file" developer browsing through those
> files).

How does:

$ ls
ChangeLog               glibc-2.3.6-r4.ebuild  glibc-2.5.1.ebuild
Manifest                glibc-2.3.6-r5.ebuild  glibc-2.6.1.ebuild
files                   glibc-2.4-r4.ebuild    glibc-2.6.ebuild
glibc-2.2.5-r10.ebuild  glibc-2.5-r2.ebuild    glibc-2.7-r2.ebuild
glibc-2.3.2-r12.ebuild  glibc-2.5-r3.ebuild
glibc-2.8_p20080602.ebuild-2
glibc-2.3.5-r3.ebuild   glibc-2.5-r4.ebuild    metadata.xml

look any worse than what's there now?

> What GLEP 55 fails to address right now is the very development
> process it is seemingly supposed to alleviate. It addresses the issue
> of EAPI implementation from the viewpoint of the package manager's
> developer, but it doesn't begin to address the viewpoint of the
> package maintainer or architecture developer at all. It looks to me
> like a lot of problems are moved out of the package manager(s) and
> into this already huge tree of files, with different EAPI-suffixed
> files addressing different problems, and that indicate be a
> non-trivial increase in the number of files in the tree - files which
> would address the equal purpose of installing exactly one
> =cat/pkg-ver.

GLEP 55 does not change the EAPI process from a maintainer perspective,
except that it replaces "set EAPI=X in the ebuild" with "use .ebuild-X".

> In other words, disregarding its other real world deficiencies like an
> immediate goal, GLEP 55 fails to describe a keywording policy for
> architecture developers and it fails to describe a "build file"
> addition (bump) policy for package maintainers.

There *is* no change there.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Council meeting summary for 10 July 2008

[Petteri Räty]

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

Ciaran McCreesh kirjoitti:
> On Sun, 13 Jul 2008 16:16:23 -0700
> "Alec Warner" <antarus@gentoo.org> wrote:
>> As far as could be determined by the members at the meeting there no
>> compelling examples in Gentoo who to change or add global scope
>> functions in future EAPIs.  As such those problems as stated are not
>> in scope for Gentoo because Gentoo is not attempting to do those
>> things at this time.
> 
> You mean you don't want per-category/package eclasses, or eclasses that
> can indicate that they only work with some EAPIs, or eclasses that can
> indicate that they're being used incorrectly, or the death of
> EXPORT_FUNCTIONS? All of these have been discussed as desirable future
> extensions.
> 

Yes I can think a lot of features like this that would be of great use 
in the main tree but as long as Portage is the only official and stable 
package manager and doesn't support the things you listed, the GLEP is 
not of much use.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: [gentoo-dev] Council meeting summary for 10 July 2008

[Ciaran McCreesh]

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

On Tue, 15 Jul 2008 18:58:01 +0300
Petteri Räty <betelgeuse@gentoo.org> wrote:
> Yes I can think a lot of features like this that would be of great
> use in the main tree but as long as Portage is the only official and
> stable package manager and doesn't support the things you listed, the
> GLEP is not of much use.

So you're saying the GLEP's of no use until Portage supports them, but
Portage can't support them until you say yes to the GLEP...

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Council meeting summary for 10 July 2008

[Petteri Räty]

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

Ciaran McCreesh kirjoitti:
> On Tue, 15 Jul 2008 18:58:01 +0300
> Petteri Räty <betelgeuse@gentoo.org> wrote:
>> Yes I can think a lot of features like this that would be of great
>> use in the main tree but as long as Portage is the only official and
>> stable package manager and doesn't support the things you listed, the
>> GLEP is not of much use.
> 
> So you're saying the GLEP's of no use until Portage supports them, but
> Portage can't support them until you say yes to the GLEP...
> 

I am saying that it makes sense to approve both at the same time or have 
other official package managers approved before accepting the GLEP.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: [gentoo-dev] Council meeting summary for 10 July 2008

[Ciaran McCreesh]

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

On Tue, 15 Jul 2008 19:16:42 +0300
Petteri Räty <betelgeuse@gentoo.org> wrote:
> > So you're saying the GLEP's of no use until Portage supports them,
> > but Portage can't support them until you say yes to the GLEP...
> 
> I am saying that it makes sense to approve both at the same time or
> have other official package managers approved before accepting the
> GLEP.

Why? We know it's a not-too-distant future need. Might as well get it
out of the way now so there isn't more than an hour's worth of stuff
all needing to be approved at the same time.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Council meeting summary for 10 July 2008

[Joe Peterson]

Petteri Räty wrote:
> I am saying that it makes sense to approve both at the same time or have 
> other official package managers approved before accepting the GLEP.

In addition, I'd want to see why the particular approach suggested in this
GELP is the "only" way (as some seem to claim).  I have yet to be convinced of
this, and as I've pointed out before (and do not wish to belabor further
here), I believe there are major drawbacks to putting the EAPI in the
filename/extension.  Rushing to approve this GLEP would be a mistake, IMHO.

						-Joe
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Council meeting summary for 10 July 2008

[Richard Freeman]

Petteri Räty wrote:
> Ciaran McCreesh kirjoitti:
>> So you're saying the GLEP's of no use until Portage supports them, but
>> Portage can't support them until you say yes to the GLEP...
>>
> 
> I am saying that it makes sense to approve both at the same time or have 
> other official package managers approved before accepting the GLEP.
> 

I'm not sure that implementation of new features in portage or official 
status for other package managers needs to be a condition for acceptance 
of this GLEP.  The council's main concern was that there wasn't a 
clearly defined immediate need for the GLEP so it was sensible to defer 
it.  That isn't an unreasonable suggestion.

Would it be more constructive to create a list of new 
features/capabilities that depend on this GLEP.  For each I'd define:

1.  The feature/unmet need.
2.  Why it can't be done or can only be done poorly without the new GLEP.
3.  When we're likely to see the feature become available assuming the 
GLEP were approved.
4.  What package managers are likely to implement it.  (Ie their 
maintainers endorse the need.

It sounds like this list might already have some items on it - so why 
not document them?

If the council wants to avoid approving the GLSA for a merely 
theoretical need they might offer to endorse the idea but delay it 
pending the implementation of one or more of the new features in one, 
two, or all three major package managers, or pending support by portage. 
  That would give developers some assurance that they wouldn't waste 
time going down a road only to be shot down later.

It is good for the well-being of Gentoo that the council be relatively 
conservative with regard to potentially-disruptive decisions.  They 
simply want to see that the benefits outweigh the costs.  So, just show 
them the benefits.  At some point the case for going forward outweighs 
the reluctance to do so.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Council meeting summary for 10 July 2008

[Ciaran McCreesh]

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

On Tue, 15 Jul 2008 13:58:36 -0400
Richard Freeman <rich0@gentoo.org> wrote:
> Would it be more constructive to create a list of new 
> features/capabilities that depend on this GLEP.  For each I'd define:
> 
> 1.  The feature/unmet need.
> 2.  Why it can't be done or can only be done poorly without the new
> GLEP. 3.  When we're likely to see the feature become available
> assuming the GLEP were approved.
> 4.  What package managers are likely to implement it.  (Ie their 
> maintainers endorse the need.
> 
> It sounds like this list might already have some items on it - so why 
> not document them?

The GLEP already documents what needs it, in the broadest reasonable
terms. The problem with specifics is that everyone will then start
arguing about how exactly, say, per-cat/pkg eclasses would work, which
is irrelevant to the GLEP.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Re: Council meeting summary for 10 July 2008

[Doug Goldstein]

Tiziano Müller wrote:
> Donnie Berkholz wrote:
>
>   
>> Hi all,
>>
>> Here is the summary from Thursday's council meeting. The complete log
>> will show up at http://www.gentoo.org/proj/en/council/ shortly.
>>
>>     
>
> wrt GLEP 56:
>
> i) I don't see a specification when use.local.desc is finally going to be
> dropped
> ii) Why not switch to XML for use.desc as well? (just to be consequent)
> We could then use XInclude in a package's metadata.xml to include a global
> use.desc.xml in <use>...</use>
> (The requirements could then be changed to: the USE flags description has to
> be written in the packages metadata.xml)
>
>
>   
Incremental steps are better then one huge sweeping change. It'll allow 
us to evaluate the needs and goals of the project as we move forward. 
The big concern with dropping use.desc is that multiple USE flags that 
do the same thing will start to pop up across the whole tree because 
developers won't know that a USE flag already exists for feature X.
-- 
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] Re: Council meeting summary for 10 July 2008

[Tiziano Müller]

Donnie Berkholz wrote:

> Hi all,
> 
> Here is the summary from Thursday's council meeting. The complete log
> will show up at http://www.gentoo.org/proj/en/council/ shortly.
> 

wrt GLEP 56:

i) I don't see a specification when use.local.desc is finally going to be
dropped
ii) Why not switch to XML for use.desc as well? (just to be consequent)
We could then use XInclude in a package's metadata.xml to include a global
use.desc.xml in <use>...</use>
(The requirements could then be changed to: the USE flags description has to
be written in the packages metadata.xml)


-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: Re: Council meeting summary for 10 July 2008

[Doug Goldstein]

Tiziano Müller wrote:
> Doug Goldstein wrote:
>
>   
>> Tiziano Müller wrote:
>>     
>>> Donnie Berkholz wrote:
>>>
>>>   
>>>       
>>>> Hi all,
>>>>
>>>> Here is the summary from Thursday's council meeting. The complete log
>>>> will show up at http://www.gentoo.org/proj/en/council/ shortly.
>>>>
>>>>     
>>>>         
>>> wrt GLEP 56:
>>>
>>> i) I don't see a specification when use.local.desc is finally going to be
>>> dropped
>>> ii) Why not switch to XML for use.desc as well? (just to be consequent)
>>> We could then use XInclude in a package's metadata.xml to include a
>>> global use.desc.xml in <use>...</use>
>>> (The requirements could then be changed to: the USE flags description has
>>> to be written in the packages metadata.xml)
>>>
>>>
>>>   
>>>       
>> Incremental steps are better then one huge sweeping change. It'll allow
>> us to evaluate the needs and goals of the project as we move forward.
>>     
> I agree.
>
>   
>> The big concern with dropping use.desc is that multiple USE flags that
>> do the same thing will start to pop up across the whole tree because
>> developers won't know that a USE flag already exists for feature X.
>>     
> I'd not drop use.desc, I'd substitute it with an XML-based file using a
> similar (or the same) syntax as metadata.xml.
> But instead of having the package manager (or other tools operating with USE
> flags/USE flag descriptions) to lookup in either a package's metadata.xml
> _or_ a global use.desc.xml, I'd use XInclude in metadata.xml (which then
> includes the global use.desc.xml) such that the package manager (or other
> tools) just have to consider a package's metadata.xml.
> This approach would make it possible to have more than one use.desc.xml.
> For example for kde or gnome related global USE-flags: kde.use.desc.xml or
> gnome.use.desc.xml.
>   
If you write the code....

That's the biggest issue with features and ideas people propose. No one 
is willing to sit down and write the code necessary. Look at how many 
GLEPs set unimplemented because of lack of code.

This also involves increasing the XML support in every package manager, 
which is not going to be a small undertaking.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: Re: Council meeting summary for 10 July 2008

[Patrick Börjesson]

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

On 2008-07-16 14:50, Doug Goldstein uttered these thoughts:
> Tiziano Müller wrote:
> This also involves increasing the XML support in every package manager, 
> which is not going to be a small undertaking.

I'd say near to impossible in at least one case

-- 
()  The ASCII Ribbon Campaign - against HTML Email
/\  and proprietary formats.

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

[gentoo-dev] Re: Re: Council meeting summary for 10 July 2008

[Tiziano Müller]

Doug Goldstein wrote:

> Tiziano Müller wrote:
>> Donnie Berkholz wrote:
>>
>>   
>>> Hi all,
>>>
>>> Here is the summary from Thursday's council meeting. The complete log
>>> will show up at http://www.gentoo.org/proj/en/council/ shortly.
>>>
>>>     
>>
>> wrt GLEP 56:
>>
>> i) I don't see a specification when use.local.desc is finally going to be
>> dropped
>> ii) Why not switch to XML for use.desc as well? (just to be consequent)
>> We could then use XInclude in a package's metadata.xml to include a
>> global use.desc.xml in <use>...</use>
>> (The requirements could then be changed to: the USE flags description has
>> to be written in the packages metadata.xml)
>>
>>
>>   
> Incremental steps are better then one huge sweeping change. It'll allow
> us to evaluate the needs and goals of the project as we move forward.
I agree.

> The big concern with dropping use.desc is that multiple USE flags that
> do the same thing will start to pop up across the whole tree because
> developers won't know that a USE flag already exists for feature X.
I'd not drop use.desc, I'd substitute it with an XML-based file using a
similar (or the same) syntax as metadata.xml.
But instead of having the package manager (or other tools operating with USE
flags/USE flag descriptions) to lookup in either a package's metadata.xml
_or_ a global use.desc.xml, I'd use XInclude in metadata.xml (which then
includes the global use.desc.xml) such that the package manager (or other
tools) just have to consider a package's metadata.xml.
This approach would make it possible to have more than one use.desc.xml.
For example for kde or gnome related global USE-flags: kde.use.desc.xml or
gnome.use.desc.xml.


-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Council meeting summary for 10 July 2008

[Peter Volkov]

В Вск, 13/07/2008 в 23:52 +0100, Ciaran McCreesh пишет:
> Which part of the 'Problem' section in the GLEP didn't you understand?
> Do you seriously consider not being able to add or change global scope
> functions in future EAPIs to be a non-issue, or were you ignoring those
> two bullet points?

I've read all previous discussions but still miss answer to the
question: Why is it impossible to state that .ebuild extension is for
bash based ebuild make package manager get and filter EAPIs based on
EAPI variable?

Note, I assume that we can do not backward-compatible changes in PM, we
just need to wait enough time to start using it. But taking into account
that the features that will make use of this GLEP55 are still not so
evident I don't see any problem to wait. In any case I'd like to
understand why should we start support this hell of extensions.

-- 
Peter.

Re: [gentoo-dev] Council meeting summary for 10 July 2008

[Ciaran McCreesh]

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

On Sun, 20 Jul 2008 17:38:32 +0400
Peter Volkov <pva@gentoo.org> wrote:
> В Вск, 13/07/2008 в 23:52 +0100, Ciaran McCreesh пишет:
> > Which part of the 'Problem' section in the GLEP didn't you
> > understand? Do you seriously consider not being able to add or
> > change global scope functions in future EAPIs to be a non-issue, or
> > were you ignoring those two bullet points?
> 
> I've read all previous discussions but still miss answer to the
> question: Why is it impossible to state that .ebuild extension is for
> bash based ebuild make package manager get and filter EAPIs based on
> EAPI variable?

I think your question is missing a word or something. I'm not entirely
sure what you're trying to ask...

But if you're asking why we can't use the EAPI variable, it's because
we can't get the EAPI variable unless we already know what it is. It's
only possible currently because all EAPIs have identical global scope
functions and environment requirements, but future EAPIs want to change
things there.

> In any case I'd like to understand why should we start support this
> hell of extensions.

Why do you think it's hell? It's just as easy as having an EAPI
variable inside the ebuild, and has the added advantage that your
editor of choice can start doing EAPI-aware syntax highlighting for you.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Council meeting summary for 10 July 2008

[Patrick Börjesson]

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

On 2008-07-20 17:38, Peter Volkov uttered these thoughts:
> В Вск, 13/07/2008 в 23:52 +0100, Ciaran McCreesh пишет:
> > Which part of the 'Problem' section in the GLEP didn't you understand?
> > Do you seriously consider not being able to add or change global scope
> > functions in future EAPIs to be a non-issue, or were you ignoring those
> > two bullet points?
> 
> I've read all previous discussions but still miss answer to the
> question: Why is it impossible to state that .ebuild extension is for
> bash based ebuild make package manager get and filter EAPIs based on
> EAPI variable?

Because that would still not allow global scope changes, because in order 
to get to know which EAPI the ebuild is written in, you have to actually
source the ebuild, and by then it's too late.

Unless you introduce some inane requirement that the EAPI variable has
to be the first thing stated in the ebuild and force the PMs to extract
that value before actually starting to parse the ebuild. Now, if
_that's_ not an ugly solution, i don't know what is...

You have to know _how_ to interpret an ebuild _before_ you actually start
doing it.

> Note, I assume that we can do not backward-compatible changes in PM, we
> just need to wait enough time to start using it. But taking into account
> that the features that will make use of this GLEP55 are still not so
> evident I don't see any problem to wait. In any case I'd like to
> understand why should we start support this hell of extensions.

Reasons for the change has been stated before, and the one i just
explained is the main one so far as i know. 

-- 
()  The ASCII Ribbon Campaign - against HTML Email
/\  and proprietary formats.

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