FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 07-14-2008, 01:22 AM
Ciaran McCreesh
 
Default Council meeting summary for 10 July 2008

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
 
Old 07-14-2008, 03:32 AM
Jeroen Roovers
 
Default Council meeting summary for 10 July 2008

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
 
Old 07-14-2008, 08:59 AM
"Santiago M. Mola"
 
Default Council meeting summary for 10 July 2008

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
 
Old 07-14-2008, 12:41 PM
Ciaran McCreesh
 
Default Council meeting summary for 10 July 2008

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
 
Old 07-15-2008, 03:58 PM
Petteri Räty
 
Default Council meeting summary for 10 July 2008

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
 
Old 07-15-2008, 04:11 PM
Ciaran McCreesh
 
Default Council meeting summary for 10 July 2008

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
 
Old 07-15-2008, 04:16 PM
Petteri Räty
 
Default Council meeting summary for 10 July 2008

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
 
Old 07-15-2008, 04:58 PM
Ciaran McCreesh
 
Default Council meeting summary for 10 July 2008

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
 
Old 07-15-2008, 05:55 PM
Joe Peterson
 
Default Council meeting summary for 10 July 2008

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
 
Old 07-15-2008, 05:58 PM
Richard Freeman
 
Default Council meeting summary for 10 July 2008

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
 

Thread Tools




All times are GMT. The time now is 04:23 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org