I upgraded some libraries after which some applications stopped working. In my example I upgraded gal and AbiWord stopped working. AbiWord was dependant on libgal.so.20, which was removed. libgal.so.21 was created, but AbiWord was not aware of this. A recompile of AbiWord solved this issue. But the cause of the problem still remains: How can we make sure that upgrading a package (be it application or library) does not break other packages already installed? The easy (and correct) answer is of course that this is impossible to catch every break. But we actually _can_ prevent some of the breaks from happening. I will here sketch a solution to some of the problems: * Upgrading a library When installing a dynamically linked file it is easy to run 'ldd' on the file. This will output (most of) the libraries that this file depends on. If the file is not dynamically linked then 'ldd' will just output an error message. 'ldd -d -r' will both check that the library exists and that the used objects (functions and data) are available in the library. If the file is dynamically linked and 'ldd -d -r' fails then something is wrong. Often this error can be solved by re-compiling the file in question. So when installing a file the following should be done: - if dynamically linked check that the libraries are OK (using ldd -d -r) and register which libraries the file depends on. When removing a file the following should be done: - See if some other file is dependant on this file (e.g. this file may be a library). If so then check that 'ldd -d -r' works for each dependant file after removing this file. If some of the dependant files do not work the user should be noted, so the user can decide whether the user wants to re-install the old version or re-compile the dependant files (This could be an install option). * Upgrading an application It is much harder to automate the detection of dependancy between applications. The dependencies will probably have to be made by humans.
I just wrote a small perl script that may help detect the ldd-problems. The script is attached
Created attachment 9946 [details] Perl script for ldd-checks Run with: ldd-check.pl /usr/bin/*
Sorry to say this, but the problem here isn't how to fix this... we're all aware of both the problem and how to fix it. The real problem is time, eventually reverse dependancy checking will be added to portage. Until that day, this problem will remain a problem.
Now we have revdep-rebuild, which could be taken advantage of when doing this. The need for this bug getting fixed demonstrates nicely on bug 78313. We should somehow detect that this library is going away, then do the reverse dependency search and rebuild all the binaries using it, then finally remove the library. The problem is that running revdep-rebuild takes rather long time, so if some equivalent checking would be done at each emerge, it could slow things down considerably.
*** Bug 92023 has been marked as a duplicate of this bug. ***
Isn
Isn´t this a dupe of Bug 1991, anyway?
ja(In reply to comment #6) > Isn
ja(In reply to comment #6) > Isn´t this a dupe of Bug 1991, anyway? It is now ;) *** This bug has been marked as a duplicate of 1991 ***
Keep it open.
Actually, ok. *** This bug has been marked as a duplicate of 1991 ***