Tiny Core Extensions > TCE 3.x
Xorg 7.5
curaga:
--- Quote from: Arslan S. on June 07, 2010, 11:50:35 AM ---nvidia has no source to build except kernel interface layer
--- End quote ---
Oh, then you could just remove Xorg from the dep file and tell to pick either version in the info.
--- Quote ---why not just convert everything and only rebuild extensions that really needs it ?
--- End quote ---
We don't know which they are, it's better for the extension maintainers to handle it.
--- Quote ---otherwise one may mess up with Xorg-7.4 and Xorg-7.5 installed at the same time :)
btw i have Xorg-7.5 and nvidia-glx installed but i didn't load Xorg-7.5-3d, what is really in it, some open source drivers ?
--- End quote ---
Yeah, the Mesa drivers.
jur:
Might be good to do something about all the extensions that have Xorg-7.4 as dep, to either duplicate them temporarily with Xorg-7.5, or perhaps to list them somewhere so users can edit the dep files after every update.
maro:
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:
--- Code: ---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
--- End code ---
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.
Arslan S.:
maro thanks for the list, i was wondering how many extensions out there that depends on Xorg-7.4, i will test one by one and rebuild/update if required
my opinion is that there should not be two versions of same extension in the repository
most of the extensions which i created depends on Xorg because they are 3D applications, some games, OpenGL based libraries and a desktop which requires xkb, some Xorg executables, xrandr etc.
major version of OpenGL is same libGL.so.1 in Xorg-7.4 and Xorg-7.5
maro:
Arslan, I trust you are aware which executables are now available via Xorg-7.5-bin.tcz (e.g. 'xrandr' being one of them). Hence that might reduce the requirements in a disk-space friendly way.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version