Bugzilla Bug 9996

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