Am Donnerstag, 19. Juni 2003 04:04 schrieb David Haller:
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:
Ich denk mal, wenn Du alles mit make install reingeschaufelt hättest, könntest Du heute eine SuSE 6.2 auch nicht mehr brauchen. Eine Distri über so lange Zeit zu nutzen, sicher und halbwegs aktuell zu halten, da gehört schon jede Menge Disziplin dazu, Respekt.
==== %prep %setup -q
cp configure configure.orig sed 's/\(FOO.*\)x\.y\.z/\1x.y.n/' < configure.orig > configure ====
Und danach die Zeilen: libtoolize --force aclocal autoconf reinstellen ;-) (Bitte nicht zu Hause nachmachen, wenn die Auswirkungen nicht bekannt sind)
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 ;)
Patch basteln ist auch nicht schwierig, configure Script kopieren z.B. als configure.orig, dann das Script abändern, mit 'diff -u configure.orig configure > configure.patch' nen Patch erstellen und ins Specfile einbauen.
Ack, aber meist ist das gar nicht mal so schwer, siehe den letzten Absatz.
Im Prinzip ist es nicht schwierig, aber die Folgen abzuschätzen, eventuell Changlogs der Lib rückverfolgen, abschätzen, ob entstehende Compilefehler aus diesen Änderungen herrühren und wie man damit umgeht usw.. Man mag es ja gar nicht glauben, aber nicht jedes Source-RPM compiliert auch wirklich problemlos auf jedem Rechner.
Ein wenig Verstaendnis von autoconf und rpm sind natuerlich noetig.
Kann nie schaden :-)
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...
Aber genau dieses "evtl." dürfte viele weniger erfahrene User vor Probleme stellen.
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.
Gerade die aktuellen Probleme mit QT 3.1.1 Update auf 3.1.2 sind ein gutes Beispiel, dass selbst kleine Versionsschritte böse Probleme bereiten können.
Nochmal, zu Verdeutlichung, diese Vorgehensweise ist natuerlich nicht DAU-kompatibel! Aber DAUs sollten IMO ja sowieso nicht selber
Genaugenommen kann es DAUs (also Mehrzahl) gar nicht geben ;-)
kompilieren, und fuer alle anderen kann's ein (lohnender) Anlass sein, sich mal ein klein wenig naeher mit autoconf/make usw. zu beschaeftigen ;))
Muß natürlich auch jeder wissen, wie viel Aufwand ein Paket einem an Arbeit oder Kosten (für ne neue Distri) wert ist. Bin z.B. gerade dabei mir ne SuSE 8.2 auf meinem PowerBook zusammenzucompilieren. Erstens, weil ich sonst auch nicht wüsste, wie ich die brachiale Rechenpower des PPC 750 alias G3 mit 266 MHz auslasten sollte, zweitens weil ich die neue glibc 2.3 haben will, drittens weil ich gcc 3.3 haben will (ohne immer auf 2.95 zurückschalten zu müssen, wenn C++ ins Spiel kommt) und viertens, weil die neue 1.4.1er Java-Version von IBM unter SuSE 7.3 nicht mehr läuft. Naja, ausserdem juckt mich die Herausforderung ;-) -- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ | http://packman.links2linux.de/ Manfred | http://www.knightsoft-net.de