Bug 836730

Description of problem: this could be a bug in rpm or an incorrect symlinking structure of libevent libraries, but when performing a rpm -Va the following files which need attention appear:

....L....    /usr/lib/libevent-2.0.so.5
....L....    /usr/lib/libevent_core-2.0.so.5
....L....    /usr/lib/libevent_extra-2.0.so.5
....L....    /usr/lib/libevent_openssl-2.0.so.5
....L....    /usr/lib/libevent_pthreads-2.0.so.5

when looking further into this the symlinks resolve fine, however for the above libraries a construct like:

libevent_core-2.0.so.5 -> libevent_core.so -> libevent_core-2.0.so.5.1.6 is used. I.e.

libevent_core-2.0.so.5 is symlinked to another symlink: libevent_core.so and next libevent_core.so is symlinked to the real library, while normally the structure would be, if translated from above:

libevent_core-2.0.so.5 -> libevent_core-2.0.so.5.1.6
libevent_core.so -> libevent_core-2.0.so.5.1.6

I've got the feeling that the above messages from rpm -Va stem from the symlink to symlink chain. 

Question: is it correct that rpm -Va is complaining about the above 'symlink to symlink to library' chained construct for libevent_core or is the structure of the symlinking for these libraries wrong and is rpm -Va is correct in complaining?


Version-Release number of selected component (if applicable): 

libevent-devel-2.0.18-1.fc17.i686.rpm


How reproducible: always


Steps to Reproduce:
1. run rpm -Va on F17 with package libevent-devel-2.0.18-1 installed.
2. filter for libevent
3.
  
Actual results:

see above

Expected results:

no message from rpm -Va either by having libevent-devel have it's symlinking structure fixed or rpm -Va accepting the above symlinking constructs.


Additional info: