Bug 120411

Summary: x86_64 arch not correctly appending to ld.so.conf breaking ldconfig
Product: Red Hat Enterprise Linux 3 Reporter: Joshua Jensen <joshua>
Component: sane-backendsAssignee: Tim Waugh <twaugh>
Status: CLOSED NEXTRELEASE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-10-15 20:30:59 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Joshua Jensen 2004-04-08 15:07:53 UTC
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

Comment 1 Joshua Jensen 2004-06-11 21:12:10 UTC
?

Ping!

Comment 2 Tim Waugh 2004-06-25 08:13:35 UTC
(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.

Comment 3 Joshua Jensen 2004-06-25 15:13:15 UTC
Sure... email me the location

Comment 4 Tim Waugh 2004-06-28 11:12:29 UTC
Here it is:

ftp://people.redhat.com/twaugh/tmp/sane-backends-120411

Let me know if these packages look okay.  Thanks.

Comment 5 Joshua Jensen 2004-07-01 19:29:53 UTC
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.

Comment 6 Tim Waugh 2004-07-02 08:54:32 UTC
It is intentional, yes.  Does sane work for you properly with these
packages?

Comment 7 Joshua Jensen 2004-07-02 17:52:10 UTC
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?

Comment 8 Joshua Jensen 2004-10-06 15:33:10 UTC
I'm satisfied that this is fixed.  Tim, are these changed commit for
future versions of Fedora and RHEL3/4 ??

Comment 9 Tim Waugh 2004-10-06 16:29:27 UTC
Yes.  If Fedora Core development isn't doing the right thing I don't
know about it.

Comment 10 Joshua Jensen 2004-10-15 20:30:59 UTC
Excellent.  Thanks Tim!