Hallo Rene, On Don, 08 Feb 2001, Rene Matthaei wrote:
Am Mittwoch, 7. Februar 2001 18:10 schrieb David Haller:
Und du hast evtl. genug Erfahrungen gesammelt, dass es sich lohnt noch mal sauber neu zu installieren. Die erste(n) Installation(en) verkonfiguriert man sich gerne so, dass es leichter ist neu zu installieren ;) Könnte man sagen - obwohl es alles gar nicht so schlimm gewesen zu sein scheint... ^^^^^^^ eben sehr wahrscheinlich nur das. Oberflaechlich tut alles wieder, aber im Hintergrund lauern irgendwelche ominoesen Fehler... (geht mir ja auch so).
Ich zumindest habe keine Lust mir meine vermurksten Libs von Hand wieder hinzufrickeln (das rpm an dem ich z.Z. backe enthaelt immerhin schlappe 4358 Dateien... Und bei Suse's 2.1.3 immer noch mindestens 3176, da weniger Doku ;).
Aber ich warte auch auf die 7.1. Schade, dass ich kein DVD habe :-)
Gute Idee. Wenn du meinst, dass sich die 7.1 lohnt. Ich habe und bleibe bei meiner 6.2 ;)
Von allem aus Serie a, eben insbesondere der (g)libc solltest du die Finger lassen, bis du genau weisst was du tust.
Und generell solltest du auch nur SuSE-RPMs installieren, bis du weisst wie du evtl. auftretende Probleme loesen kannst.
Na Du bist gut - es gibt so viele tolle Softwareprodukte im Internet, und die laufen eben nicht alle mit den "Bordmitteln", denke ich (wie zum Beispiel Mozilla, auch wenn man den nicht vielleicht unbedingt braucht - trotzdem!)
Dann mach dich am besten ein wenig mit RPM und make vertraut. Dann kannst du kontrollieren, was wo hininstalliert wird und ggfs. Gegenmassnahmen vorher erledigen. Gutes Beispiel fuer eine kaputte Installation ist der Realplayer. Der krallt sich alle mime-Typen mit denen er umgehen kann. Aber ich will nunmal nicht wavs mit dem abspielen sondern mit play... Wie gesagt rpm --test ist bei rpms dein Freund. Auch eine gute Idee ist, vor dem Installieren mal mit dem mc ins rpm zu schauen, was denn da so alles drin ist. Und nicht die Scripts in INFO/SCRIPTS vergessen ;)
Ich bekomme hier z.B. nach einer aehnlichen Sache staendig (nicht nur bei rpm): $ rpm -qf /lib/libc-2.2.so rpm: ../iconv/skeleton.c:297: gconv: Assertion `outbufstart == ((void *)0)' failed. Abgebrochen
*LOL* Das sind die Ueberreste einer ausversehen druebergebuegelten glibc-2.2 -- trotz rpm -i --force --nodeps glibc-2.1.3-foobar.rpm von SuSE ;) Naja, ich weiss inzwischen wie ich das loesen koennte, aber ich bastel mir grad eh ein neues System :) In kürzesten Worten - woran lag es?
Ein kaputtes spec. Das hat nicht nach /tmp/irgendwo installiert um das binary-rpm daraus zu basteln, sondern gleich nach /lib usw. Ich weiss jetzt aber nicht mehr, ob ich da einen Fehler gemacht hatte, oder das .spec das ich als Vorlage verwendete...
Außerdem denke ich, dass Du vielleicht (?) - wie ich - die shlibs aus der Serie a hättest drüberinstallieren sollen.
Die auch. Klar.
(Eine höchstwahrscheinlich SAUblöde Frage - WAS bedeutet eigentlich immer diese ver!/$/! "foo" oder "foobar" etc.?! Ich habe nur eine Ahnung...
In etwa das gleiche wie "bla" "blubb". Das sind sog. "Metasyntaktische Variablen", also einfach Platzhalter fuer Werte, deren spezielle Werte im Zusammenhang unwichtig sind. Im Jargon-file[1] sind noch einige mehr aufgelistet, gern wird die Sequenz: "foo, bar, baz, quux, quuux .." genommen. Ach ja, "foobar" ist nicht mit "fubar" zu velwechsern ;)
Mein Problem mit dem Problemlösen und Selbstkompilieren von glibc ist: Nach make install - wie krieg ich das Zeug wieder vom System runter?
s.o. IMHO so gut wie garnicht, denn ein make uninstall koennte bei der glibc fatal sein. Ich wuerde dir eigentlich empfehlen, neu zu installieren. Ich meinte auch eher, ob Du vielleicht ein paar Faustregeln parat hast, wie ich (vielleicht in den Makefiles) relativ zügig und gut feststellen kann, wo das Zeug hingekommen ist
Dazu kannst du erstens im den meisten Makefile eine Zuweisung 'prefix = ' und/oder 'DESTDIR=' suchen, die das "Startverzeichnis" festlegen unterhalb dessen dann die Dateien installiert werden. Zum testen kann man diese Variable fuer ein 'make install' auch "ueberschreiben" in dem man 'make -e prefix=/tmp/foobar/ install' aufruft. Das -e zwingt make, die im Makefile gesetzten Variablen durch die in der Umgebung (und wie oben uebergebenen) zu ersetzen. Ausserdem solltest du dir jeweils die "targets" mit install im Namen anschauen, insbesondere natuerlich den target 'install:', der aber oft nur auf weitere target verweist, oft in der Form 'install: install-recursive' oder aehnlich. Siehe dazu info make und versuche mindestens die Rubrik "Introduction" zu verstehen...
und *vielmehr*, ob es Backups gibt etc.
Das wird leider selten gemacht (auch bei rpms), insofern ist es am besten du schaust dir rpm --test und/oder das Makefile an und machst vor der Installation selber ein Backup. Wenn du Fragen zu speziellen Paketen hast dann frage, oder noch besser, schau ob's z.B. bei packman rpm's fuer Suse gibt.
(*hrpmf*!!!)... Zum Glueck hatte ich ne root-Konsole offen, in der ich dann die Links in /lib wieder auf die 2.1er Versionen umbiegen konnte... Bei mir ging auch kurz kaum was - aber immerhin (!) rpm lief noch, und die Tab-Taste verschaffte mir auch Einblick in die Verzeichnisse (was mit ls nicht mehr ging :-).
Genau. Denn ls war natuerlich gegen die 2.1.x gelinkt ;(
Also Vorsicht. Wenn, dann nimm lieber fertige Binary-RPMs (fuer SuSE!). Aber das geht doch nicht immer - wer von Euch hat denn DIESE Geduld schon mal je gehabt :-)?
Wieso Geduld? Selber backen! oder auf packman[2] schauen. Ggfs. lohnt sich eine Frage hier ob jemand anderes Interesse hat und ein RPM baeckt. Oder du suchst bei freshmeat / rpmfind.net nach rpm _fuer Suse_ (s.u. warum).
(Wie sagt man eigentlich rpm, dass man gerne ein backup hätte?)
Immer erstmal testen. rpm <wasauchimmer> --test
Ich meinte, so wie bei YaST - oder kann nur YaST, was YaST kann?
Aeh, die Frage versteh ich nicht ganz ;) Yast verwendet auch nur rpm. Und eben AFAIK ohne --test. Yast ruft dann halt noch SuSE-Config auf. Du kannst z.B. per Hand ein rpm --test machen und (wenn's ok aussieht) das rpm dann immernoch mit Yast installieren.
Und von RPMs fuer RedHat (und Abkoemmlinge wie Mandrake etc.) lass liber die Finger, die haben ein voellig anderes Namensschema (SuSE's Schuld) und oft auch andere Verzeichnisstrukturen... Davon habe ich schon vor langer Zeit gehört, und das soll auch der Grund gewesen sein, dass einige Leute von SuSE abgesprungen sind.
Der Grund fuer die "Inkompatibilitaeten" sind weniger die Datei- strukturen, als die Paketnamen. Beispiel: SuSE: gnlibs, Andere: gnome-libs. Wenn nun ein Paket nach gnome-libs schreit, dann wird sich das auf nem SuSE-Linux eben nicht finden...
WIE kann es aber dann gleichzeitig sein, dass ausgerechnet SuSE diesen FileSystem-Standard-Test am besten (!) absolviert hat (wahrscheinlich durch eine Menge Links ;-)
Nichtmal. s.o.
PS: Und RedHat-Pakete sind doch immer noch am besten, wenn es keine von SuSE gibt, oder?
Schwierig zu beantworten. Kommt auf die Pfade und Abhaengigkeiten des speziellen RPMs an.
Oder wie erstellt man sich am "Einfachsten" RPMs, wenn man nur Tarballs hat?!
Am einfachsten ist wohl das Suse-spec der Vorversion anzupassen. Dann ein RH-spec. Dann selber basteln. Besorg dir, wenn du Interesse hast, das Maximum-RPM (book) von http://www.rpm.org. Das ist die beste und einzige mir bekannte wirklich ausfuehrliche Doku zu rpm (und den spec-Dateien). Und selbst da bleibt die ein oder andere Frage unbeantwortet. [1] http://www.tuxedo.org/~esr/jargon/html/entry/metasyntactic-variable.html [2] URL weiss ich grad nicht, IIRC aber von www.links2linux.de verlinkt. CU David -- Merke: Wenn eine Frage nicht mit 42 beantwortet werden kann, ist die Frage ungültig. [Christopher Splinter in dag°]