On Thu, Aug 24, 2006 at 04:58:02PM -0400, Chris Gianelloni wrote:
Don't forget that this will require an update to (at least)
eselect-opengl, too.
Actually I'm not sure it would. eselect-opengl currently checks
/usr/lib[,64,32]/opengl/ for 32bit opengl libs libs and only finds the
emul libs
On Fri, 2006-08-25 at 13:26 +0100, Herbie Hopkins wrote:
On Thu, Aug 24, 2006 at 04:58:02PM -0400, Chris Gianelloni wrote:
Don't forget that this will require an update to (at least)
eselect-opengl, too.
Actually I'm not sure it would. eselect-opengl currently checks
On Mon, 2006-08-21 at 12:21 +0100, Herbie Hopkins wrote:
On Tue, Aug 08, 2006 at 11:43:13AM -0400, Mike Frysinger wrote:
someone remind me why our emul packages install in some obscure directory
tree
rooted in /emul
if we moved these things to the standard lib32 dirs, it would
On Tue, Aug 08, 2006 at 11:43:13AM -0400, Mike Frysinger wrote:
someone remind me why our emul packages install in some obscure directory
tree
rooted in /emul
if we moved these things to the standard lib32 dirs, it would certainly ease
the pain of people doing multilib building, both in
On Mon, 2006-21-08 at 12:21 +0100, Herbie Hopkins wrote:
On Tue, Aug 08, 2006 at 11:43:13AM -0400, Mike Frysinger wrote:
someone remind me why our emul packages install in some obscure directory
tree
rooted in /emul
if we moved these things to the standard lib32 dirs, it would
On Monday 21 August 2006 10:29, Olivier Crête wrote:
On Mon, 2006-21-08 at 12:21 +0100, Herbie Hopkins wrote:
I've always viewed the emul libs as a temporary measure until we had full
multilib fuctionality in portage. Afaik the only person working on this
was eradicator who has been mia for
On Mon, 2006-21-08 at 13:28 -0400, Mike Frysinger wrote:
On Monday 21 August 2006 10:29, Olivier Crête wrote:
On Mon, 2006-21-08 at 12:21 +0100, Herbie Hopkins wrote:
I've always viewed the emul libs as a temporary measure until we had full
multilib fuctionality in portage. Afaik the only
On Monday 21 August 2006 13:39, Olivier Crete wrote:
Will we make emul-x86-gtk-libs block gtk+? We dont have use based
deps/blockers...
building for ABI is unrelated to USE flags
how long will it take before we have API/arch based
ones.
you really think having users build ABI stuff on the
Herbie Hopkins wrote:
I'm not sure why /emul was originally chosen though it's a choice I've
just gone along with whilst maintaining these packages. I've always
viewed the emul libs as a temporary measure until we had full multilib
fuctionality in portage. Afaik the only person working on this
looks like your mail server ate this ...
someone remind me why our emul packages install in some obscure directory tree
rooted in /emul
if we moved these things to the standard lib32 dirs, it would certainly ease
the pain of people doing multilib building, both in and out of portage
it'd also
someone remind me why our emul packages install in some obscure directory tree
rooted in /emul
if we moved these things to the standard lib32 dirs, it would certainly ease
the pain of people doing multilib building
-mike
pgp0iUxwqWpVd.pgp
Description: PGP signature
11 matches
Mail list logo
