I'd like to add my vote to those that are proposing a more "brute force migration". By this I mean a bulk update of the dependency files.
I'm not saying to do it in the next 24h, but don't wait for many weeks or month with it. Because as we have seen with the long running "openssl saga" many maintainers don't care, don't know or forget about it and choose or leave the old version in the .dep files. That means the new version does not really get tested. Even freshly build extensions in that case were continuing to refer to the old version. In my view a bit a forceful approach is quite in order here. In particular as TC 3.0 is not yet declared stable I see more of a chance to break things now then at a later point in time. OTOH lets face it: TC is (at least in my view) not really meant to be as "rock-solid" as RH.
If my counting is not off there are 32 extensions in the 3.x repository that depend on Xorg-7.4.tcz directly. Add to this 10 extensions which refer to Xorg-7.4-dev.tcz. I wonder how many of those really need the "full" Xorg extension or if some could get away for example with Xorg-7.5-bin.tcz. In any case it should be really well understood what aspect of any 'Xorg' extension it is that another one needs. For example some application might "just work" with Xorg-7.5.tcz but it would have already done so with 'Xvesa', but using Xorg-7.5-3d.tcz is what really makes a difference. OTOH it's the question to which degree our .dep files should reflect "minimal requirements" or "best performance". IMHO the .dep file should only include the absolute minimum and anything else should be noted in the .info file.
I also tried to find out who are the maintainers of those 32 extensions:grep "Xorg-7.4\." *.dep | sed 's#\.dep.*##' | while read e ; do
t=$( grep 'Title' ${e}.info | tr '\t' ' ' | sed 's#.*: *##' )
m=$( grep 'Extension_by' ${e}.info | tr '\t' ' ' | sed 's#.*: *##' )
printf "%-30s%s\n" "$m" "$t"
done | sort
Althalus plt.tcz
Arslan S. cairo-clock.tcz
Arslan S. clutter.tcz
Arslan S. compiz-base.tcz
Arslan S. compiz-gnome.tcz
Arslan S. compiz.tcz
Arslan S. dreamchess.tcz
Arslan S. freeglut.tcz
Arslan S. ftgl-dev.tcz
Arslan S. ftgl.tcz
Arslan S. gnome-desktop-base.tcz
Arslan S. gtkglext.tcz
Arslan S. hedgewars.tcz
Arslan S. nvidia-glx.tcz
Arslan S. pinball.tcz
Arslan S. projectM.tcz
Arslan S. teeworlds.tcz
Arslan S. vinagre.tcz
Arslan S. vino.tcz
Curaga Mplayer-xorg.tcz
Curaga, Robert Schumann wine-gl-dev.tcz
Curaga, Robert Schumann wine-gl.tcz
Jason W kdelibs-3.5.10.tcz
SvOlli qt-4.5-opengl.tcz
SvOlli qt-4.x-opengl.tcz
bmarkus bigforth.tcz
bmarkus lxrandr.tcz
bmarkus xplanet.tcz
juanito synaptics.tcz
robc mupen64plus.tcz
robc recordmydesktop-gtk.tcz
wonderfulll xf86-video-unichrome.tcz
So a lot of the responsibility rests with just a few people. Maybe we can spread out some of the testing, but I hate to admit that I'm not a regular user of any of those so my "expertise" in helping out might be rather limited.
Furthermore trying to create new extensions to extend the usability of 'Xorg-7.4' is in my view fatal. It would only increase the confusion. I'm of the opinion that a "short & sharp" period of "pain", is much better than a "long suffering". Therefore a speedy change from Xlibs_support.tcz to Xorg-7.5-lib.tcz might be the first thing to do.
If people see the need I could try to undertake a similar analysis (based on 'ldd') as I once did for 'openssl'. I'm just worried that it might take a few days and I urgently need to send my (main) laptop into repair before the warranty runs out. That limits my ability of doing this in the short term.
If a "forceful migration" in the near future is not acceptable I'd like to propose that at least no update of any extension (and no new one) makes it into the repository that still uses Xorg-7.4.tcz (or Xlibs_support.tcz). That way the issue should at least not continue to grow over time.
Welcome
FAQ
Downloads
Wiki
