Wie installiere ich eine tar.gz-Datei unter Linux? Wie verwalte ich manuell installierte (oder eigenständige) Anwendungen?

Ich sehe all diese Links, die Pakete und .debs erklären ... ich weiß, dass ... und es gibt viele Probleme, um tar.gz-Dateien zum Laufen zu bringen (zB: Update-Alternativen für Java oder manuelles Ablegen der Datei in / usr / local / bin (oder irgendwo anders, was ich aus stundenlanger Suche abgeleitet hatte)). Wenn Pakete so schlau sind, wie wenige Linux-Anwendungen sind dann in Paketen oder .debs / rpms verfügbar?

Ich spreche als neuer Benutzer. Ich weiß, Experten wissen es wahrscheinlich besser (ich denke, ich kann eine kompilierbare Version von Eclipse herunterladen?). Wie Netbeans und Chrome ist .shauch Eclipse ein einfaches, startfähiges Verzeichnis. Java erfordert dieses update-alternativesGeschäft, aber ich glaube nicht, dass es sich in der "Programmliste" von Ubuntu / Debian (nur als Befehl registriert) usw. registriert (ich weiß, dass dies ein solches ist) manchmal in Repositories verfügbar, aber ich bin nur verwirrt, warum Download-Seiten nicht die richtigen Erklärungen haben).

Kurz gesagt: Wenn Sie eine tar.gz-Datei herunterladen oder kompilieren, wie registriere ich sie im System? update-alternativesscheint es als Befehl zu registrieren, in Ubuntu wird es nicht in der Suchleiste angezeigt. In Debian kann ich manuell eine Verknüpfung zum GNOME 2-Launcher hinzufügen. Aber was soll ich wirklich tun?

Bearbeiten:

Nachdem ich ein bisschen mehr mit den neuen Lösungen herumgespielt habe, kann ich mein "Problem" sortieren:

Wie soll ich meine manuell installierten Programme verwalten? Firefox und Eclipse sind meine einzigen Beispiele (ich lade nicht viel herunter). Sie können beide die Kiste rauslaufen lassen, was mir gefällt. Außer, wo soll ich sie installieren? Ich sehe, dass Eclipse eigene Anweisungen hat, aber ich würde lieber alle meine "manuellen Pakete" auf die gleiche Weise ausführen.

1. Nach einiger Recherche entschied ich mich, diese Programme in zu setzen /usr/local/bin.
2. Von wie Eclipse zu installieren , ich dachte , etwas zu zeigen , bis im Launcher zu bekommen, brauche ich ein setzen xxx.desktopin der Datei ~/.local/share/applications/. Ist der Name dieser .desktop-Datei wichtig?
3. Sachen mit Autotools (ich suche eine configureoder eine unix/configureDatei) werden gut funktionieren. Einige Forschungspunkte, die ich verwenden sollte CheckInstall, um all diese zu verfolgen.
4. Ich sollte verwenden update-alternatives, um Pfade zu registrieren. Aus diesem Java-Thread sieht es so aus, als würde ich einen Link von /usr/bin/javanach erstellen /usr/lib/jvm/jdk.... Wenn ich diese "Standalone" -Anwendungen wie Eclipse oder Firefox installiere, sollte ich immer eine Verknüpfung herstellen /usr/bin/[app]? Und wenn Behauptung 1 zutrifft, würde ich so etwas tunsudo update-alternatives --install "/usr/bin/[app]" "[app]" "/usr/local/bin/[app]" 1

Sind diese Anweisungen korrekt / ein guter Weg, um manuelle Installationen zu verwalten? Gibt es noch andere Schritte, denen ich folgen sollte? Andere Vorschläge?

Warum sind viele Apps in Paket-Repos nicht verfügbar?

Es kann viele Gründe geben:

• Niemand hat sich die Mühe gemacht, die App zu packen.
• Niemand darf die App paketieren (wie Oracle darauf besteht, der einzige zu sein, der Java verbreitet ).
• Das Paket wird unter einer Lizenz veröffentlicht, die den Distributionswerten widerspricht.
• ...

Es gibt keinen einzigen Grund. Wenn Sie Ihre Lieblings-App im Paket-Manager Ihrer Distribution sehen möchten, sollten Sie jeden Fall separat behandeln. Versuchen Sie, mit den Entwicklern in Kontakt zu treten (z. B. über einen IRC-Kanal oder eine Mailingliste), und fragen Sie, wie Sie beim Verpacken helfen können.

Wie installiere ich einen Tarball?

Ein Tarball (.tar.gz-Paket) kann alles enthalten. Bis Sie es tatsächlich öffnen, können Sie nicht davon ausgehen, wie es installiert werden soll. Auch hier sollte jedes Paket anders angegangen werden.

Dokumentation suchen! Jedes (halb-) anständige Paket enthält Anweisungen zur Installation der Anwendung. Ihr erster Reflex sollte immer darin bestehen, nach einer Textdatei mit dem Namen README, INSTALL oder ähnlichem zu suchen. Das Auschecken der Website des Herausgebers kann ebenfalls hilfreich sein.

Da jedes Paket anders ist, gibt es keinen universellen Weg, um jeden Tarball der Welt zu verarbeiten. Das ist, als würde man nach einem Rezept fragen, das mit allen Zutaten der Welt funktioniert. Passiert nicht.

Wenn Sie sich mit Ihrem System, Ihrer Distribution und Ihrer Desktop-Umgebung auskennen, werden die Dinge immer vorhersehbarer, je länger Sie sich in der Linux-Welt aufhalten.

Ein Sonderfall: Autotools

Wenn Projekte größer werden, müssen sie einfache Möglichkeiten bieten, um vom Quellcode zur Binärdatei und zur vollständigen Installation auf dem System zu wechseln. Aus diesem Grund werden sie mit einem eingebetteten Build-System ausgeliefert, einer Sammlung von Skripten, um das Notwendige zu tun.

In der Linux / Open Source / Free Software-Welt wurde ein Build-System weiter verbreitet: GNU Autotools . Wenn Sie sich jemals mit einem (n) Open Source-Paket befassen, besteht eine gute Chance, dass Sie Autotools verwenden.

Im einfachsten Fall können Sie eine mit Autotools gepackte App folgendermaßen installieren:

• ./configure: Ein Skript, das die Ihrem System entsprechenden Makefiles generiert (es prüft auch häufig die Verfügbarkeit von Abhängigkeiten).
• make: Kompilieren des Quellcodes gemäß den zuvor generierten Makefiles.
• make install: Kopiert die Binärdateien an die entsprechenden Speicherorte, erstellt Symlinks und alle anderen vom Entwickler definierten Schritte.

Anmerkungen

• configureSkripte haben normalerweise viele Optionen, z. B. welchen Compiler Sie verwenden oder wie Sie das Zielverzeichnis definieren. Wenn Sie Flexibilität brauchen, lohnt sich ein Blick darauf ./configure --help.
• Auch wenn Sie sicher , dass es sich sind Autotools und Sie wissen , dass es wirklich gut, immer beginnt mit docs (README, INSTALL, ...) Lesen

Antwort auf das Update in der Frage

Was Sie verlangen, hat keine eindeutige Antwort. Jeder hier mag eine Meinung darüber haben, was "gute Praxis" ist, aber am Ende des Tages können nur Sie herausfinden, was für Sie funktioniert . Wenn es eine einfache Antwort gäbe, würden Sie die Frage nicht stellen. Ihre Distribution hätte es für Sie beantwortet.

Nachstehend einige persönliche Bemerkungen.

• Auf meinem System reserviere ich /usr/local/binfür die Pakete, die von meinem Paketmanager installiert wurden. Alles, was ich von Hand kompiliere / installiere, geht rein /opt. Dies ist ein Detail, aber es hilft, größere Kopfschmerzen zu vermeiden, wenn Sie mit mehreren Versionen desselben Programms arbeiten.

• xxx.desktopund GUI-Probleme im Allgemeinen hängen von der verwendeten Desktop-Umgebung ab. Wenn es für Ihr System funktioniert, großartig. Es kann jedoch nicht auf alle unter Unix verfügbaren Umgebungen verallgemeinert werden.

• /usr/local/binhat den Vorteil, bereits in deinem PFAD zu sein . Wenn Sie ein anderes Verzeichnis verwenden möchten (wie /optich es vorschlage), müssen Sie es in Ihren PATH aufnehmen. Wenn Sie nicht wissen, wie es geht, öffnen Sie ein Terminal und führen Sie Folgendes in einem Terminal aus (dies ist nicht die schönste Möglichkeit, aber ohne etwas über Ihr System zu wissen, kann ich nichts anderes vorschlagen):echo 'export PATH=$PATH:/opt' >> ~/.bashrc

Ich denke , dass Sie mit sich selbst zu klären, was Sie es auf „registrieren“ wollen mit .

Zum Erklären - und ich versuche nicht, schlau zu sein - ist "Linux" natürlich der Kernel, und der Kernel kennt die Userspace-Software auf Ihrem System über init hinaus weder und hat auch kein Interesse daran. Also, worüber reden wir hier?

Sie erwähnen eine Reihe von verschiedenen Distributionen. Manchmal erstelle ich Software aus dem Quellcode, obwohl sie im Repository verfügbar ist, da ich einige Konfigurationsoptionen festlegen möchte, die nicht in der Distributionsbinärdatei festgelegt sind. Das einzige Problem, das ich dabei habe, ist, dass ich das Paket, wenn es eine Voraussetzung für etwas anderes ist, tatsächlich beim Verpackungssystem registrieren muss, um zu vermeiden, dass das Distributionspaket versehentlich über dem von mir erstellten installiert wird. Auf Fedora / RPM-basierten Systemen geschieht dies mit rpm -i --justdb <package>. Ich mache das nicht auf Debian / Apt-basierten Systemen; Stattdessen erzwinge ich einfach die Installation nach Bedarf, was vielleicht faul ist - es scheint eine schönere Möglichkeit zu geben, dies zu tun, indem ein Dummy-Paket erstellt wird, das vorgibt, eine beliebige Voraussetzung zu erfüllen. Das entspricht in etwa dem Vorschlag von m0nhawk, tatsächlich ein Paket aus der .tar.gz-Quelle zu erstellen - außer ein bisschen einfacher (ich bin ehrlich und sage, dass ich den Vorschlag von m0nhawk überhaupt nicht mag).

Es scheint, dass Sie neben dem Verpackungssystem noch andere Probleme haben. Mir ist nicht klar, was das ist, obwohl Sie die Desktop-Umgebung erwähnen (z. B. Gnome). Diese sind heterogen, daher gibt es einfach keine Antwort auf die Frage "Wie mache ich das unter Linux?" - es geht nicht einmal um die Frage "Wie mache ich das unter Ubuntu?" Oder "Wie mache ich das unter Linux?" gentoo "- es ist eine Frage von" wie mache ich das für den Gnome-Desktop "oder" wie mache ich das auf dem XFCE-Desktop "usw. Meiner Meinung nach ist das einzige Problem die Frage der Starter, die Sie erwähnen, die ich Ich würde gerne glauben, dass jedes DE ein einfaches Mittel bietet, um dies zu tun (aber es wird nicht genau dasselbe sein, weil sie unterschiedlich sind).

Dann gibt es Dienste, die vom init-System verwaltet werden (z. B. systemd oder upstart). Bei dieser Frage handelt es sich also tatsächlich um eine Reihe verwandter Fragen, die sich möglicherweise auf Folgendes beziehen:

• das Verpackungssystem, zB apt oder yum
• das Init-System, zB systemd oder upstart
• die Desktop-Umgebung, zB kde oder unity
• der filebrower, zB nautilus oder konqueror
• ?????

Ein Grund dafür, dass es keine einfache einheitliche Lösung geben kann (obwohl der XDG-Standard möglicherweise einige Teile davon enthält), ist, dass "linux" kein einfaches einheitliches Betriebssystem ist, und ich denke, dass die große Mehrheit seiner Benutzer dies vorziehen. Ich verwende oft überhaupt keine DE und ich verwende nie den Dateibrowser, mit dem sie kommen, usw.

Auch hier versuche ich wirklich hilfreich zu sein und nicht nur Pontifikat: Wenn es Probleme gibt, die Sie hier lösen möchten, müssen Sie genauer überlegen, was diese Probleme sind und welche Software tatsächlich mit ihnen zusammenhängt (jenseits von "Linux") ") wenn du sie lösen willst.

Ich denke, der Hauptgrund für Ihr allgemeines Problem ist, dass ein Linux-System als solches keine "Registry" enthält. Eine ausführbare Datei ist alles, was Sie wirklich brauchen, um etwas auszuführen. Wenn Sie nicht den vollständigen Pfad zur ausführbaren Datei angeben möchten, suchen die meisten Shells in den Verzeichnissen, die in Ihrer Umgebungsvariablen $ PATH aufgeführt sind, nach ihnen. Bei verknüpften Bibliotheken und so weiter kann es etwas komplexer werden, aber normalerweise müssen Sie nicht so weit gehen.

Verschiedene Distributionen von Linux haben sich auf verschiedene Dateisystemlayouts und Paketverwaltungssysteme standardisiert, darin liegt das Problem. Die Redhats benutzen rpm , Debians / Ubuntu benutzen deb-Pakete. Arch ging auch seinen eigenen Weg . Aus Sicht von Softwareprojekten befindet sich Ihre Benutzerbasis, sofern Sie nicht in eine Distribution aufgenommen werden möchten, ausschließlich in einer Distribution oder in einem kommerziellen Produkt, das eine einfache Installation für jedermann anstrebt. Dies sind wahrscheinlich die einzigen Punkte, mit denen Sie beginnen möchten verschiedene Pakete.

Tatsächlich ist eine Quelle, mit der tar.gz erstellt gccwird, wahrscheinlich die beste Definition eines allgemeinen "Linux-Pakets". Ein Linux-Kernel mit einigen GNU-Dienstprogrammen und GCC, der in etwa den gemeinsamen Nenner aller verschiedenen Varianten von Linux-basierten Betriebssystemen darstellt.

Ich würde nicht so weit gehen zu sagen, dass "so wenige" Dinge als Pakete verfügbar sind, weil etwas bestimmtes, das Sie suchen, nicht vorhanden ist. (oder vielleicht hat sich der Distributor dafür entschieden, sich nicht mit all dieser Aufregung zu beschäftigen? Wie Chrome und sein eigener Update-Prozess). Es gibt so viele Pakete um für so viele verschiedenen Paket - Systeme für so viele Architekturen für so viele freie Software seines lustigen nicht .

Wenn Sie etwas erstellt haben, das nicht als Paket für Ihre Linux-Distribution geliefert wird, oder die Option zum Erstellen als Paket unterstützt, können Sie es am besten als echtes Paket registrieren, indem Sie ein Paket dafür erstellen und definieren, wo alle Pakete enthalten sind Die Dateien sollten auf dem ausgewählten Paketsystem basieren und auf diese Weise installiert werden. Seien Sie eine Seele und bringen Sie Ihre Verpackungsarbeit wieder in das Projekt ein, damit andere davon profitieren können.

Im Internet gibt es verschiedene Anleitungen zum Erstellen von Paketen . Debian ist einer von ihnen .

Wenn Sie nur ein kompiliertes Paket ausführen möchten, fügen Sie möglicherweise den Binärpfad zu Ihrem hinzu $PATH.

Was ist es, wenn Sie etwas anderes tun?

Ich möchte hinzufügen, dass Sie ~/bin/stattdessen auch auf symlink können /usr/bin. *.desktopDateien können in ~/.local/share/applications/oder abgelegt werden /usr/share/applications/. Nur ich benutze meinen Computer und ich vermeide es so oft wie möglich, Systemdateien (irgendetwas außerhalb meines Home-Verzeichnisses) selbst zu berühren.

Wenn Sie Inhalte in das "Home-Verzeichnis" einfügen, werden sie natürlich nicht für andere Benutzer angezeigt.

Dies ist, was in der Standardeinstellung ~/.profilefür Debian Wheezy enthalten ist:

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
    PATH="$HOME/bin:$PATH"
fi