Bug 18362 – library updating breaks dependant applications

• Product: Portage Development
• Status: RESOLVED DUPLICATE

[Description Ole Tange 2003-03-28 06:21:59 UTC]

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.

[Comment 1 Ole Tange 2003-03-28 06:56:27 UTC]

I just wrote a small perl script that may help detect the ldd-problems. The script is attached

[Comment 2 Ole Tange 2003-03-28 06:57:15 UTC]

Created attachment 9946 [details]
Perl script for ldd-checks

Run with: ldd-check.pl /usr/bin/*

[Comment 3 Alain Penders (RETIRED) 2003-03-28 19:29:08 UTC]

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.

[Comment 4 Petr Baudis 2005-02-09 11:14:02 UTC]

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.

[Comment 5 Tuan Van (RETIRED) 2005-05-09 10:10:14 UTC]

*** Bug 92023 has been marked as a duplicate of this bug. ***

[Comment 6 Jakub Moc (RETIRED) 2005-05-09 10:16:42 UTC]

Isn

[Comment 7 Jakub Moc (RETIRED) 2005-05-09 10:16:42 UTC]

Isn´t this a dupe of Bug 1991, anyway?

[Comment 8 Alec Warner (RETIRED) 2005-07-30 13:14:47 UTC]

ja(In reply to comment #6)
> Isn

[Comment 9 Alec Warner (RETIRED) 2005-07-30 13:14:47 UTC]

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 ***

[Comment 10 Jason Stubbs (RETIRED) 2005-07-30 21:14:53 UTC]

Keep it open. 

[Comment 11 Jason Stubbs (RETIRED) 2005-07-30 21:21:49 UTC]

Actually, ok. 

*** This bug has been marked as a duplicate of 1991 ***