Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 18362 - library updating breaks dependant applications
Summary: library updating breaks dependant applications
Status: RESOLVED DUPLICATE of bug 1991
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Unclassified (show other bugs)
Hardware: All Linux
: High minor (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
: 92023 (view as bug list)
Depends on:
Blocks:
 
Reported: 2003-03-28 06:21 UTC by Ole Tange
Modified: 2011-10-30 22:21 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Perl script for ldd-checks (ldd-check.pl,636 bytes, text/plain)
2003-03-28 06:57 UTC, Ole Tange
Details

Note You need to log in before you can comment on or make changes to this bug.
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) gentoo-dev 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) gentoo-dev 2005-05-09 10:10:14 UTC
*** Bug 92023 has been marked as a duplicate of this bug. ***
Comment 6 Jakub Moc (RETIRED) gentoo-dev 2005-05-09 10:16:42 UTC
Isn
Comment 7 Jakub Moc (RETIRED) gentoo-dev 2005-05-09 10:16:42 UTC
Isn´t this a dupe of Bug 1991, anyway?
Comment 8 Alec Warner archtester Gentoo Infrastructure gentoo-dev Security 2005-07-30 13:14:47 UTC
ja(In reply to comment #6)
> Isn
Comment 9 Alec Warner archtester Gentoo Infrastructure gentoo-dev Security 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) gentoo-dev 2005-07-30 21:14:53 UTC
Keep it open. 
Comment 11 Jason Stubbs (RETIRED) gentoo-dev 2005-07-30 21:21:49 UTC
Actually, ok. 

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