J.R.:
> Which architecture? If you refer to amd64,
> fglrx-driver 8.42.3-2, what happens is that the
> package does not use the ati version of libGL, but it
> does not remove the diversion created in previous
> versions. Use dpkg-divert to eliminate the diversions
> and then re-install libgl1-mesa-glx.
Thx that's a good hint. It's legacy i686 here though.
As you can see i'm not used to diversion problems, and try to figure now what
to do in this case.
Since it appears to be a problem on package level i looked into fglrx-driver
doc and found
fglrx-driver (8.24.8-1) unstable; urgency=low
* Upgrading from previous versions is quite tricky because libGL is moving
from /usr/X11R6/lib to /usr/lib and I couldn't figure out a completely
safe way to upgrade the libGL diversion. Upgrading should in fact work
just fine, but downgrading to previous versions and recovery from errors
during upgrades are broken.
Therefore, I recommend to completely remove previous versions of this
package before installing. Sorry for any inconvenience this may cause.
-- Flavio Stanchina <@> Sat, 15 Apr 2006 13:05:31 +0200
Since i already tried reinstall fglrx-driver in the first place, i gave your
suggestion a try anyway. I deleted the symlink and reinstalled libgl1-mesa-glx
7.0.1-2 - but still nothing changed:
dpkg-divert libGL.so.1
diversion by fglrx-driver from: /usr/lib/libGL.so.1
diversion by fglrx-driver to: /usr/lib/fglrx/diversions/libGL.so.1
libgl1-mesa-glx: /usr/lib/libGL.so.1
diversion by fglrx-driver from: /usr/lib/libGL.so.1.2
diversion by fglrx-driver to: /usr/lib/fglrx/diversions/libGL.so.1.2
libgl1-mesa-glx: /usr/lib/libGL.so.1.2
diversion by fglrx-driver from: /usr/lib/libGL.so.1.2
diversion by fglrx-driver to: /usr/lib/fglrx/diversions/libGL.so.1.2
diversion by fglrx-driver from: /usr/lib/libGL.so.1
diversion by fglrx-driver to: /usr/lib/fglrx/diversions/libGL.so.1
....but no symlink at all was created in /usr/lib
This is todays update, apt-cache policy:
fglrx-driver:
Installed: 8.42.3-2
Candidate: 8.42.3-2
Version table:
*** 8.42.3-2 0
500 http://ftp.de.debian.org unstable/non-free Packages
100 /var/lib/dpkg/status
8.40.4-2 0
500 http://ftp.de.debian.org testing/non-free Packages
Reinstalling fglrx-driver once again didn't improve the situation.
I think that says it all and i could as well close the thread here.
But i've still some questions.
Can i safely 'plug in' a custom diversion and symlink to /usr/lib/libGL.so.1 ?
What will happen when package maintainers fix it on package level but i would
update only much later, to another major version, which maybe provides just
another path than /usr/lib ?
To illustrate the situation a little bit, i purged the libgl1-mesa-glx package
with apt and also deleted the deb package file in /var/cache - just to satisfy
a nagging paranoia -, which lead to a new diversion /usr/lib/libGL.so.1 ->
/usr/lib/libGL.so.1.5.xyz. The diversion libgl.so.1 placed in fglrx/diversions
was a broken symlink after that, as libGL.so.1.2 was gone. After reinstallation
of libgl1-mesa-glx, the symlink /usr/lib/libGL.so.1 was gone without any
replacement.
Apparently the package insista on placing the diversion into
/usr/lib/fglrx/diversions.
And obviously packages like googleearth, xscreensaver-gl, and even fglrx-driver
commandline tools, don't have it in their path.
A less related topic (i hope):
I also note that i although i've fglrx-control installed, i can't the heck find
any GUI neither on commandline nor in KDE controlcenter nor in the Debain menus.
The commandline tool 'aticonfig' is part of fglrx-driver so that should be
another one.
dpkg -L showed me /usr/bin/amdcccle (never seen this name before!) which
launches a guru w/o any error message despite the custom symlink, and meanwhile
i've installed the libGLmesa dbg package too.
I'm not sure what to do next. Maybe just leave it with the dirty symlik, and
try to remember it's there when in some months maybe running into trouble with
another update to libGLso.1.3 ....?
--
m°
