Hallo, On Tue, 17 Jun 2003, Manfred Tremmel wrote:

Am Dienstag, 17. Juni 2003 12:00 schrieb Normen Dommaschk:

...

kann ich eigentlich ein rpm Paket aus SuSE 8.2 unter SuSE 7.3 installieren? Das 8.2 habe ich von einem FTP Server von SuSE.

Nein, bis 8.1 kann es klappen (wenn es sich um keine C++ Programme handelt, die benötigten Libs aktuell genug sind und die Pfade passen), mit 8.2 und der 2.3er glibc hasst Du keine Chance (Ausnahmen könnten das eine oder andere noarch.rpm sein). Du kannst versuchen das Source-RPM neu zu compilieren, kann klappen, muß aber nicht (Gründe, siehe oben bei 8.1er Paketen).

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. 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. 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. Kurzum: i.d.R. lohnt sich ein Versuch. Man muss natuerlich den jew. noetigen Aufwand abwaegen. -dnh -- Gibt es eigentlich in dag° "echten Blödsinn" ? Ich meine jetzt ausser meinem Bescheidenen Beiträgen dazu. [WoKo in dag°]

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

Hallo, On Thu, 19 Jun 2003, Manfred Tremmel wrote:

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.

Och, weder noch eigentlich. Sicher ist sie nicht (von der Software her), mein sendmail 8.9.3 und apache 1.3.6 haben definitiv bekannte Exploits -- allerdings ist es nicht moeglich, diese SW von aussen her anzusprechen und wenn ich online bin laeuft der Apache sowieso nicht. Und aktuell? Naja, ein paar Teile sind aktualisiert, vieles ist aber "original" ;)

...

==== %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)

Wozu? Es wird ja nicht das configure.in, sondern das configure script geaendert, nach einem autoconf waere die Aenderung wieder weg!

...

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.

Jup. Mach ich meistens auch, wenn mehrere Aenderungen noetig sind.

...

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.

ACK. Ich sag mir halt immer: "schau'n wer mal, ob's durchlaeuft" ;)

...

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.

Jo mei, was waere denn die Alternative? Gleich $lib zu aktualisieren? Und sich evtl. damit weitere Probleme einzuhandeln? Ne, also da mach ich lieber den o.g. Versuch und kann mir, wenn's klappt, einen Haufen Aerger ersparen.

...

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.

*hehe* Gutes Beispiel. Schreit jetzt $app nach qt 3.1.2 lohnt es sich IMO, zu versuchen, ob's nicht auch mit der 3.1.1 kompiliert und laeuft.

...

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 ;-)

Stimmt. Aber die werden ja gezuechtet, es gibt staendig einen neuen DAU, ergo hat man den aktuellen DAU und die nicht ganz aktuellen...

...

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.

ACK. [..]

Naja, ausserdem juckt mich die Herausforderung ;-)

*g* -dnh --

....Ommmmmm ....Ommmmmm .....Ommmmmm Pendel ----Pendel-----Pendel------ Mensch Axel: Sonst machst Du das doch mit der Glaskugel. Ist die schon wieder in der Spülmaschine? [Axel Lindlau und Volker Kroll in suse-linux]

Hallo, On Sat, 21 Jun 2003, Manfred Tremmel schrieb:

Am Freitag, 20. Juni 2003 16:43 schrieb David Haller:

...

On Thu, 19 Jun 2003, Manfred Tremmel wrote:

...

Und danach die Zeilen:

libtoolize --force aclocal autoconf

reinstellen ;-) (Bitte nicht zu Hause nachmachen, wenn die Auswirkungen nicht bekannt sind)

Wozu? Es wird ja nicht das configure.in, sondern das configure script geaendert, nach einem autoconf waere die Aenderung wieder weg!

Dreimal darfst Du raten, wieso ich den Warnhinweis und den Smily dazugestellt habe.

*ups* *ding* *eg* Nicht noetig ;) Danke der Nachhilfe, ich muss mal meinen Ironiedetektor neu justieren...

...

...

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.

Jup. Mach ich meistens auch, wenn mehrere Aenderungen noetig sind.

Ich mach das auch unterschiedlich. Wenn ich weiß, dass ich ne änderung über zig Versionen schleppen muß und jedes mal den patch ändern müsste wenn was angepasst wird, ist mir ne sed-Änderung oft lieber, die klappt auch nach ner Verschiebung oder anderen Änderungen noch. Andererseits schiest man sich auch leicht mal was kaputt, wenn man mit den zu ersetzenden Begriff auch falsche Werte umwandelt.

Jau. Versionsspezifisch ist's ja eigentlich immer... Und fuer ein ein, zwei einfache Aenderungen ist ein 'sed' im .spec oft einfacher als ein patch... Kommt halt immer darauf an, was man wo wie aendert...

...

ACK. Ich sag mir halt immer: "schau'n wer mal, ob's durchlaeuft" ;)

Versuch macht gluch, oder wie heisst das?

s/g/k/ ;)) Dann: "Genau!" :)

...

...

Aber genau dieses "evtl." dürfte viele weniger erfahrene User vor Probleme stellen.

Jo mei, was waere denn die Alternative? Gleich $lib zu aktualisieren?

Ne, passt schon, man sollte sich eben nur der Risiken bewusst sein und bei Problemen dann nicht unbedingt Bugreports an den Autor schicken.

ACK.

...

...

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.

*hehe* Gutes Beispiel. Schreit jetzt $app nach qt 3.1.2 lohnt es sich IMO, zu versuchen, ob's nicht auch mit der 3.1.1 kompiliert und laeuft.

Definitiv, hab von der 3.1.2 die Nase gestrichen voll.

*hehe* Bei solchen Kandidaten lohnt sich dann evtl. sogar etwas mehr Aufwand, als nur die als Minimal-Version geforderte im configure ein wenig runterzusetzen, da muss man halt schauen, wo's evtl. sonst noch hakt ;) Naja, ich hab solche Situation ja fast immer, ich bin ja froh, dass die glibc so abwaertskompatibel ist, ansonsten waere ich hier ja schon lange durchgedreht... ;) Aber zum Glueck sind die meisten Programmierer ja einfach nur zu faul (bzw. haben nicht die Moeglichkeit) $App/$lib auf $alter_Plattform zu testen, und somit kompiliert erstaunlich viel auch mit $alter_lib... Wobei, manche App faellt bei mir auch beim kompilieren wegen sowas durch den Filter... Echte "Killerapps" gibt's fuer mich kaum noch[1], und wenn eine App sich dann straeubt oder (auch mit den aktuellen, geforderten Libs) massenweise "einfach zu behebende" Warnungen und obendrein noch Fehler erzeugt, dann faellt die App bei mir eben einfach raus. Wie eine App kompiliert ist IMO ein guter Hinweis auf die beim Programmieren verwendete Sorgfalt, und wenn die nicht gegeben ist, dann will ich die App i.d.R auch nicht verwenden... Schwierig wird's bei Apps wie GIFT; die Code-Qualitaet ist IMO, aehem *zensiert* (mein patch war IIRC > 100 kb, gelaufen ist's dennoch nicht sauber), aber Alternativen gibt's wohl keine... *seufz* Und nein, meine "Quickhacks" melde ich nicht als Bugreports. Wenn ich Bugs melde, will ich "sauberen Code" beitragen, und das ist ein Aufwand, der mir meist zuviel ist... Hm. Bei WindowMaker muss ich mal wieder schauen, mein 0.80 laeuft nun bald 1 1/2 Jahre, meine Aenderungen scheinen also nix kaputtgemacht zu haben ;) Wenn's mir den WMaker mal wegen $FOO [2] mit nem SIGSEGV verrupft, hat sich der bisher immer berappelt und nach nem Neustart (via Dialog) lief's stabil weiter -- die laufenden Apps sind dabei jew. nicht betroffen... Und die Fehler liessen sich meist dann auf andere Apps bzw. X zurueckfuehren ;) Richtig "haengengeblieben" ist mir WMaker noch nie :) Wenn's mal was verrupft hat, dann eben nur den Windowmanager selbst, xterm+mutt und XEmacs liefen dabei also z.B. voellig unbetroffen weiter... Nur fehlten halt kurz die Windowmanager- Funktionen wie z.B. das aendern des Fensters... Nach dem Neustart von WMaker ging aber das auch wieder. Im Vergleich zu KDE, das mir schon haeufig gleich das komplette X gekillt hat, ist mir so ein Verhalten doch wesentlich lieber, wenn's _nur_ den Windowmanager einmal im Jahr mal verrupft ;) Laesst sich "schick" mit einem "kill -11 $PIDOF_WMAKER" nachvollziehen, der WMaker bietet einem dann freundlicherweise auch gleich an, einen anderen WM zu starten :) Ja, ich hab das grad mal getestet :)

...

...

Genaugenommen kann es DAUs (also Mehrzahl) gar nicht geben ;-)

Stimmt. Aber die werden ja gezuechtet, es gibt staendig einen neuen DAU, ergo hat man den aktuellen DAU und die nicht ganz aktuellen...

Meinste Du, es ist doch was dran, an den Klonebabys dieser UFO-Sekte?

Welche? UFO-Sekten gibt's ja massenweise... Ach, du meinst die, die gross verkuendet haben, sie haette einen Menschen geklont? *ROTFL* Hm. Ne. Dazu faellt mir eher folgende sig ein: ==== Der nächste DAU kommt bestimmt. Sie werden in den Kellern von AOL gezüchtet. [Dieter Bruegmann in dag°] ==== -dnh [1] und diese sind dann i.d.R. die anspruchlosesten, z.B. mutt ;) [2] i.d.R. eigentlich nicht durch WMaker bedingt/verursacht, IIRC waren's bisher irgendwelche Zusatztools... -- Space? Leertaste? Kleiner, weisser Biberdildo? -- Longbow2404517 in forum.counter-strike.de