Fragen zum Mischen von Debian testing/unstable

C

chlue

Grünschnabel
Ich versuche mich seid neusten an Debian Testing (bisher w2k/xp). Leider gibt es von einigen Dingen, die ich gerne nutzen möchte auch dort noch relativ alte Versionen. Zur Zeit möchte ich z.b. Blender 2.44 und Openoffice 2.2 nutzen. Ich habe zu diesen Zweck Unstable mit aufgenommen und durch Pinning und default dafür gesorgt, das standardmäßig Testing genommen wird.

Tja wenn Pakete keine Abhängigkeiten hätten wäre soweit alles ok. Leider wollen sowohl Openoffice als auch Blender unter anderen neuere Versionen von gcc und glibc. Da diese Sachen auch von vielen anderen Paketen benötigt werden, bin ich nun unsicher wie problematisch es ist diese zu updaten. Da glibc auch noch auf 'freeze' steht und regelmäßig geupdated wird befürchte ich, das diese Pakete nicht so bald automatisch nach testing wandern werden. Außerdem bin ich mir nicht im klaren wieviel weitere Arbeit und Probleme auf mich durch Updates und Wechsel von Unstable nach Testing der Pakete auf mich zukommen, wenn ich diese manuell aus Unstable installiere.

Nach meiner bisherigen Vorstellung von Abhängigkeiten kann man diese mit registrierten dll's unter windows vergleichen. Unter windows habe ich aber auch die Möglichkeit eine andere Version der dll einfach nur runterzuladen und in das gleiche Verzeichniss wie mein Programm zu packen. Ist ein vergleichbarer Weg unter Debian auch möglich? (ist leider immer schwer eine Suchmaschiene mit so unpräzisen Fragen zu füttern ?( )

In diesen Zusammenhang stellt sich mir noch die Frage ob selber runtergeladene/konvertiere/kompilierte *.deb's, auch von der Paketverwaltung verwaltet werden, oder ob ich dazu noch ein lokales Reprosity anlegen muss, dass ich jedesmal update, wenn ich eine weitere Datei ausprobieren möchte. Ich habe zwar eine Menge Dokumentation dazu finden können, wie man diese einzelnen Schritte erledigen kann, aber bisher bin ich noch nicht auf eine alltagstaugliche Gesammtstrategie gestoßen.
 
Das Problem ist, daß die Programme immer gegen bestimmte Versionen der Bibliotheken gelinkt sind. Stehen diese Versionen nicht mehr zur Verfügung, kann es passieren (und tut es auch in den meisten Fällen), daß die Programme nicht mehr laufen, weil sie ihre Shared-Objects nicht mehr finden. Daher rate ich vom Mischen eigentlich immer ab. Dann lieber den Source runterladen und ein eigenes deb bauen, das gegen die aktuell installierten Bibliotheken gelinkt ist.
 
Das Problem ist, daß die Programme immer gegen bestimmte Versionen der Bibliotheken gelinkt sind. Stehen diese Versionen nicht mehr zur Verfügung, kann es passieren (und tut es auch in den meisten Fällen), daß die Programme nicht mehr laufen, weil sie ihre Shared-Objects nicht mehr finden. Daher rate ich vom Mischen eigentlich immer ab. Dann lieber den Source runterladen und ein eigenes deb bauen, das gegen die aktuell installierten Bibliotheken gelinkt ist.
Das heißt, wenn ich mir den Sourcecode runterlade und selber compiliere, funktionieren viele Programme weiterhin mit älteren Abhängigkeiten?

So wie ich das bisher überblicke haben nahezu alle Abhängigkeiten entweder keine Angabe der Version oder ein >=xxx. Das heißt doch eigendlich, wenn ich alle notwendigen Abhängigkeiten mit update, erhöhe ich im wesentlichen die Gefahr das ich mir neue Bugs einfange, aber es sollte alles weiterlaufen. Oder ist die Annahme, das Abhängigkeiten abwärtskompatibel sind falsch?

Defcon, das ich mir unter openoffice.org die neusten Versionen herunterladen kann habe ich auch bereits gesehen, aber ich mache mir halt bisher Sorgen, das ein solches Update andere Sachen zerstört, bzw die Versionsverwaltung der apt aushebelt und unbrauchbar macht.
 
Die Annahme, daß Abhängigkeiten abwärtskompatibel sind, ist prinzipiell falsch. Nehmen wir z.B. die libstdc++.so.X. Ein Programm kann gegen die libstdc++.so.5 gelinkt sein, aber wenn nur die libstdc++.so.6 wird dieses nicht mehr funktionieren. In manchen solchen Situationen reicht zwar ein entsprechender Link aus um das zu beheben, aber gerade bei der libc macht das meist eher Probleme. Da hilft dann nur neu kompilieren um gegen die installierte Version zu linken.
 
Ok bisher war ich der Annahme, das Abhängigkeiten im wesentlichen auf features beruhen, die erst ab der Version enthalten sind. So wie ich das jetzt lese beruhen die Versionen der Abhängigkeiten also oft nur darauf welche Version der Ersteller der *.deb verwendet hat.

Gemäß dieses Forumbeitrags www.debianforum.de kann ich also versuchen mir mit folgenden Schritten ein 'passendes' *.deb erstellen:
apt-get update
apt-get build-dep <name des pakets>
apt-get -b source <name des pakets>
dpkg -i paketname.deb
Irgendwie glaube ich aber das das auf die gleichen Konflikte wie bisher beim zweiten Schritt hinauslaufen wird. Naja muss es wohl einfach mal probieren :bibber:
 
Du erstellst ja mit dieser Befehlsfolge ein Paket aus einem Source-Paket. Damit wird dieses ja gegen die aktuell installierten Bibliotheken gelinkt.
 

Ähnliche Themen

Keine grafische Oberfläche (Debian Installation)

suche 32-Bit Kompatibilitaetsbibliothek für Debian Wheezy amd64 -- Welches Paket?

Squid als RPCoHTTPS Proxy für Outlook Anywhere

Fragen zu gNewSense

sata unterstützung(für VIA VT8237S) unter debian etch 4.0 r3

Zurück
Oben