I have two machines (both ~amd64) and updated net-misc/curl from 7.24.0 to 7.25.0 recently. Now the one machine (hostname miramis) wants to rebuild about 80 packages that link against libcurl. The other machine (hostname ayanta) doesn't want to rebuild packages. Now I checked which files are installed by curl: On ayanta it's "/usr/lib64/libcurl.so.4.2.0", on miramis it's "/usr/lib64/libcurl.so.5.2.0". With the USE-flags beeing identical this is very strange and should not be happening that way. I'll attach: "emerge --info", "build.log" and "config.log" from both machines Reproducible: Always
Created attachment 306761 [details] machine miramis: emerge --info
Created attachment 306763 [details] machine ayanta: emerge --info
Created attachment 306765 [details] machine miramis: build.log
Created attachment 306767 [details] machine ayanta: build.log
Created attachment 306769 [details] machine miramis: config.log.xz compressed due to bugzillas size limit
Created attachment 306771 [details] machine ayanta: config.log.xz compressed due to bugzillas size limit
URL is where curl devs point me. Nevertheless: I just found a note in net-misc/curl's ChangeLog: 26 Mar 2012; Anthony G. Basile <blueness@gentoo.org> curl-7.25.0.ebuild: Forcing a bump to the soname unnecessarily breaks backwards compat So I'll mark this RESOLVED OBSOLETE. But this went quite sh**y for me. miramis is building all the packages (including libreoffice) again, just because the SONAME has been downgraded again :( Gentoo.... still compiling ...
The same happens here after reemerging of curl-7.25.0: root@condor:/root(4)# genlop -t curl | tail Fri Jan 27 01:05:52 2012 >>> net-misc/curl-7.24.0 merge time: 2 minutes and 19 seconds. Sun Mar 25 05:23:09 2012 >>> net-misc/curl-7.25.0 merge time: 2 minutes and 18 seconds. Sun Apr 8 02:51:22 2012 >>> net-misc/curl-7.25.0 merge time: 1 minute and 51 seconds. /usr/lib/libcurl.so.5.2.0 changed to /usr/lib/libcurl.so.4.2.0 and revdep-rebuild rebuilds 41 packages including virtualbox, libreoffice etc.