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


 
 
LinkBack Thread Tools
 
Old 12-24-2007, 11:38 AM
Ciaran McCreesh
 
Default )

On Mon, 24 Dec 2007 10:52:53 +0000
Steve Long <slong@rathaus.eclipse.co.uk> wrote:
> Ciaran McCreesh wrote:
> > On Mon, 24 Dec 2007 06:03:12 +0000
> > Steve Long <slong@rathaus.eclipse.co.uk> wrote:
> >> * Set the EAPI inside the ebuild in a way that makes it easy to
> >> fetch it This is ok as atm only EAPI=1 is in the tree, so there is
> >> no backward compatibility issue.
> >
> > It's both a backwards and a forwards compatibility issue.
> >
> Yeah, so forwards into the future where it's impossible to maintain
> this format (er..) there'll be another type of ebuild for your
> purported long-term solution.

Hopefully that'll be EAPI 2, and hopefully we're talking months rather
than years.

> > And eclasses are an entirely separate issue. They need to
> > be dealt with differently, ideally starting with EAPI 2.
> >
> But they come under the scope of this discussion, since this is about
> the long-term future of *every* EAPI. So let's discuss them.

Ok. What technically sound ideas that have been implemented in a real
package manager and tried out on a large, real tree maintained by
multiple developers do you have about improving eclasses with respect
to EAPI handling? I'm curious, because the only solutions we have for
working with the current system are going to suck in the long term (but
equally, they do work with EAPI 0/1, which means they're fine for short
term), and I've yet to hear of a solution that is implementable (both
theoretically and practically), usable from a tree perspective and
scalable across EAPIs.

To start you off, here's a list of ideas that suck:

* Per-EAPI eclasses, or a master eclass that uses sub-eclasses for
whichever EAPI is in use. This is the best general current solution, but
it gets messy very quickly with new EAPIs.

* Eclasses enforcing EAPI restrictions either by global scope or
pkg_setup die. The former's illegal, breaks the metadata cache as it's
done currently, and is way too easy for developers to screw up. The
latter is way too easy for developers to screw up, results in users
seeing the mess and doesn't allow package managers to work around it.

* Variant: eclasses forcibly setting EAPI to OOPS-SOMEONE-SCREWED-UP if
they don't support the eclass used. This one's actually ok from a
package manager perspective, but lousy from a developer testing thing
perspective.

* Eclasses modifying EAPI. Doesn't scale across multiple eclasses, nor
across EAPIs removing features, nor EAPIs changing eclasses.

* Some kind of list of supported EAPIs in an eclass. Still has to deal
with EAPI 0 and 1, and doesn't work well across multiple eclasses.

* Banning eclasses from using anything that isn't supported in every
EAPI. Makes new features rather useless, and removing things rather
difficult...

* Crazy hackery involving making 'inherit' look somewhere else in
future EAPIs. At best you'd end up having stub eclasses (again with no
particularly nice way of saying 'oops') to deal with EAPIs 0 and 1.

* Introduce some new global scope eclass-like function that, combined
with supported EAPI sets, does have a proper way of signalling 'not
supported' (and throw in per cat/pkg eclasses because you can).
Unfortunately, you can't do this without breaking current EAPI 0 / 1
package managers, unless you also switch file extensions or some
equivalent op.

All but the last of these are nowhere near good enough. The last one
may or may not be OK as a starting point, but everyone I've spoken to
who's worked with a real multiple EAPI repo agrees that it's a long way
off being a good enough idea that it's worth considering having serious
discussion about it.

So go ahead and start discussing eclasses, if you want. But first I
suggest getting lots and lots of experience and making damned sure you
understand how everything works...

--
Ciaran McCreesh
--
gentoo-dev@gentoo.org mailing list
 
Old 12-28-2007, 04:21 AM
Steve Long
 
Default )

Ciaran McCreesh wrote:
> On Mon, 24 Dec 2007 10:52:53 +0000
> Steve Long <slong@rathaus.eclipse.co.uk> wrote:
>> Ciaran McCreesh wrote:
>> > On Mon, 24 Dec 2007 06:03:12 +0000
>> > Steve Long <slong@rathaus.eclipse.co.uk> wrote:
>> >> * Set the EAPI inside the ebuild in a way that makes it easy to
>> >> fetch it This is ok as atm only EAPI=1 is in the tree, so there is
>> >> no backward compatibility issue.
>> >
>> > It's both a backwards and a forwards compatibility issue.
>> >
>> Yeah, so forwards into the future where it's impossible to maintain
>> this format (er..) there'll be another type of ebuild for your
>> purported long-term solution.
>
> Hopefully that'll be EAPI 2, and hopefully we're talking months rather
> than years.
>
Whatever. EAPI="2" works fine with current software. Could you tell me why
you're so hot on export'ing EAPI? I thought it was only relevant,
environment-wise, to the ebuild and subshells. What is the use case for
exporting it externally?

> * Eclasses modifying EAPI. Doesn't scale across multiple eclasses, nor
> across EAPIs removing features, nor EAPIs changing eclasses.
>
I don't see what's wrong with EAPI (if set, otherwise implicitly whatever
the ebuild sets, or 0 if not set there) only applying to the file it's
declared in.

Since we can't remove eclasses, it would be useful to continue allowing them
to examine the EAPI variable for future compatibility. I'm sure there are
other restrictions imposed by this "enhancement" which make maintenance
more difficult for no benefit to the maintainer.


--
gentoo-dev@gentoo.org mailing list
 
Old 12-28-2007, 06:57 AM
Marius Mauch
 
Default )

On Fri, 28 Dec 2007 05:21:06 +0000
Steve Long <slong@rathaus.eclipse.co.uk> wrote:

> I don't see what's wrong with EAPI (if set, otherwise implicitly whatever
> the ebuild sets, or 0 if not set there) only applying to the file it's
> declared in.

Because that doesn't work at all, see
http://article.gmane.org/gmane.linux.gentoo.devel/53354

Marius
--
gentoo-dev@gentoo.org mailing list
 
Old 12-28-2007, 11:14 AM
Ciaran McCreesh
 
Default )

On Fri, 28 Dec 2007 05:21:06 +0000
Steve Long <slong@rathaus.eclipse.co.uk> wrote:
> Whatever. EAPI="2" works fine with current software. Could you tell
> me why you're so hot on export'ing EAPI? I thought it was only
> relevant, environment-wise, to the ebuild and subshells. What is the
> use case for exporting it externally?

I'm going to ignore you until you post a lengthy explanation of why
what you just said was utter bollocks. You clearly don't have a clue
what you're talking about just now, and by continuing to post nonsense
like the above to the discussion you're wasting everyone's time.

Honestly, that was the single most wrong thing anyone's said in this
entire discussion.

--
Ciaran McCreesh
 
Old 12-29-2007, 08:48 AM
Steve Long
 
Default )

Ciaran McCreesh wrote:

> On Fri, 28 Dec 2007 05:21:06 +0000
> Steve Long <slong@rathaus.eclipse.co.uk> wrote:
>> Whatever. EAPI="2" works fine with current software. Could you tell
>> me why you're so hot on export'ing EAPI? I thought it was only
>> relevant, environment-wise, to the ebuild and subshells. What is the
>> use case for exporting it externally?
>
> I'm going to ignore you until you post a lengthy explanation of why
> what you just said was utter bollocks. You clearly don't have a clue
> what you're talking about just now, and by continuing to post nonsense
> like the above to the discussion you're wasting everyone's time.
>
> Honestly, that was the single most wrong thing anyone's said in this
> entire discussion.
>
Er two questions, not statements.
The package manager knows the value; so does bash. Why on earth does, say,
make need to know it?

(Not that it's hard to allow 'export' in the line, just wondering why it
keeps getting raised as required.)


--
gentoo-dev@gentoo.org mailing list
 
Old 12-29-2007, 06:08 PM
Ciaran McCreesh
 
Default )

On Sat, 29 Dec 2007 09:48:33 +0000
Steve Long <slong@rathaus.eclipse.co.uk> wrote:
> The package manager knows the value; so does bash. Why on earth does,
> say, make need to know it?

Don't think 'make'. Think 'emake'.

--
Ciaran McCreesh
 
Old 04-20-2008, 05:21 PM
Thomas Bächler
 
Default )

Have a look at:
http://bbs.archlinux.org/viewtopic.php?id=47390

According to the kernel configuration help, increasing the maximum
number of CPUs from 4 to 8 will make the kernel 32KB bigger with no
performance decrease.


Opinions?
 
Old 04-20-2008, 05:31 PM
"Dan McGee"
 
Default )

On Sun, Apr 20, 2008 at 12:21 PM, Thomas Bächler <thomas@archlinux.org> wrote:
> Have a look at:
> http://bbs.archlinux.org/viewtopic.php?id=47390
>
> According to the kernel configuration help, increasing the maximum number
> of CPUs from 4 to 8 will make the kernel 32KB bigger with no performance
> decrease.
>
> Opinions?

I'd always rather these things go through the ML or a feature request,
rather than a forum post. That way someone can actually trace the
process.

Sounds fine to me, although I don't think there is any point on i686
(who would run >4 cores there?). x86_64 makes sense though.

-Dan
 
Old 04-20-2008, 06:23 PM
eliott
 
Default )

On 4/20/08, Dan McGee <dpmcgee@gmail.com> wrote:
> On Sun, Apr 20, 2008 at 12:21 PM, Thomas Bächler <thomas@archlinux.org> wrote:
> > Have a look at:
> > http://bbs.archlinux.org/viewtopic.php?id=47390
> >
> > According to the kernel configuration help, increasing the maximum number
> > of CPUs from 4 to 8 will make the kernel 32KB bigger with no performance
> > decrease.
> >
> > Opinions?
>
>
> I'd always rather these things go through the ML or a feature request,
> rather than a forum post. That way someone can actually trace the
> process.
>
> Sounds fine to me, although I don't think there is any point on i686
> (who would run >4 cores there?). x86_64 makes sense though.

Well.. if it isn't harmful in any way, and if we would do it on
x86_64, then we should also do it on i686. Having as consistent a
baseline as possible is good.

As to actually doing it, are there any ramifications due to the
potential for tracking additional cpus (timeslice allocation
algorithmic changes?) that would be a noticeable performance inpact
for people running 2 or 4 cpus?
 
Old 04-21-2008, 03:03 AM
"K. Piche"
 
Default )

On Sun, 2008-04-20 at 12:31 -0500, Dan McGee wrote:
> On Sun, Apr 20, 2008 at 12:21 PM, Thomas Bächler <thomas@archlinux.org> wrote:
> > Have a look at:
> > http://bbs.archlinux.org/viewtopic.php?id=47390
> >
> > According to the kernel configuration help, increasing the maximum number
> > of CPUs from 4 to 8 will make the kernel 32KB bigger with no performance
> > decrease.
> >
> > Opinions?
>
> I'd always rather these things go through the ML or a feature request,
> rather than a forum post. That way someone can actually trace the
> process.
>
> Sounds fine to me, although I don't think there is any point on i686
> (who would run >4 cores there?). x86_64 makes sense though.

I've got some machines at work that have 4 dual core CPU's (cpuinfo
shows 8 cpu's) running 32 bit Linux so it's not that wierd.

> -Dan
--
K. Piche <kpiche@rogers.com>
 

Thread Tools




All times are GMT. The time now is 09:55 PM.

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