Am Samstag, den 10.12.2005, 17:00 -0800 schrieb Donnie Berkholz:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Ben Skeggs wrote:
> | Am Freitag, den 09.12.2005, 23:12 +0000 schrieb Donnie Berkholz:
> |
> |>2) Users with no X installed will pull in the virtual/x11 package
> |>because there is no longer a default virtual.
> |
> | A user in #gentoo-amd64 ran into issues with this that I reproduced in a
> | chroot.  On a new install, with no X installed you end up with messages
> | saying that virtual/x11 is blocking x11-base/xorg-x11-6.8.2-r6.
> |
> | ie, Here's what happens when you attempt to merge aterm:
> | http://members.iinet.net.au/~darktama/aterm_merge.log
> |     
> | I'm not an expert, but the xorg-x11 ebuild has "!virtual/x11" in
> | DEPEND/RDEPEND, could this be why?
> 
> Already been fixed some hours ago.
Yup, I noticed that soon after I posted this.  Thanks.

> 
> |>I hope that covers pretty much everything right now.
> |
> | When porting ebuilds to modular, how do we intend on handling the other
> | x11 virtuals in DEPEND/RDEPEND?  I'm assuming that we modify it so that
> | the modular dependencies depend directly on media-libs/mesa etc, and
> | leave virtual/opengl as the alternative?
> |
> | Or should I just wait until the real virtual/{opengl,xft,glu,glut}
> | ebuilds exist before touching packages that need them?
> 
> The other ones should just stay the same as they are. virtual/x11 was
> different because it was one virtual covering something that split into
> hundreds of separate packages. But xft, opengl, glu are just changing
> <=xorg-x11-6.99 into libXft, mesa, mesa respectively so that will
> require no porting work, just more true "virtual" packages to be added.
Ah, I see.  That makes sense now actually, I'll hold off modifying
packages that depend on those virtuals until the "real" virtuals for
them are in place.

Thanks,
Ben.
-- 
[email protected] mailing list

Reply via email to