Hallo, On Thu, 19 Jun 2003, Manfred Tremmel wrote:
Am Mittwoch, 18. Juni 2003 02:44 schrieb David Haller:
Kleine Ergaenzung dazu: Sind evtl. benoetigte libs (!= glibc) aktuell genug, kompilieren die meisten (aber eben laengst nicht alle) Pakete selbst auf einer ex-SuSE 6.2/glibc-2.1.3 mehr oder weniger sauber durch.
Wieso auch nicht.
Ausserdem setzen viele Pakete unnoetig aktuelle libs voraus, z.B. das jew. aktuelle gtk(2), da die Entwickler nicht die Moeglichkeit haben, oder zu faul oder unwissend sind, auch mit einer aelteren lib zu testen.
Kostet aber ehrlich gesagt auch arg viel Zeit, alle Versionen von zig benötigten libs in allen möglichen Kombinationen durchzutesten. Da ist es wahrlich einfacher die eigene Basis als Minimalversion zu setzen.
ACK. Ich unterstreiche mal nachtraeglich den ersten Punkt ;) Was die Entwickler aber leisten koennen, ist ein Hinweis im INSTALL, im Stile von: "Ich hab das mit libfoo-x.y.z entwickelt, daher setze ich diese im configure voraus, aber libfoo-x.y.(z-n) sollte lt. Doku ebenfalls laufen, ueber konkrete Hinweise dazu wuerde ich mich freuen." Generell unterstelle ich den Entwicklern keine boese Absicht und die fehlende Moeglichkeit zum testen kann man leicht ausgleichen (s.u.).
Gerade bei Projekten mit schnellen Releasezyklen würden mehr lib-versionen testen, als programmieren. Wenn man wiederum nicht testet, geht die eingesparte Zeit durch Support wieder flöten.
ACK.
Wie "weit" man zurueckgehen kann haengt sehr von der lib ab. Geht es nur um micro-Versionen (also z.B. gefordert: gtk-1.2.9, vorhanden: gtk-1.2.3) geht es meist gut, dazu muss man aber i.d.R. das configure anpassen und das ist natuerlich abhaengig davon, wie die lib versioniert ist.
"Meist gut" kann aber auch bedeuten, dass der Autor genau wegen eines Bugfixes oder sonstiger änderung die Version vorgegeben hat.
Bei einem konkreten Anlass, sollte das dann allerdings wiederum dokumentiert werde ("verwende libfoo-x.y.z wegen ...").
Anpassungen des configure bzw. configure.in Skripts, dann nen Patch dafür erstellen, diesen ins spec-file aufnehmen (man will ja ein sauberes System behalten), das ist dann nicht mehr unbedingt für Einsteiger geeignet.
Naja, im Prinzip ist das einfach. Ich backe mir praktisch alles selbst als RPM (Basissystem: SuSE 6.2/glibc-2.1.3, mir bleibt also kaum was anderes uebrig ;), und so finden sich in recht vielen meiner .spec-Dateien Zeilen wie diese: ==== %prep %setup -q cp configure configure.orig sed 's/\(FOO.*\)x\.y\.z/\1x.y.n/' < configure.orig > configure ==== Kurz: es wird einfach die Angabe der Mindestversion von libfoo manipuliert, die Schwierigkeit ergibt sich nur daraus, diese Aenderung per patch oder per sed o.ae. aus dem .spec heraus vorzunehmen. Wuerde man das per Hand aendern waere's trivial -- fuer sed muss man eben ein eindeutiges Muster samt Ersetzung finden ;)
Kurzum: i.d.R. lohnt sich ein Versuch. Man muss natuerlich den jew. noetigen Aufwand abwaegen.
Und das nötige Hintergrundwissen und Ehrgeiz mitbringen.
Ack, aber meist ist das gar nicht mal so schwer, siehe den letzten Absatz. Ein wenig Verstaendnis von autoconf und rpm sind natuerlich noetig. Wichtig war mir eigentlich die Aussage: $PAKET will libfoo-1.2.12, ich habe hier 1.2.11 (oder .9 oder so)... Und in diesen Faellen ist eine Anpassung eben wie oben angedeutet meist doch eher einfach und in 1min (grep plus ein test-sed-lauf plus diff) erledigt. Im Vergleich zum aktualisieren von libfoo sehr oft durchaus lohnend. Falls Fehlermeldungen auftauchen, muss man halt evtl. dann doch aktualisieren... Was ich hier schon mit (lt. configure) gegen "viel zu alte" libs kompiliert habe... ;)) IIRC waren da auch _deutlich_ groessere Unterschiede dabei, als bisher angesprochen -- ich weiss eben auf was ich mich einlasse, und habe keine Angst vor Fehlermeldungen beim kompilieren oder linken, da schau ich dann eben wo's haengt und entscheide dann, ob ich versuche zu patchen, einfach die lib aktualisiere oder das ganze sein lasse ;) Wo also die Grenze bzgl. Aufwand zu ziehen ist, haengt immer von dem ab, der versucht zu kompilieren... Bei, sagen wir GTK1/GTK2 oder QT1/QT2/QT3 kann man es z.B. wohl vergessen, der Aufwand waere zu gross, in anderen Faellen stoert eben nur eine bloede zu hohe Version im configure... Diese testhalber mal zu manipulieren hat sich fuer mich bisher fast immer gelohnt. Nochmal, zu Verdeutlichung, diese Vorgehensweise ist natuerlich nicht DAU-kompatibel! Aber DAUs sollten IMO ja sowieso nicht selber kompilieren, und fuer alle anderen kann's ein (lohnender) Anlass sein, sich mal ein klein wenig naeher mit autoconf/make usw. zu beschaeftigen ;)) -dnh --
Now, if I could just figure out how to get hold of egg yolks, without superfluous egg whites... -- S. Lamble Why not leave them with the whites? Properly cared-for, in time they will turn into a tasty chicken! -- Tanuki