Created attachment 321356 [details] output of USE="X udev" emerge -pv thunar On a fresh stable amd64 install, with default default/linux/amd64/10.0 profile: USE="X udev" emerge -pv thunar will try to pull several ~amd64 deps including udev. This is due to line 37 in the current thunar-1.4.0.ebuild: udev? ( || ( ${GVFS_DEPEND}[udisks,udev] ${GVFS_DEPEND}[gdu,udev] ) ) The first [udisks,udev] one is for ~amd64 gvfs, so if the user has neither udisks nor gdu in USE, then autounmask tries to unmask all requirements to get ~amd64 gvfs. I believe the order on these should be swapped so that stable users don't get hit with a wall of dangerous autounmask stuff on a fairly typical installation. I have verified that swapping the order will fix the issue on stable amd64-- that is, autounmask just reports a couple of USE changes, rather than a half dozen ~amd64 keywords + USE changes. Now, if a full ~amd64 user tries to do the same thing (wrong USE) after the order was swapped, he may see some funky behavior like a suggested gvfs downgrade, until he or she sets USE=udisks. But IMHO we need to get this fixed for stable users. Tested with freshly unpacked stage3-amd64-20120621.tar.bz2 and portage tree dated Tue Aug 14 14:37:57 UTC 2012.
Probably a duplicate.
The issue is in portage's dep_zapdeps function, since it doesn't distinguish between these two choices. Specifically, it needs to distinguish between two choices that both have unsatisfied USE deps, where one of the choices is more desirable due to IUSE differences between stable and unstable versions.
*** Bug 436672 has been marked as a duplicate of this bug. ***
I can now install gvfs ONLY with my ~amd64 keyword, plus keywording the glib and gobject-introspection. The gvfs version stable 1.12.3-r1 DON'T support USE="udisks" and then not supported by Thunar.
Created attachment 355998 [details] emerge -pv thunar output Can someone from xfce@ take a look at this too? This is still happening when a stable user tries to do: USE="X udev" emerge -pv thunar I cannot see a reason that unstable gvfs is needed at all. It seems like autounmask just gets excited because it will be needed to add USE=udisks on gvfs, but it goes ahead and creates a package.accept_keywords entry as well. Just for a test, I simplified the dep, removing possibility for old gvfs with USE=gdu... so now the dep reads: udev? ( ${GVFS_DEPEND}[udisks,udev] ) ...which can be satisfied just by adding udisks to stable gvfs, but it still tries to pull unstable gvfs. emerge output attached.
Created attachment 356000 [details] USE="X udev" emerge -pvt thunar Here is the output with --tree added... I'm not seeing any extra helpful info, maybe someone else will.
Created attachment 356004 [details, diff] ebuild patch I didn't realize the udisks flag had been masked on stable gvfs. So the issue here is what it always has been. I believe that *stable* thunar's gvfs deps (the udev? ( || ( ) ) construct) should list *stable* gvfs first, then unstable gvfs as a second option. Yes, there's a portage bug here too, probably. But this can be trivially worked around in the ebuild. And I believe the ebuild should be written this way anyway.
Short-term fix -- stabilize a gvfs that works with stable udisks:2 -- see bug 481072. Long-term fix, portage needs to use the second dep in the || () list instead of --autounmask'ing the first one.
that's a pretty bad and conufing bug imo and the average user might not get to the root cause of these ~arch deps being pulled in
