Apparently, libcurl was upgraded from libcurl.so.2 to libcurl.so.3 (probably by 'emerge -uavD world'). However, darcs is still linked against the old version. Shouldn't either darcs be recompiled, or libcurl.so.2 retained (if darcs depends on this particular version, which I don't think it does)? PS: Any reason darcs is stuck at 0.9 or so? Are we waiting for the dust to settle around 1.0 before unmasking it? Reproducible: Didn't try Steps to Reproduce: 1. 2. 3.
darcs works just fine with libcurl.so.3. I think this is a general problem with upgrading libraries, and I don't see that current portage can do anything about it. Please educate me if I am wrong. You'll just have to re-emerge darcs and it should work. I'll try to move darcs-1.0.0 to x86 soon. ks
You are right, of course. I don't know portage well enough to know if it can be done, but I think there should be a way to specify this (i.e. that dependent packages must be rebuilt (relinked) when a library version is upgraded). It certainly is annoying when one upgrade breaks other packages. (Could it be part of the problem that libcurl is part of the curl package, and independently versioned? I also note the curl ebuild contains: # backwards compat link dosym libcurl.so.3 /usr/$(get_libdir)/libcurl.so.2 but I don't get the symbolic link, so maybe I misinterpret what this is about?) So, to sum up, I don't know if this should be turned over to the curl maintainer to do something about the versioning, and/or the ebuild process needs to be improved, or whether we just have to accept things as they are, and resolve to WONTFIX or whatever.
I had another machine where libcurl had not yet been upgraded, and could reproduce the problem: When the ebuild merges, it does merge the compatibility symlink: >>> Merging net-misc/curl-7.12.0-r2 to / --- /usr/ --- /usr/lib/ >>> /usr/lib/libcurl.so.3.0.0 >>> /usr/lib/libcurl.so.3 -> libcurl.so.3.0.0 >>> /usr/lib/libcurl.so -> libcurl.so.3.0.0 >>> /usr/lib/libcurl.la >>> /usr/lib/libcurl.a >>> /usr/lib/libcurl.so.2 -> libcurl.so.3 --- /usr/share/ [...] However, emerge goes on and unmerges the old package, and removes the symlink again: >>> Unmerging net-misc/curl-7.11.0... No package files given... Grabbing a set. [...] <<< obj /usr/lib/libcurl.so.2.0.2 --- !mtime obj /usr/lib/libcurl.la --- !mtime obj /usr/lib/libcurl.a --- !mtime obj /usr/include/curl/types.h --- !mtime obj /usr/include/curl/stdcheaders.h --- !mtime obj /usr/include/curl/multi.h --- !mtime obj /usr/include/curl/mprintf.h --- !mtime obj /usr/include/curl/easy.h --- !mtime obj /usr/include/curl/curl.h --- !mtime obj /usr/bin/curl-config --- !mtime obj /usr/bin/curl <<< sym /usr/lib/libcurl.so.2 Now, something definitely doesn't work as intended here, but I cannot judge if it is a problem with portage or the curl ebuild. I can only say that it isn't a problem with the darcs ebuild. The curl maintainer is listening, as far as I can see. liquidx, could you comment on this? ks
yeah, there's something not right with the curl upgrade and i haven't gotten round to this yet. do you mind if i reassign to myself so i don't forget this?
Not at all. Reassigning ...
It is now causing problems with Apache2 for me. Same symptoms/cause as for this existing bug (filed here to avoid creating duplicate)
Negative report, but I came across this as I was about to file a bump bug, and can at least mention that in February '05, I'm not having darcs or curl problems. AfC
libcurl has much smarter internals now that should of fixed this bug.
