| 1 |
> Hi, |
| 2 |
> how do you people handle dynamically linked breakage during world |
| 3 |
> upgrades? |
| 4 |
> I upgraded media-libs/pdflib from 5.0.2 to 6.0.0_p1 and since php was |
| 5 |
> dynamically linked against pdflib it broke, giving me the following |
| 6 |
> error: |
| 7 |
> php: error while loading shared libraries: libpdf.so.2: cannot open |
| 8 |
> shared object file: No such file or directory |
| 9 |
> |
| 10 |
> I can't figure out how to keep my servers up to date without breaking |
| 11 |
> them at points. If I would have manually recompiled pdflib (getting the |
| 12 |
> later version), php would still be broken until I was manually done with |
| 13 |
> the recompile of php. |
| 14 |
|
| 15 |
A few points: |
| 16 |
|
| 17 |
* Note that revdep-rebuild supports regular emerge options, the most |
| 18 |
useful of which is -p. This tool definitely does what you ask. |
| 19 |
|
| 20 |
* If you update a library (anything beginning with or containing lib is a |
| 21 |
bit of a giveaway), then you'd do well to know what it's reverse |
| 22 |
dependencies are (that is, and package you may have installed that depends |
| 23 |
on it). That way you can pre-empt any possible breakage. You might even |
| 24 |
get into the habit of simply rebuilding any dependent as a matter of |
| 25 |
course (which is no bad thing, IMO). There are a few tools to determine |
| 26 |
reverse dependencies available, but I find them inadequate when compared |
| 27 |
to "dep" which is available here: |
| 28 |
http://home.jesus.ox.ac.uk/~ecatmur/my-bin/dep. Use the -r parameter to |
| 29 |
list reverse dependencies for a named package. |
| 30 |
|
| 31 |
* There is no law that stipulates that you _must_ upgrade underlying |
| 32 |
dependencies (thus causing the occasional breakage in the first place). |
| 33 |
This is one argument I have against the "deep" option. There is no getting |
| 34 |
away from the fact that, unless mandatory recompilation of packages which |
| 35 |
link to and are sensitive to the condition of other packages becomes a |
| 36 |
feature of portage (or you are innately aware of what to look out for), |
| 37 |
then upgrading libs is sometimes going to temporarily break things here |
| 38 |
and there. Of course, revdep-rebuild solves the problem as a retrospective |
| 39 |
measure. Another approach is to stop using the -D option and let portage |
| 40 |
upgrade dependencies as and when a given packages indicates that it is |
| 41 |
_mandatory_ for them to be upgraded, not just because you can (if it ain't |
| 42 |
broke, don't fix it) .... |
| 43 |
|
| 44 |
If you want to santise things a bit in that respect, then I would suggest |
| 45 |
at least using dep's -w parameter which will remove things from world that |
| 46 |
shouldn't be there, based upon whether they are "top-level" packages (i.e. |
| 47 |
whether or not something else depends upon them). Bear in mind that the |
| 48 |
emerge -u parameter will traverse dependencies which are directly listed |
| 49 |
as such in a given ebuild; only -D will traverse each dependency's |
| 50 |
dependencies and so on ;) |
| 51 |
|
| 52 |
* Some packages support the "static" USE flag which would also prevent |
| 53 |
such breakage at the expense of larger binaries. Static binaries are a bit |
| 54 |
faster too. |
| 55 |
|
| 56 |
* Perhaps the best solution of all is to simply copy your environment to a |
| 57 |
"staging" box and perform updates there first (building binary packages |
| 58 |
with emerge --buildpkg). After a little testing, you can rapidly install |
| 59 |
your known-working packages on your production box (with emerge --usepkg). |
| 60 |
|
| 61 |
HTH, |
| 62 |
|
| 63 |
--Kerin Francis Millar |
Archives