Ich bin relativ neu in Linux, aber ich habe mich mit einer Ubuntu-VM herumgespielt, um mich mit ihr vertraut zu machen. Ich habe SSH, Apache, PHP, MySQL, Ruby, Rails, Passenger und Git eingerichtet, um meine Webentwicklungsprojekte durcheinander zu bringen. Ein paar davon habe ich aus Source, PHP und Git aus meinem Kopf gebaut.
Ich habe mich gefragt, was ist die beste Methode, um etwas aus der Quelle neu zu kompilieren / neu zu installieren? Zum Beispiel, wenn ich Git auf eine neuere Version aktualisieren oder eine Erweiterung für PHP aktivieren wollte. Ist es in Ordnung, es neu zu kompilieren und dann über der aktuellen Installation zu installieren? Oder ist das ein Nein und ich sollte vor der Neuinstallation zuerst deinstalliert werden?
Wenn ja, wie genau deinstallieren Sie etwas, das von der Quelle installiert wurde?
Ich habe ein wenig versucht, herumzusuchen, aber dies scheint eine schwierige Frage zu sein, und ich konnte beim Erstellen von Quellen nichts finden, nur bei der Verwendung von Paketmanagern.
Danke für jede Hilfe.
EDIT: Danke für all die bisherigen Eingaben. Sie alle schienen meine Frage zum Deinstallieren zu beantworten, aber die Hauptfrage, nach der ich gesucht habe, war:
Ob ich etwas deinstallieren sollte, das ich aus der Quelle erstellt habe, bevor ich es neu kompiliere und erneut installiere. Oder ist es in Ordnung, über aktuelle Installationen zu installieren, wenn ich ein Konfigurationsflag ändern oder auf eine neuere Version aktualisieren muss?
3 Antworten auf die Frage
3
Matt
Dies ist möglicherweise nicht der Anser, nach dem Sie suchen, aber die bewährte Methode für Ubuntu ist es, die Dinge nicht vom Quellcode aus zu installieren. Ich würde sagen, dass Sie sich apt ansehen wollen oder seine Ableitungen (aptitude et al. ). Git zum Beispiel lebt in einem Paket namens git-core.
Wenn Sie am Ende Dinge aus dem Quellcode installieren, können Sie ziemlich sicher sein, dass sie dort landen /usr/localwerden. Dadurch können Sie alte Teile und Teile manuell entfernen, wenn Sie sich für ein Upgrade entscheiden.
Einige Makefiles haben auch Deinstallations- / Deinstallationsziele, aber ich bin nicht sicher, für welchen Anteil dies gilt.
Danke, ich würde gerne bei Paketmanagern bleiben, aber es scheint, als hätten sie oft keine Versionen, nach denen ich suche. Wenn ich mich erinnere, als ich vor einiger Zeit alles eingerichtet hatte, lag die verfügbare Git-Version um einige Hauptversionen hinterher und ich konnte PHP 5.3 nur 5.2.x nicht finden. Wenn ich etwas aus dem Quellcode baue, werden Dateien immer nur in / usr / local gespeichert?
anomareh vor 14 Jahren
0
/ usr / local ist eine Konvention. Bei der Installation von der Quelle wird nur / usr / local * verwendet, sofern dies nicht * ist. Die Makefiles sind die einzige maßgebliche Quelle.
Richard Hoskins vor 14 Jahren
1
2
Richard Hoskins
Das Kompilieren Ihrer Software in einer VM ist eine großartige Möglichkeit, sich mit einem Betriebssystem "vertraut zu machen". Zweifellos sind alle schrecklichen Warnungen über das Rollen Ihrer eigenen Maschine wahr, für eine Produktionsmaschine, aber auf lange Sicht sind Sie besser dran, wenn Sie jetzt Ihre Fehler machen.
Wenn es einen Grund gibt, eine frühere Version zu deinstallieren, sollte dies in einer README- oder INSTALL-Datei vermerkt werden. Wenn nicht, sollte es sicher sein, "make install" auszuführen, wodurch die alte Version überschrieben wird. Machen Sie einen Schnappschuss von Ihrer VM, bevor Sie "make install" machen. Wenn etwas bricht, versuchen Sie es zu beheben. Wenn Sie es nicht beheben können, kehren Sie zum Schnappschuss zurück und versuchen Sie es erneut.
Wenn Sie später das vollständig rückgängig machen möchten, enthält das Makefile alle Informationen, die Sie deinstallieren müssen. Sie können Ihr eigenes "uninstall" -Ziel erstellen oder manuell mit "rm" tun. Denken Sie daran, dass andere Dinge in der Zwischenzeit von der Software abhängig geworden sind. Daher ist die Snapshot-Strategie auch für die Deinstallation sinnvoll.
Bei aller Güte der Paketmanager gibt es einige Fehler. Einige Pakete haben große Abhängigkeiten, um Funktionen hinzuzufügen, an denen Sie nicht interessiert sind. Manchmal haben sie nicht die Version der gewünschten Software. Manchmal haben sie überhaupt keine Software.
Wenn Sie auf einem wichtigen Computer auf eines dieser Probleme stoßen und Sie völlig auf Paketverwalter angewiesen sind, werden Ihre Fehler teuer. Aber jetzt können Sie einfach zum zuletzt bekannten Gut zurückkehren und ein wenig klüger vorgehen.
Ja, genau das habe ich getan. Jedes Mal, wenn ich ein Stück installiert habe und arbeite, habe ich einfach einen neuen Schnappschuss gemacht. Ich habe ein paar Tage gebraucht, um alles gut zu spielen, aber es war nicht so schlimm. Mein größtes Problem mit Paketmanagern waren Versionsprobleme.
anomareh vor 14 Jahren
1
@ Anomareh: Ich empfehle dringend, dass Sie lernen, wie Sie Ihre eigenen Pakete erstellen. Sie können die integrierten Deinstallationsfunktionen des Paketmanagers verwenden und die gewünschten Versionen erhalten. Wenn eine unnötige Abhängigkeit besteht, können Sie sie in Ihrem eigenen lokalen Paket entfernen. Ich habe seit Jahren nicht mehr nach / usr / local installiert. Ich kompiliere entweder ein lokales Paket oder installiere es in mein $ HOME-Verzeichnis.
quack quixote vor 14 Jahren
0
@ ~ quack Danke für den Rat, ich werde mich darum kümmern. Wenn Sie Links für Anfänger zu diesem Thema haben, wäre das großartig.
anomareh vor 14 Jahren
0
In Ubuntu können Sie checkinstall installieren und anstelle von sudo make install können Sie sudo checkinstall -D ausführen. Dadurch wird das Programm vom Quellcode aus installiert, aber apt-get kann auch wie ein normales Programm entfernt und ein .deb erstellt werden Datei.
Justin S vor 14 Jahren
1
1
whitequark
Es gibt keine generische Methode zum Deinstallieren von quellkompilierten Dingen. Das ist einer der vielen Gründe , nichts von der Quelle zu installieren . make uninstallfunktioniert manchmal durch.
Sie können einige Änderungen an einem Paket vornehmen, ohne "rohe" Quellen zu installieren: Schauen Sie sich diese und diese Artikel von Debian-Administration.org an .