Hi, I've seen that the new "clean by default" portage behavior is currently discussed on gentoo-dev ml... Here is an example of a bad consequence, where an actual runtime dependency is stronger than the ebuild dependency protected from cleaning: - I've installed sylpheed-claws 0.8.5 while aspell-0.50.1 was installed - I've then upgraded to aspell-0.50.2 - libaspell-common-0.50.1.so deleted by portage cleaning - sylpheed-claws then refused to start, because it was still looking for libaspell-common-0.50.1.so I don't know why it was looking for the minor version installed while compiling and not the symlink (libaspell-common.so, or at least libaspell-common.50.so), but "ldd" output was explicit. It's probably just a sylpheed-claws bug. I had to reemerge it. Now, "ldd" still gives me a dependency on the minor version, so the problem will occur again when I upgrade aspell: thomas@gromit thomas $ ldd /usr/bin/sylpheed-claws libaspell.so.15 => /usr/lib/libaspell.so.15 (0x4002a000) libaspell-common-0.50.2.so => /usr/lib/libaspell-common-0.50.2.so (0x400e4000) [...]
ok, after talking with the aspell author, i've come to some conclusions about how to fix this. libaspell-common is a library used internally by libaspell. applications should never need to link against this. furthermore, libaspell-common's interface may change at any time, so it's actually not safe for apps to link against it. they're currently linked against it because it's listed in the dependency_libs list of libaspell.la. i've spoken with the aspell author and he doesn't know of a good way to prevent this problem. so how do we prevent apps from linking against it? i've come up with 2 ways: 1. we can find every package that links against aspell and patch its libtool to set link_all_deplibs to "no". this will cause the package to link against libaspell.so, but none of its dependencies (libaspell-common.0.51.0.so). this is probably the "right" thing to do, but it's kind of a maintenance nightmare. 2. we can sed out the libaspell-common.la dependency from libaspell.la before installing it. this is probably the easiest solution. i don't think removing the libaspell-common.la from libaspell.la has any ramifications other than preventing packages linking against libaspell from also linking against libaspell-common. this change is made in only one place (the aspell ebuild) and can be removed if the aspell author solves the problem. this is my preferred solution. in any case, it'll cause a lot of things to need to be rebuilt. (eg: packages that link with libaspell; packages that link w/ packages that link with libaspell, etc..) seemant, do you know of any reason not to go with solution #2?
I think it would be the best course of action, to be honest. I am not entirely sure if it would require a lot of recompilation. It might, but might not. aspell is relatively new in the tree (this version) and not everything works it at the moment. It's something to investigate anyway.
*** Bug 9980 has been marked as a duplicate of this bug. ***
i just checked in aspell-0.50.2-r1. this should fix the bad dependency on aspell-common. you'll need to recompile everything that depends on aspell afterwards. closing
just adding some words so people finding this with apps other than sylpheed-claws might find this bug. a list of the current packages depending on aspell: abiword gnome-spell sylpheed-claws lyx gtkspell gtk+licq balsa
