Description of problem: Both postuninstall and postuninstall script of the x86_64 arch of this package still use "/usr/lib/sane" when appending to or removing from /etc/ld.so.conf. This causes ldconfig to never look at /usr/lib64/sane, and to error out when looking for /usr/lib/sane: ldconfig: Can't stat /usr/lib/sane: No such file or directory Version-Release number of selected component (if applicable): RHEL3 for AMD64 arch Solution: Please don't fork the code to handle this... have the rpm's scripts intelegently look for /usr/lib*/sane and go from there
? Ping!
(Not sure why this got missed.) The current sane-backends branch for RHEL3 has these changes from the latest available code: * Fri Jan 2 2004 Tim Waugh <twaugh> 1.0.9-5.5 - Remove %%{_libdir}/sane from ld.so.conf on upgrade. * Wed Dec 24 2003 Tim Waugh <twaugh> 1.0.9-5.4 - Don't run ldconfig in %%{_libdir}/sane even in %%install. * Tue Dec 16 2003 Tim Waugh <twaugh> 1.0.9-5.3 - Put rpath tricks back in but take out ld.so.conf tampering (better fix for bug #110174). * Thu Dec 4 2003 Tim Waugh <twaugh> 1.0.9-5.2.1 - Rebuilt. * Thu Dec 4 2003 Tim Waugh <twaugh> 1.0.9-5.2 - Fix rpath in backends (bug #110174). and so I believe the problem is already fixed, albeit in a different way. Can I get you to try out the 1.0.9-5.5 packages, if I put them somewhere you can get at them, to see if they fix the problem you see? Then we can try to get them into a future quarterly update.
Sure... email me the location
Here it is: ftp://people.redhat.com/twaugh/tmp/sane-backends-120411 Let me know if these packages look okay. Thanks.
I must be missing something... now there is no mention of sane anything in ld.so.conf. Is this what you indended? Actually, I do see this from ldconfig -v: /usr/lib64: libsane.so.1 -> libsane.so.1.0.9 So it appears that the .so files are simply being included in a better place, and ldconfig isn't complaining anymore as a result.
It is intentional, yes. Does sane work for you properly with these packages?
Truth be told I don't have a scanner attached to my remotely managed Opteron server :-) However, I can run saned and it is able to open libsane in its startup process: open("/usr/lib64/libsane.so.1", O_RDONLY) = 3 Don't know if that is enough of a test... but really I opened the case for the ldconfig error messages that were produced. That case at least can be closed... do you have a scanner and an Opteron box to test further?
I'm satisfied that this is fixed. Tim, are these changed commit for future versions of Fedora and RHEL3/4 ??
Yes. If Fedora Core development isn't doing the right thing I don't know about it.
Excellent. Thanks Tim!