Aloa, wenn ich aber alles mit *.rpm installiere, dann kann ich aber php nicht mit pgsql konfigurieren/kompilieren. Zuerst hab ich postgresql über yast installiert, dann hab ich dies gemacht: 1. gunzip apache_1.3.x.tar.gz 2. tar xvf apache_1.3.x.tar 3. gunzip php-x.x.x.tar.gz 4. tar xvf php-x.x.x.tar 5. cd apache_1.3.x 6. ./configure --prefix=/www 7. cd ../php-x.x.x 8. ./configure --with-pgsql=/var/lib/pgsql/data --with-apache=../apache_1.3.x --enable-ftp und dann bekomm ich eine Fehlermeldung: error: Cannot find libpq-fe.h. Please specify correct PostgreSQL installation path. Ich glaub aber dass ich PostgreSQL händisch installieren muss, weil es sonst nicht funkt, oder? lg Charlie ----- Original Message ----- From: Holger Macht To: suse-linux@suse.com Sent: Thursday, January 29, 2004 4:34 PM Subject: Re: Installation On Thursday 29 January 2004 16:27, Karl Schaubmair wrote:

Hi,

will auf Suse 8.2 Apache, PostgreSQL, PHP und ColdFusion MX installieren.

Ich hab aber in einem schlauen Buch gelesen, dass man immer die *.rpm installieren sollte, aber ich muss sie ja vorher noch compilieren.

Was ist da am besten?

Natürlich ist es sehr vorteilhaft, wenn man die rpm Datei installiert, da dann die installiereten Dateien in einer Datenbank festgehalten werden und mögliche Paketkonflikte aufgelöst bzw. davor gewarnt wird. Falls Du die Pakete mit ./configure make make install einspielst, weiß am Ende keiner mehr wo jetzt überall Dateien liegen. EIne für mich gute Lösung ist einfach ein ./configure und make zu machen (also zu Kompilieren) und anschließend mit checkinstall eine RPM-Datei erstellen zu lassen. Gruß, Holger -- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-linux-unsubscribe@suse.com Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-linux-help@suse.com

Hallo, Am Fri, 30 Jan 2004, Karl Schaubmair schrieb: [.. TOFU (grausamste Variante) ..] Stell das TOFU ab. Zumindest ich werde deine Fragen nicht lesen, bis das besser wird. -dnh -- There is a theory which states that if ever anyone discovers exactly what the Universe is for and why it it here, it will instantly disappear and be replaced by something even more bizarre and inexplicable. -- There is another theory which states that this has already happend.

Holger Macht wrote:

Falls Du die Pakete mit ./configure make make install einspielst, weiß am Ende keiner mehr wo jetzt überall Dateien liegen. EIne für mich gute Lösung ist

Im makefile ist festgehalten wo was hinkommt. Es soll auch sowas wie make uninstall geben ;-) cu Carsten

Thomas Hertweck wrote:

Carsten Becher wrote:

...

Holger Macht wrote:

...

Falls Du die Pakete mit ./configure make make install einspielst, weiß am Ende keiner mehr wo jetzt überall Dateien liegen.

Im makefile ist festgehalten wo was hinkommt. Es soll auch sowas wie make uninstall geben ;-)

1. Wenn Du eine Software deinstallieren willst, suchst Du Dir tatsaechlich anhand des Makefiles die Dateien zusammen, die Du wieder von Hand entfernen musst? Das kann ich kaum glauben, umstaendlicher geht es ja nicht. Mache das mal bei einer Software, die mehrere hundert Dateien im System an unterschiedlichen Orten installiert. Viel Spass :-)

Danke :-) Allerdings gibt es nicht nur die Monsterpakete a la OO oder KDE, sondern auch (zumindest auf meinen Systemen) einiges an kleineren Paketen, die teilweise auch nicht bei der SuSe dabei sind und im Inet "nur" als source verfügbar sind. Da dann extra ein rpm draus bauen...nö. Und bei 10 oder 20 Dateien ist das imo noch überschaubar :-)

2. Ein "make uninstall" (das auch wirklich das tut, was es soll) trifft man eher selten in Makefiles an. Zudem wuerde ein derartiges Vorgehen voraussetzen, dass Du die konfigurierten Quellen auf der Festplatte aufbewahrst - ansonsten kann das "make uninstall" nicht funktionieren.

Naja... bei heute gängigen Plattenkapazitäten im 200+ GB-Bereich sind mir die paar MB an source ehrlich gesagt egal ;-) Schlechte Erfahrungen habe ich auch noch nicht gemacht.

3. Ohne den Bau eines RPMs wird Deine RPM-Datenbank inkonsistent und es koennen keine Abhaengigkeiten mehr ueberprueft werden bzw. Du musst diese Pruefung mit den Optionen "--nodeps --force" umgehen. Das ist nicht gerade das, was man wirklich moechte.

Eh, sorry? Meine rpm-Datenbank wird nicht inkonsistent weil ich software als source installiere. Die wird erst dann inkonsistent wenn ich Software die als rpm installiert wurde händisch entferne. Richtig ist, das wenn ich ein Programmpaket das von einem anderen Programmpaket vorrausgesetzt wird (das als rpm installiert wird) als source installiere das die Abhängigkeiten den Bach runtergehen und evtl. das Programmpaket ein zweites Mal angefordert wird. Das ist allerdings keine Inkonsitenz der rpm- Datenbank sondern eine "Unfähigkeit" des Paket Managers.

4. Durch den Bau eines RPMs haelt man die RPM-Datenbank konsistent, kann Abhaengigkeitsueberpruefungen durchfuehren und viele sonstige Features von RPM nutzen, kann seine Software komplett ohne Probleme deinstallieren, braucht nur das Source-RPM aufheben (evtl. auf CD, denn man kann ja das RPM auch ohne Anwesenheit der Quellen, im Gegensatz zu oben, wieder entfernen), u.v.m.

CU, Th.

Durch den Gebrauch von sourcepaketen ist man nicht auf Gnade des Packagers angewiesen ( sobald du einen 486 noch im Einsatz hast und alle "modernen" rpm für 586+ compiliert wird source für mich wieder hochinteressant. Zusätzlich bei Performance-kritischen Anwendungen die für Intel compiliert sind rede ich mir zumindest ein das ein compilieren für meinen K7 nicht schlecht ist). Wenn eine Software, die nur als source verfügbar ist, per bsw. checkinstall zum rpm gemacht wird, wird dann nicht auch das makefile verwendet (resp. der Installationsverlauf beobachtet). Dann ist zumindest die Deinstallation auch nicht zuverlässiger als wenn direkt über make uninstall geht imo. Das was für mich für rpm spricht ist die Verwaltung von Abhängigkeiten. Der Rest ist entweder Bonbon (man kann die source löschen) oder auch nicht besser als der traditionelle Weg (make uninstall). cu Carsten

Thomas Hertweck wrote:

Carsten Becher wrote:

...

Da dann extra ein rpm draus bauen...nö. Und bei 10 oder 20 Dateien ist das imo noch überschaubar :-)

Ich habe sehr viele eigene Software hier compiliert und installiert, und ich finde das selbst bei 10 oder 20 Dateien nicht uebersichtlich, wenn kein RPM gebaut wird - hier kann ich Deiner

Nunja, wenn wir bei "ich finde" weitermachen könnte ich jetzt sagen "finde ich wohl" :-) Bringt aber nicht viel. Ich habe jedenfalls keine Probleme bei 10-20 Dateien die Übersicht zu behalten. Mag mit der Gewohnheit zusammenhängen.

Logik nicht folgen. Ebenso tauchen Deine Installationen nicht in der RPM-Datenbank auf.

Logisch.

...

[...] Schlechte Erfahrungen habe ich auch noch nicht gemacht.

Dann hast Du garantiert auch noch nicht besonders viel installiert.

Danke für die Blumen :-) Was soll man halt schon so in den letzten 8 Jahren installiert haben ;-). SuSE habe ich erst seit ca. 3 Jahren. Genausogut könnte ich jetzt behaupten das du wohl nicht viel Routine hast, wenn du dich ohne Paketmanager so schnell verirrst ;-)

Mache mal fuer ein einziges SuSE-RPM, von dem andere Pakete uphaengen, ein Upgrade - dann wirst Du sehr schnell merken, wie weit Du ohne Benutzung von RPM (also mit "make install" kommst) :-) Und

Per Logik mache ich für ein rpm-installiertes Programm kein Update per make. Und umgekehrt. rpm installiert-> rpm Update. make installiert -> make update.

das gilt auch fuer ganz ganz kleine Pakete, die vielleicht nur zwei Dateien installieren - hat so gesehen nichts mit der Groesse des Paketes zu tun.

Das Dateienanzahlargument von mir betraf eine evtl. Deinstallation. Keinen Gruselmix (da gebe ich dir latürnich recht) aus rpm/ make Updates innerhalb eines Programmes.

...

...

3. Ohne den Bau eines RPMs wird Deine RPM-Datenbank inkonsistent und es koennen keine Abhaengigkeiten mehr ueberprueft werden bzw. Du musst diese Pruefung mit den Optionen "--nodeps --force" umgehen. Das ist nicht gerade das, was man wirklich moechte.

Eh, sorry? Meine rpm-Datenbank wird nicht inkonsistent weil ich software als source installiere. Die wird erst dann inkonsistent wenn ich Software die als rpm installiert wurde händisch entferne.

Deine RPM-Datenbank wird schneller inkonsitent als Du glauben magst. Wenn Du z.B. Software installierst ueber "make install", im Anschluss daran eine Software per RPM, die von ersterem abhaengt...

Dafür liest man ja vorher (!) die diversen Hilfetexte , und überlegt sich was im jeweiligen System wovon abhängt.

Wenn Du ein SuSE-RPM aus dem System nimmst, um die Software per "make install" auf eine neue Version upzugraden... Usw. Ich halte

s.o.

wenig von Deinem Vorgehen. Deine Einstellung laesst vermuten, dass ich Dich nicht zur Nutzung von RPM ueberzeugen kann, auch wenn es diverse Vorteile bietet (und eigentlich keine Nachteile) - wenn es fuer Dich, so wie es ist, OK ist, schoen; ich halte Dein Vorgehen aber eher fuer potenziell gefaehrlich.

Funktioniert seit '95 recht gut.

...

Richtig ist, das wenn ich ein Programmpaket das von einem anderen Programmpaket vorrausgesetzt wird (das als rpm installiert wird) als source installiere das die Abhängigkeiten den Bach runtergehen und evtl. das Programmpaket ein zweites Mal angefordert wird. Das ist allerdings keine Inkonsitenz der rpm- Datenbank sondern eine "Unfähigkeit" des Paket Managers.

Das ist nicht die Unfaehigkeit des Paket-Managers, denn der kann natuerlich nur funktionieren, wenn man ihn auch beruecksichtigt beim Installieren von Software. Nutzt Du "make install", dann uebergehst Du RPM, somit ist es eher die "Unfaehigkeit" (um bei diesem Wort zu bleiben, soll nicht beleidigend sein) des Admins, der installiert, nicht die von RPM. Bei jeder Distribution sollte man Software i.d.R. in dem Paketformat installieren, das zur jeweiligen Distribution gehoert. Das beschraenkt sich nicht alleine auf SuSE und RPM. Wenn

Womit man sich natürlich schön brav auf die Software beschränken muss die der jew. Distributor beilegt. Und hoffen das man keine garstige Software aus dem Internet oder woher auch immer benötigt die unhöflicherweise nicht als rpm vorliegt. Und immer hoffen das die rpm-datenbank nicht abrutscht, dann haben zwar die Windows-Leute wieder was zum lachen (kaputte Registry gibts dann auch mit Linux... so ähnlich jedenfalls) aber so richtig lustig fände ich das dann nicht. Tut eigentlich rpm -rebuilddb von Grund auf , also wenn die db weg ist?

Du in Deinem Auto den Airbag ausschaltest, kannst Du hinterher bei einem Unfall auch nicht kommen und sagen, der Airbag/Hersteller bzw. das System war "unfaehig"...

Nunja.... wenn ich den Airbag ausschalte ist das Sicherheitssystem ganz aus , wenn ich make verwende , verwende ich ein anderes System und nicht garkeines. Im übrigen- wir können uns jetzt natürlich in epischer Breite für/gegen Paketmanager unterhalten, allerdings war die ursprüngliche Frage : "Falls Du die Pakete mit ./configure make make install einspielst, weiß am Ende keiner mehr wo jetzt überall Dateien liegen. EIne für mich gute Lösung ist" was ja wohl schlicht und einfach falsch ist. Es steht im makefile, ansonsten könnte die soft nicht installiert werden. Das es evtl. einen "Augenblick" dauert das makefile für cinelerra durchzuschauen sei hier unbestritten ;-) Das ein make uninstall nicht funktioniert bedeutet das der jew. Programmierer ein Hoppala gemacht hat, nicht unbedingt das die ganze Methode falsch ist. cu Carsten

Kleines comment, Jetzt gibts aber auch: http://www.tu-chemnitz.de/linux/Dokumentation/RPM/index.html Johan Fredag 30 januar 2004 16:05 skrev Thomas Hertweck:

Carsten Becher wrote:

...

Thomas Hertweck wrote:

...

[...] Das ist nicht die Unfaehigkeit des Paket-Managers, denn der kann natuerlich nur funktionieren, wenn man ihn auch beruecksichtigt beim Installieren von Software. Nutzt Du "make install", dann uebergehst Du RPM, somit ist es eher die "Unfaehigkeit" (um bei diesem Wort zu bleiben, soll nicht beleidigend sein) des Admins, der installiert, nicht die von RPM. Bei jeder Distribution sollte man Software i.d.R. in dem Paketformat installieren, das zur jeweiligen Distribution gehoert. Das beschraenkt sich nicht alleine auf SuSE und RPM.

Womit man sich natürlich schön brav auf die Software beschränken muss die der jew. Distributor beilegt.

Wieso denn? Hast Du das eigentlich ueberhaupt verstanden, um was es geht? Nochmal: Wenn es kein fertiges RPM gibt, dann baut man sich selbst eines und installiert dann dieses gebaute RPM-Paket statt ein "make install" durchzufuehren. Gruende dafuer wurden ja reichlich genannt, z.B. Pflege der RPM-Datenbank, Pflege der Abhaengigkeiten im System und leichtere Deinstallationen. Wo ist man da auf den jeweiligen Distributor angewiesen? Gar nicht, genau - es liegt alles in den eigenen Haenden. Wenn Du mal objektiv schauen wuerdest, muesstet Du IMHO erkennen, dass Deine Vorgehensweise einige erhebliche Nachteile besitzt. Aber ich sehe nun ehrlich gesagt wenig Sinn darin, Dir etwas zu erklaeren, wenn Du es gar nicht verstehen _willst_. Deswegen hoere ich jetzt auch besser auf...

CU, Th.

Ooooopppppsss ....... hier kommt es korrekt http://asic-linux.com.mx/~izto/checkinstall/ Viel spaß Johan Lørdag 31 januar 2004 03:08 skrev yep@osterbo-net.dk:

Kleines comment,

Jetzt gibts aber auch:

http://www.tu-chemnitz.de/linux/Dokumentation/RPM/index.html

Johan

Fredag 30 januar 2004 16:05 skrev Thomas Hertweck:

...

Carsten Becher wrote:

...

Thomas Hertweck wrote:

...

[...] Das ist nicht die Unfaehigkeit des Paket-Managers, denn der kann natuerlich nur funktionieren, wenn man ihn auch beruecksichtigt beim Installieren von Software. Nutzt Du "make install", dann uebergehst Du RPM, somit ist es eher die "Unfaehigkeit" (um bei diesem Wort zu bleiben, soll nicht beleidigend sein) des Admins, der installiert, nicht die von RPM. Bei jeder Distribution sollte man Software i.d.R. in dem Paketformat installieren, das zur jeweiligen Distribution gehoert. Das beschraenkt sich nicht alleine auf SuSE und RPM.

Womit man sich natürlich schön brav auf die Software beschränken muss die der jew. Distributor beilegt.

Wieso denn? Hast Du das eigentlich ueberhaupt verstanden, um was es geht? Nochmal: Wenn es kein fertiges RPM gibt, dann baut man sich selbst eines und installiert dann dieses gebaute RPM-Paket statt ein "make install" durchzufuehren. Gruende dafuer wurden ja reichlich genannt, z.B. Pflege der RPM-Datenbank, Pflege der Abhaengigkeiten im System und leichtere Deinstallationen. Wo ist man da auf den jeweiligen Distributor angewiesen? Gar nicht, genau - es liegt alles in den eigenen Haenden. Wenn Du mal objektiv schauen wuerdest, muesstet Du IMHO erkennen, dass Deine Vorgehensweise einige erhebliche Nachteile besitzt. Aber ich sehe nun ehrlich gesagt wenig Sinn darin, Dir etwas zu erklaeren, wenn Du es gar nicht verstehen _willst_. Deswegen hoere ich jetzt auch besser auf...

CU, Th.

Lørdag 31 januar 2004 09:38 skrev David Haller:

Grrr.....

Am Sat, 31 Jan 2004, yep@osterbo-net.dk schrieb: [TOFU fachgerecht entsorgt]

http://learn.to/quote/

ja ja rictig so An euch beide ...... Schuldige mein rostiges deutsch. Johan

-dnh

-- Das ist die "Geiz ist Geil"-Generation, gespart wird vor allem am Verstand. Ich sehe das doch jeden Tag auf andere Bereiche des Lebens bezogen. Der größte Teil der Menschen will betrogen, belogen und abgzockt werden es muß alles schön bunt sein sonst funktioniert alles nicht. -- T. A. Bätzig in suse-linux

Hallo, * Thomas Hertweck textete am 31.01.04:

yep@osterbo-net.dk wrote:

...

Ooooopppppsss ....... hier kommt es korrekt

http://asic-linux.com.mx/~izto/checkinstall/

Was meintest Du mit "jetzt gibt es auch..."? Checkinstall war AFAIK schon bei SuSE 8.0 mit dabei, also wahrlich nichts Neues.

Bei meiner SuSE 7.3 isses schon mit drauf. cu flo -- Wolltest Du etwas zum Thema Netzkultur beisteuern, oder was sind Deine persoenlichen Motive hier? Oder doch nur Geltungsdrang der fuer Dich unwiedersprochen bleiben muss. [Frank Toennes in dsnu]

Lørdag 31 januar 2004 09:56 skrev Thomas Hertweck:

yep@osterbo-net.dk wrote:

...

Ooooopppppsss ....... hier kommt es korrekt

http://asic-linux.com.mx/~izto/checkinstall/

Was meintest Du mit "jetzt gibt es auch..."? Checkinstall war AFAIK schon bei SuSE 8.0 mit dabei, also wahrlich nichts Neues. Es wurden auf dieser Liste auch schon oft die (Vor- und) Nachteile diskutiert - schau dafuer bitte mal ins Archiv der Liste, es gibt genuegend Threads dazu.

Wir sind ja nicht ganz allein, viellicht hat andere daran interesse. Johan

Gruesse, Thomson

PS: Bitte lerne, Emails korrekt zu zitieren (quoten)! Siehe http://learn.to/quote/ Deine Antworten sind momentan sehr unuebersichtlich...

Hallo Carsten, Am Freitag, 30. Januar 2004 15:04 schrieb Carsten Becher:

Womit man sich natürlich schön brav auf die Software beschränken muss die der jew. Distributor beilegt. Und hoffen das man keine garstige Software aus dem Internet oder woher auch immer benötigt die unhöflicherweise nicht als rpm vorliegt.

Konvertierung? Mein YaST (SuSE 8.1) zeigt mir ein Paket namens "Alien". Ich meine auch dunkel in Erinnerung zu haben, in grauer Vorzeit mal ein KDE-Programm zur Konvertierung von RPM-, Debian- und Tarball-Paketen auf meiner Platte installiert gehabt zu haben. Der Name dieses Programms und die SuSE-Version sind mir aber jetzt entfallen. Grüße, Marcus