[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ATI fglrx driver on sid



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°



Reply to: