Summary: | gnome-extra/evolution-data-server links to the already-installed libraries | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Diego Elio Pettenò (RETIRED) <flameeyes> |
Component: | New packages | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | Build log |
Description
Diego Elio Pettenò (RETIRED)
2010-12-26 15:23:47 UTC
Created attachment 258118 [details]
Build log
$ qfile /usr/lib/libebook-1.2.so gnome-extra/evolution-data-server (/usr/lib64/libebook-1.2.so) $ qfile /usr/lib/libcamel-1.2.so gnome-extra/evolution-data-server (/usr/lib64/libcamel-1.2.so) so this would actually be a problem with evolution-data-server ? Then eds-2.32 provides libcamel-1.2.so.19 but libcamel-1.2.so.14 is preserved due to other packages using it, see postinst: for lib in libcamel-provider-1.2.so.14 libedata-cal-1.2.so.7 \ libgdata-1.2.so libgdata-google-1.2.so libcamel-1.2.so.14 \ libedata-book-1.2.so.2 libebook-1.2.so.9 \ libedataserver-1.2.so.13 libecal-1.2.so.7 libedataserverui-1.2.so.8 do preserve_old_lib_notify /usr/$(get_libdir)/$lib done Could it be that your system still has the old lib when it should not ? Should have, shouldn't have - it depends. But, if the problem lies in evolution-data-server, it may come from la file deps ordering in Makefile.am. In addressbook/libebook/Makefile.am, libebook_1_2_la_LIBADD starts with $(top_builddir)/addressbook/libegdbus/libegdbus-book.la $(top_builddir)/camel/libcamel-1.2.la in addressbook/libegdbus/Makefile.am, libegdbus_book_la_LIBADD is $(E_DATA_SERVER_LIBS) in configure.ac, E_DATA_SERVER_DEPS="gio-2.0 libxml-2.0 libsoup-2.4 gconf-2.0 $mozilla_nspr" I think that this has an effect of linking to system libs first. Flameeyes, do you agree ? How could I try to reproduce this problem to report to upstream if needed? Thanks (In reply to comment #2) > $ qfile /usr/lib/libebook-1.2.so > gnome-extra/evolution-data-server (/usr/lib64/libebook-1.2.so) > $ qfile /usr/lib/libcamel-1.2.so > gnome-extra/evolution-data-server (/usr/lib64/libcamel-1.2.so) > > so this would actually be a problem with evolution-data-server ? > > Then eds-2.32 provides libcamel-1.2.so.19 but libcamel-1.2.so.14 is preserved > due to other packages using it, see postinst: > > for lib in libcamel-provider-1.2.so.14 libedata-cal-1.2.so.7 \ > libgdata-1.2.so libgdata-google-1.2.so libcamel-1.2.so.14 \ > libedata-book-1.2.so.2 libebook-1.2.so.9 \ > libedataserver-1.2.so.13 libecal-1.2.so.7 libedataserverui-1.2.so.8 > do > preserve_old_lib_notify /usr/$(get_libdir)/$lib > done > > > Could it be that your system still has the old lib when it should not ? > Anyway, even if I generally agree with using preserve_old_lib, for this case, it was really a headache to run a ton of revdep-rebuild && rm ... commands and I would have preferred to simply run a revdep-rebuild command after updating evolution -> What about simply dropping preserve_old_lib for this case? No, there is no case where it is wrong. When there is so many libs, the user simply needs to run revdep-rebuild either without arguments or with a full list at once, not one lib by one. The postinst info is not ideal but we are holding hands enough already. I thought running "revdep-rebuild" without arguments would simply don't rebuild anything if I don't manually remove every old lib before. And about running revdep-rebuild with multiple arguments... it would probably be the best option, but current information provided by eclass points to the opposite direction :-/ (Looks like new bugzilla add people to CC list by default :-S) If the problem lies where I placed it in comment 3, preserve_old_lib just hides the problem, without fixing a thing. Cause in that case evolution isn't broken in this context. (In reply to comment #9) > If the problem lies where I placed it in comment 3, preserve_old_lib just hides > the problem, without fixing a thing. > Cause in that case evolution isn't broken in this context. The excerpt you posted look fine. The problem with preserve_old_libs is that people don't understand they should revdep-rebuild just after the upgrade, not days later. It is a temporary solution to not break your desktop instantly on upgrades, not a long term "fix". (In reply to comment #3) > Should have, shouldn't have - it depends. > But, if the problem lies in evolution-data-server, it may come from la file > deps ordering in Makefile.am. > In addressbook/libebook/Makefile.am, libebook_1_2_la_LIBADD starts with > $(top_builddir)/addressbook/libegdbus/libegdbus-book.la > $(top_builddir)/camel/libcamel-1.2.la > in addressbook/libegdbus/Makefile.am, libegdbus_book_la_LIBADD is > $(E_DATA_SERVER_LIBS) > in configure.ac, E_DATA_SERVER_DEPS="gio-2.0 libxml-2.0 libsoup-2.4 gconf-2.0 > $mozilla_nspr" > > I think that this has an effect of linking to system libs first. > Flameeyes, do you agree ? Should we report this to upstream then? (In reply to comment #11) If you can confirm it, yes. It wouldn't be the first gnome package to receive such fix - it's quite easy to escape notice, after all Personally, I'd rather not get involved with a lib I don't really care about. IIRC, as long, as silent make isn't used, the proof either for or against should be visible in evolution-data-server build log (or in the *build tree* la file). However, can this still be reproduced ? Outside portage, that is - I've tried a little test and it seemed to link correctly. Actually, I can't reproduce it even with portage - 'ldd -r' output for libebook is clean and complete for upgrade from gnome-extra/evolution-data-server-2.30.0 to 2.32.2. I would close this if nobody is able to reproduce :-| Wasn't a patch for a similar problem provided for evolution-3 by tetromino recently? +*evolution-data-server-2.32.3 (19 Jun 2011) + + 19 Jun 2011; Pacho Ramos <pacho@gentoo.org> + +evolution-data-server-2.32.3.ebuild, +files/fix_relink_command.pl: + Version bump, also fix bug #349782 (linking problems) with tetromino's + solution. + |