The ebuilds for these versions of mesa depend on xorg-server-1.7 even though the packages themselves do not appear to have such strict dependencies. Reproducible: Always Steps to Reproduce: 1. un-keyword mesa 2. emerge mesa
A bit more info: * The configure script in mesa-7.7 checks for xorg-server >= 1.6.0, but the ebuild requires xorg-server >= 1.7.0. * The configure script in mesa-7.6.1 does not check for the xorg-server version, but the ebuild for this also requires xorg-server >= 1.7.0.
Already fixed, sync again. Thanks *** This bug has been marked as a duplicate of bug 296956 ***
I'm confused -- how does the fix for bug 296956 correct the bug here? That bug is about mesa[gallium] depending on xorg-server; this bug is about the ebuilds for mesa-7.6 and mesa-7.7 requiring too high a xorg-server version. The source configure script for mesa-7.7 only checks for xorg-server-1.7, and the source configure script for mesa-7.6 doesn't check for xorg-server at all. Yet, the ebuilds require xorg-server-1.7 -- why?
Sync again, we've fixed the issue in portage.
Remi, I just synced, and I'm looking at sources.gentoo.org. Why do mesa-7.6.1 and mesa-7.7 block <xorg-server-1.7, when =xorg-server-1.6 is all that is required by mesa-7.7's configure script, and mesa-7.6.1's configure script doesn't check at all?
(In reply to comment #5) > I just synced, and I'm looking at sources.gentoo.org. Why do mesa-7.6.1 and > mesa-7.7 block <xorg-server-1.7, when =xorg-server-1.6 is all that is required > by mesa-7.7's configure script, and mesa-7.6.1's configure script doesn't check > at all? That's because we don't want people mixing stable xorg-server with unstable mesa. We don't usually do this, but the latest mesa releases have been hectic, so we want to play it safe. As for mesa depending on xorg, we've disable that code so now mesa is back to being a library loaded by xorg-server and opengl apps. Thanks
I'm not trying to be difficult, but... :) Using wrong dependencies as a way to block installation of a package just seems like it is asking for trouble. Aren't there various layers of package masking that can be applied? Or just keep the ebuilds in the x11 overlay? Please, wrong dependencies aren't going to stop users from installing something, they just make it confusing for everyone else.
There are combinations especially with gallium which don't work properly with xorg-server-1.6. To save developers the work of finding out which combinations work and which ones fail subtly, it is perfectly reasonable to prevent mixing these versions with blockers. You can always use emerge --nodeps or copy mesa ebuild to a local overlay and modify there if you disagree.
(In reply to comment #8) > There are combinations especially with gallium which don't work properly with > xorg-server-1.6. > > To save developers the work of finding out which combinations work and which > ones fail subtly, it is perfectly reasonable to prevent mixing these versions > with blockers. > > You can always use emerge --nodeps or copy mesa ebuild to a local overlay and > modify there if you disagree. > Hmmm, OK, thank you for the explanation. Yes, I already had made a local copy and changed the xorg-server dependency. Problem with --nodeps of course is that you lose all the correct dependencies too! If there are problems mixing >=mesa-7.6 with xorg-server-1.6, how are you going to receive bug reports on those problems if you've blocked them from mixing? Isn't the fact that those mesa versions are in ~arch sufficient to let users know that there may be problems?
(In reply to comment #9) > If there are problems mixing >=mesa-7.6 with xorg-server-1.6, how are you going > to receive bug reports on those problems if you've blocked them from mixing? We do _not_ want people to mix them accidentally. Lots of people put some packages in ~arch but forget to remove them once those go stable. Again, we don't usually block versions like this. > Isn't the fact that those mesa versions are in ~arch sufficient to let users > know that there may be problems? Sometimes no, as we found out when we put 1.7 in portage. A lot of users mixed ~arch and stable packages and hell broke loose. So closing again. Thanks PS, you don't need to reopen bugs to comment on them. So please try to avoid it. *** This bug has been marked as a duplicate of bug 296956 ***
Well, I reopened it because it is not really a duplicate of #296956, but I'll let it rest. Now I don't want to hear any "I told you so", but in using mesa-7.6.1 with xorg-server-1.6.5, I have noticed that X doesn't resume from suspend very well on my laptop with a Radeon X600. So I unmasked 9999 and got pretty much the same problem. Just letting you know, cheers.
