I'm working on a script to fix the x11-base/xfree depends, but some things still demand specific versions of X. I'm going to say that realisticly, if the user has X, emerge -uUDav world is going to upgrade it. for i in `find /usr/portage -name \*.ebuild`; do cat $i | grep "x11-base/xfree" && cat $i | sed -e "s/x11-base\\/xfree/virtual\\/x11/g" | sed -e "s/=virtual\\/x11/virtual\\/x11/g" | sed -e "s/>virtual\\/x11/virtual\\/x11/g" | sed -e "s/virtual\\/x11-[0-9].[0-9].[0-9]/virtual\\/x11/g" | sed -e "s/virtual\\/x11-r[0-99]/virtual\\/x11/g" | sed -e "s/virtual\\/x11-\${PV}/virtual\\/x11/g" | sed -e "s/virtual\\/x11-\[0-9\]/virtual\\/x11/g" | sed -e "s/virtual\\/x11\*/virtual\\/x11/g" | sed -e "s/virtual\\/x11-\[0-9\]/virtual\\/x11/g" | sed -e "s/virtual\\/x11[1-9]/virtual\\/x11/g" | sed -e "s/virtual\\/x11-\[0-9\]/virtual\\/x11/g" | sed -e "s/virtual\\/x11-4.0/virtual\\/x11/g" > /tmp/ebuild.tmp && cat /tmp/ebuild.tmp > $i; done This is crude, but it works. As gentoo moves away from xfree, you won't be able to depend on specific xfree versions anymore; and all of the old xfree versions are surpassed by xorg-x11, which is based on the code from xfree 4.4 cvs pre-x11 license. I'm testing this out now. There's probably a few misses, like on one ebuild that greps around in /var/db/pkg for 'sdk' in xfree's compile time USE flags. This is a good kickstart but it's likely to have some regression, and you may want to buff that out for a few days rather than just slam it into portage. On the other hand, you could just run it, have a few devs test it, and if it doesn't cause any real breakage, commit the changes to portage and worry about regressing it for the next few days. If you did that, the devs would all be able to emerge sync to see which builds are corrected; but that may look unelegant, even if it doesn't really break anything. It may be more elegant to work on it on your end before committing anything to the portage tree. An example of this type of nondestructive regression would be xfree drivers that work for XFree 4.1 but not 4.3. They won't work with xorg-x11, and so should depend on x11-base/xfree; however, having them depend on virtual/xfree won't really break anything unless the user tries to use them with xorg-x11 or xfree-4.3.0.
do this with for i in `find /usr/portage/metadata` as well, else it tries to get xfree anyway.
Created attachment 27880 [details] ebuild_alter.sh : alter ebuilds for x11 This is a script I made from the earlier comment. It runs through your portage tree and portage cache and alters the ebuilds and portage cache to depend on virtual/x11 instead of *x11-base/xfree* It works for me fine, but your mileage may vary. Test it on your own box before submitting anything to the portage tree.
This is not the correct way for us to do it, although it may work fine for you locally. Every altered ebuild needs to be _proven_ to work with all packages supplying the virtual (at this point xfree and xorg-x11 are expected). They can all be assumed to work with xfree and therefore need to be tested on xorg-x11. Therefore, the correct way to close this bug is to get a listing of all ebuilds depending on x11-base/xfree in any way (a grep -rl x11-base/xfree /var/cache/edb/dep seems to work, sort of). If you'd like to collect and sort such a list by category/package-version, it would be quite helpful. It'd be even more helpful to have the associated herds.
Created attachment 27905 [details] 414 package world rebuild This is output from `emerge -euUDpv world` You can see I've slipped abi-word 2.1.0 in there (but abi depends on virtual/x11 anyway), dillo 0.8.0, and xchat 2.0.8. I version bumped all of these myself, which is why they're not in an overlay; it was a quick hackjob. I also use several overlays. Only a few packages come from these overlays though; most come from the portage tree. Because the overlay number is displayed by these, you can clearly see which come from where. I've also unmasked gnome. The ebuilds do come from the portage tree. I'll tell you how it works out. Of the 305 ebuilds that my script altered on my machine, I probably only hit a few that didn't already depend on virtual/x11; but it's a start, right? If anything breaks, I'll inform you. My intent was exactly this. The developers can do the same thing I'm doing here on their own boxes to track down what's what. I'll probably make a quick hack and give you a new ebuild_alter.sh to spit out which files are altered, so you can track it better. I should have thought of that earlier, but better late than never.
Created attachment 27906 [details] new ebuild_alter.sh New ebuild_alter.sh script. This one actually spits out all altered files to ~/ebuild_alter.list This will let you examine what files were altered by the script, and thus, directly target your efforts for checking them for misses (i.e. why in the heck does this alter xfree's ebuild?) and for breakage (do things still have proper dependencies and still merge properly?). Thus, you may go on a case-by-case basis and see if the script did any damage. Each ebuild that it properly alters without regression should be commitable (assuming it makes sense; xfree-specific drivers and such don't make sense with i.e. kdrive). Sorry, I feel I may have miscommunicated my intentional use of this thing earlier. Hopefully here I have covered both what my intent was and fixed the script to be able to properly support that intent. I hope this is useful.
I seem to have misread your previous comments. I get what you're saying now. My aims were wrong. Sorry for wasting your time. it was a lack of understanding of the issue on my part
Marking invalid in favor of bug #45610.
As a side note, should non-fully-compatible X11's provide virtual/x11? It is my understanding that i.e. x11-base/kdrive does not work with gtk+1.2 apps, but also does not PROVIDE="virtual/x11". I was told that only fully complient x11 builds should supply virtual/x11. Is this a rule? If so, then the comment made in #3, This is not the correct way for us to do it, although it may work fine for you locally. Every altered ebuild needs to be _proven_ to work with all packages supplying the virtual (at this point xfree and xorg-x11 are expected). They can all be assumed to work with xfree and therefore need to be tested on xorg-x11. would be a little backwards; more likely, when a package is found to not work with a certain virtual/x11 supplying package, it should be determined if that package is bugged or if the x11 is noncompliant (bugged), and thus that should be addressed. If the x11 is the problem, it should lose its virtual/x11 until the bug is fixed. Is this a backwards view of things?
The virtual/x11 is really for the libraries, not the server, since that's what other programs build against. kdrive doesn't make any sense to have virtual/x11 -- xlibs do. Giving and taking a virtual/x11 all the time would be complete havoc. Nobody would ever have any idea whether their preferred implementation was valid at any given time and would be switching back and forth whenever we found a bug.
true. But if it were a "bug" rather than an "unimplimented feature," it's assumed you wouldn't remove the virtual/x11; it's still compliant, although broken. If it were "Does not actually support X window drawing method Foo, and won't for 5 more releases," that'd be something to pull virtual/x11 for. If it was "We broke the x_DrawWindow() function, we'll fix it in our next revision," that'd just be a bug.
