symlinks deleted on upgrade, but not during reinstall

John H uothrawn at
Tue Sep 27 17:18:35 UTC 2011

----- Original Message -----
> From: Jeff Johnson <n3npq at>
> To: John H <uothrawn at>
> Cc: 
> Sent: Tuesday, September 27, 2011 11:31 AM
> Subject: Re: symlinks deleted on upgrade, but not during reinstall

> Good, you've diagnosed most of what is happening already.
> Try strace -f (to follow into all the helpers) and look for unlink calls from
> /sbin/ldconfig removing the symlink(s).
> Expect a huge amount of spewage from strace. You can try adding "-e 
> unlink", but
> then you will lose the other context thyat is often useful from starching 
> through
> a hugely complex operation involving multiple processes.

Heres what it looks like is happening: the install of my openldap-2.4 is creating this symlink properly:

/usr/lib/ ->

In the %post install of my openldap-2.4, ldconfig is reassigning this symlink to point to "".  Then, in the uninstall of openldap-2.3, is removed, but in its %post section ldconfig is removing my symlink (/usr/lib/ because it no longer has a valid target.

How can I get ldconfig to not mess with my files ?

> What's likely happening is that running /sbin/ldconfig is removing the 
> symlinks.
> And the like (just guessing) reason is that the soname within the library 
> executable
> disagrees with the symlinks you are attempting to package.
> Use readelf -a to display the internal SONAME.

readelf -a gives an SONAME of for my symlink (as expected, given its a symlink). For the openldap-2.3.43 package, the SONAME is  As one would expect... Is this a concern? LDAP-based login functionality works if I have a symlink even though the SONAME is wrong.


> On Sep 27, 2011, at 10:34 AM, John H wrote:
>>  I'm using CentOS 5.6 32bit with the stock OpenLDAP 2.3.43 and 
>> attempting to build an RPM for OpenLDAP 2.4.23.  A lot of things in CentOS 5.6 
>> depend on (among other 2.3 libs), so in my 2.4 specfile, I am 
>> creating a symlink in my %install section: 
>>  ln -s $RPM_BUILD_ROOT/usr/lib/
>>  And adding a Provides tag of "".
>>  However, whenever I upgrade the package (rpm -Uvh), the symlink isn't 
>> installed. I can then reinstall it, and have the symlink be available. My %files 
>> section has these definitions, so the symlink is definitely getting into the 
>> RPM:

More information about the Rpm-list mailing list