| 1 |
Jan Kohnert schrieb: |
| 2 |
> Andreas Dau schrieb: |
| 3 |
>> Andreas Dau schrieb: |
| 4 |
>>> mein meckert: |
| 5 |
>>> incorrect version of Berkeley db: compiled against 4.7.25, linked |
| 6 |
>>> against 4.3.29 |
| 7 |
>> Ehm ... es muss doch eine Möglichkeit geben, das zu reparieren? |
| 8 |
> |
| 9 |
> man emerge *duck und weg* |
| 10 |
> |
| 11 |
> Also: |
| 12 |
> emerge -pP wird dir vermutlich etliches anzeigen, was weg kann. |
| 13 |
|
| 14 |
# emerge -pP |
| 15 |
|
| 16 |
Calculating dependencies... done! |
| 17 |
>>> No packages selected for removal by prune |
| 18 |
>>> To see reverse dependencies, use --verbose |
| 19 |
>>> To ignore dependencies, use --nodeps |
| 20 |
|
| 21 |
> emerge -p --depclean vermutlich auch |
| 22 |
|
| 23 |
# emerge --depclean -p |
| 24 |
|
| 25 |
* Depclean may break link level dependencies. Thus, it is |
| 26 |
* recommended to use a tool such as `revdep-rebuild` (from |
| 27 |
* app-portage/gentoolkit) in order to detect such breakage. |
| 28 |
* |
| 29 |
* Always study the list of packages to be cleaned for any obvious |
| 30 |
* mistakes. Packages that are part of the world set will always |
| 31 |
* be kept. They can be manually added to this set with |
| 32 |
* `emerge --noreplace <atom>`. Packages that are listed in |
| 33 |
* package.provided (see portage(5)) will be removed by |
| 34 |
* depclean, even if they are part of the world set. |
| 35 |
* |
| 36 |
* As a safety measure, depclean will not remove any packages |
| 37 |
* unless *all* required dependencies have been resolved. As a |
| 38 |
* consequence, it is often necessary to run `emerge --update |
| 39 |
* --newuse --deep world` prior to depclean. |
| 40 |
|
| 41 |
Calculating dependencies... done! |
| 42 |
>>> No packages selected for removal by depclean |
| 43 |
>>> To see reverse dependencies, use --verbose |
| 44 |
Packages installed: 365 |
| 45 |
Packages in world: 191 |
| 46 |
Packages in system: 50 |
| 47 |
Required packages: 365 |
| 48 |
Number to remove: 0 |
| 49 |
|
| 50 |
> Denk an python-updater, falls mit einem der vorigen Kommandos eine alte |
| 51 |
> Python-Version gelöscht werden soll (vor dem löschen derselben natürlich), |
| 52 |
|
| 53 |
# python-updater |
| 54 |
* Starting Python Updater from 2.4 to 2.6 : |
| 55 |
* No packages needs to be remerged. |
| 56 |
|
| 57 |
> sonst ist dann dein emerge kaputt. Schlimm kann es auch werden, wenn alte |
| 58 |
> openssl-Versionen weg sollen, falls noch wget/ftp dagegen gelinkt sind. Dann |
| 59 |
> sind nämlich die kaputt, und man kann nur hoffen, einen Browser zu finden der |
| 60 |
> noch funktioniert, um die Quellen zum erneuten emergen runterladen zu können. |
| 61 |
> |
| 62 |
> Danach dürfte dein System alles in allem ziemlich kaputt sein, da du leider |
| 63 |
> scheinbar ein fauler Updater bist (db-4.3 ist so uralt, das vermutlich |
| 64 |
> Archäologen damit ihren Spaß haben). |
| 65 |
|
| 66 |
Interessant. Ich mache auf dem System täglich(!) |
| 67 |
|
| 68 |
1. emerge --sync |
| 69 |
2. emerge --update --deep --newuse -pv world |
| 70 |
3. emerge --depclean |
| 71 |
4. revdep-rebuild (falls depclean was entfernt hat) |
| 72 |
5. emerge --prune |
| 73 |
6. revdep-rebuild (falls prune was entfernt hat) |
| 74 |
|
| 75 |
Sollte also db-4.3 zu alt sein, dann ist definitiv Portage kaputt. |
| 76 |
|
| 77 |
> revdep-rebuild ist dann dein Freund. |
| 78 |
|
| 79 |
revdep-rebuild -p |
| 80 |
* Configuring search environment for revdep-rebuild |
| 81 |
|
| 82 |
* Checking reverse dependencies |
| 83 |
* Packages containing binaries and libraries broken by a package update |
| 84 |
* will be emerged. |
| 85 |
|
| 86 |
* Collecting system binaries and libraries |
| 87 |
* Generated new 1_files.rr |
| 88 |
* Collecting complete LD_LIBRARY_PATH |
| 89 |
* Generated new 2_ldpath.rr |
| 90 |
* Checking dynamic linking consistency |
| 91 |
[ 100% ] |
| 92 |
|
| 93 |
* Dynamic linking on your system is consistent... All done. |
| 94 |
|
| 95 |
cu, |
| 96 |
Andreas |
Archives