Come installare veramente un file tar.gz su Linux - come gestire le applicazioni installate manualmente (o standalone)?

Vedo tutti questi link che spiegano pacchetti e .debs ... So che ... e ci sono molti kludges per far funzionare i file tar.gz (es: update-alternative per Java o rilasciare manualmente il file in / usr / local / bin (o da qualche altra parte, che avevo dedotto dalle ore di ricerca)). Se i pacchetti sono così intelligenti, come sono disponibili così poche applicazioni Linux in pacchetti o .debs / rpms?

Sto parlando come nuovo utente; So che gli esperti probabilmente lo sanno meglio (penso di poter scaricare una versione compilabile di Eclipse?). Come netbeans e chrome .sh, eclipse è una directory semplice e lanciabile, Java richiede questo update-alternativesbusiness ma non credo che si registri nella "lista dei programmi" di Ubuntu / Debian (si registra solo come comando), ecc. (So che questi sono a volte disponibile nei repository, ma sono solo confuso perché le pagine di download non hanno spiegazioni adeguate).

Per farla breve: se un download o compila un file tar.gz, come posso registrarlo nel sistema? update-alternativessembra registrarlo come comando, in Ubuntu, non compare nella barra di ricerca. In Debian, posso aggiungere manualmente un collegamento al programma di avvio di GNOME 2. Ma cosa dovrei davvero fare?

Modificare:

Quindi, dopo aver giocato un po 'di più con le nuove soluzioni, posso affinare il mio "problema":

Come devo gestire i miei programmi installati manualmente? Firefox ed Eclipse sono i miei unici esempi finora (non scarico molte cose). Entrambi possono esaurire la scatola, cosa che mi piace. Tranne, dove dovrei installarli? Vedo che Eclipse ha le sue istruzioni, ma preferirei fare tutti i miei "pacchetti manuali" allo stesso modo.

1. Dopo alcune ricerche, ho deciso di inserire questi programmi /usr/local/bin.
2. Da come installare eclipse , ho pensato di ottenere qualcosa da mostrare nel programma di avvio, ho bisogno di inserire un xxx.desktopfile ~/.local/share/applications/. Il nome di questo file .desktop è importante?
3. Le cose con gli autotools (cerco un file configureo unix/configure) funzioneranno bene. Alcuni punti di ricerca che dovrei usare CheckInstallper tenere traccia di tutti questi.
4. Dovrei usare update-alternativesper registrare i percorsi. Da questo thread Java , sembra che crei un collegamento da /usr/bin/javaa /usr/lib/jvm/jdk.... Quando installo queste applicazioni "standalone" come Eclipse o Firefox, devo sempre collegarmi a /usr/bin/[app]? E se l'asserzione 1 è vera, farei cose del generesudo update-alternatives --install "/usr/bin/[app]" "[app]" "/usr/local/bin/[app]" 1

Queste istruzioni sono corrette / un buon modo per gestire le installazioni manuali? Ci sono altri passaggi che dovrei seguire? Altri suggerimenti?

Perché molte app non sono disponibili nei repository di pacchetti?

Potrebbero esserci molte ragioni:

• Nessuno si è preso la briga di impacchettare l'app.
• A nessuno è consentito impacchettare l'app (come Oracle che insiste per essere l'unica a distribuire Java ).
• Il pacchetto è pubblicato sotto una licenza che contraddice i valori di distro.
• ...

Non c'è un solo motivo. Se desideri vedere la tua app preferita nel gestore dei pacchetti della tua distro, dovresti trattare ogni caso separatamente. Prova a metterti in contatto con gli sviluppatori (ad esempio su un canale IRC o una mailing list) e chiedi come potresti aiutare il packaging.

Come installare un tarball?

Un tarball (pacchetto .tar.gz) potrebbe contenere qualsiasi cosa. Fino a quando non lo si apre effettivamente, non è possibile supporre come installarlo. Ancora una volta, ogni pacchetto dovrebbe essere affrontato diversamente.

Cerca documentazione! Qualsiasi pacchetto (semi) decente fornirà istruzioni su come installare l'applicazione. Il tuo primo riflesso dovrebbe essere sempre quello di cercare un file di testo chiamato README, INSTALL o qualcosa del genere. Anche il controllo del sito Web dell'editore può essere d'aiuto.

Poiché ogni pacchetto è diverso, non esiste un modo universale per elaborare tutti i tarball del mondo. È come chiedere una ricetta che funzioni su tutti gli ingredienti del mondo. Non sta succedendo.

Una buona conoscenza del tuo sistema, della tua distribuzione e dell'ambiente desktop ti aiuterà, quindi, se questo è rassicurante, le cose sembreranno sempre più prevedibili mentre passi il tempo nel mondo di Linux.

Un caso speciale: autotools

Man mano che i progetti diventano più grandi, devono fornire modi semplici per passare dal codice sorgente al binario alla completa installazione sul sistema. Questo è il motivo per cui vengono forniti con un sistema di build incorporato, una raccolta di script per fare il necessario.

Nel mondo Linux / Open Source / Software libero, un sistema di build ha ottenuto un'adozione più ampia: GNU Autotools . Se hai mai a che fare con un pacchetto sorgente (n aperto), c'è una solida possibilità che utilizzerai Autotools.

Nel caso più semplice, ecco come installare un'app impacchettata con autotools:

• ./configure: Uno script che genererà i Makefile corrispondenti al tuo sistema (verifica spesso la disponibilità di dipendenze).
• make: Compilazione del codice sorgente in base ai Makefile generati in precedenza.
• make install: Copia i file binari nelle posizioni appropriate, crea collegamenti simbolici e qualsiasi altro passaggio definito dallo sviluppatore.

Appunti

• configuregli script di solito hanno molte opzioni, come quale compilatore usare o come definire la directory di destinazione. Se hai bisogno di flessibilità, vale la pena guardarlo ./configure --help.
• Anche se sei sicuro che si tratti di Autotools e lo conosci davvero bene, inizia sempre leggendo i documenti (README, INSTALL, ...)

Rispondi all'aggiornamento nella domanda

Quello che stai chiedendo non ha una risposta definitiva. Tutti qui potrebbero avere un'opinione su ciò che costituisce una "buona pratica", ma alla fine, solo tu puoi trovare ciò che funziona per te . Se ci fosse una risposta facile, non faresti la domanda. La tua distribuzione avrebbe risposto per te.

Detto questo, ecco alcune osservazioni personali.

• Sul mio sistema, mi riservo /usr/local/bini pacchetti installati dal mio gestore pacchetti. Tutto ciò che compilo / installo a mano va bene /opt. Questo è un dettaglio ma aiuta a evitare grossi mal di testa quando si ha a che fare con diverse versioni dello stesso programma.

• xxx.desktope i problemi della GUI in generale, sono specifici dell'ambiente desktop in uso. Se funziona per il tuo sistema, fantastico. Ma non può essere generalizzato a tutti gli ambienti disponibili su Unix.

• /usr/local/binha il vantaggio di essere già nel tuo PERCORSO . Se vuoi usare un'altra directory (come /optti suggerisco), assicurati di includerla nel PERCORSO. Se non sai come farlo, apri un terminale ed esegui quanto segue in un terminale (non il modo più carino per farlo, ma senza sapere nulla del tuo sistema, non posso suggerire nient'altro):echo 'export PATH=$PATH:/opt' >> ~/.bashrc

Credo che bisogna chiarire con te stesso ciò che si desidera "registrare" esso con .

Per spiegare - e non sto cercando di essere intelligente - "linux" è, ovviamente, il kernel, e il kernel non conosce né ha alcun interesse in nessuno dei software di spazio utente sul tuo sistema oltre init. Di cosa stiamo parlando qui?

Hai citato diverse distro. A volte creo software dal sorgente anche se è disponibile nel repository perché desidero impostare alcune opzioni di configurazione che non sono impostate nel binario della distribuzione. L'unico problema che ho con questo è che se il pacchetto è un prerequisito per qualcos'altro, devo davvero registrarlo con il sistema di imballaggio al fine di evitare l'installazione accidentale del pacchetto di distribuzione sopra quello che ho costruito. Su sistemi basati su fedora / rpm, questo viene fatto con rpm -i --justdb <package>. Non lo faccio su sistemi basati su debian / apt; invece forzo semplicemente le installazioni secondo necessità, il che è forse pigro - sembra che ci sia un modo migliore per farlo, creando un pacchetto fittizio che finge di soddisfare qualunque requisito. Questo è in qualche modo simile al suggerimento di m0nhawk di creare effettivamente un pacchetto dal sorgente .tar.gz - tranne un po 'più semplice (sarò onesto e dirò che non mi piace affatto il suggerimento di m0nhawk).

Sembra che tu abbia altri problemi oltre a quello con il sistema di imballaggio. Non mi è chiaro quali siano, sebbene tu menzioni l'ambiente desktop (ad esempio, Gnome). Questi sono eterogenei, quindi non c'è semplicemente una risposta alla domanda "come faccio su Linux" - non si tratta nemmeno di "come posso fare su Ubuntu" o "come posso farlo su gentoo "- si tratta di" come posso fare questo per il desktop gnome "o" come posso farlo sul desktop XFCE ", ecc. A mio avviso, l'unico problema è la questione dei lanciatori che menzioni, che io vorrei credere che ogni DE fornisce un modo semplice per farlo (ma non sarà esattamente lo stesso, perché sono diversi).

Quindi ci sono servizi gestiti dal sistema init (es. Systemd o upstart). Quindi questa domanda è in realtà una serie di domande correlate relative, potenzialmente:

• il sistema di confezionamento, ad es. apt o yum
• il sistema init, ad esempio systemd o upstart
• l'ambiente desktop, ad esempio kde o unity
• il filebrower, ad esempio nautilus o konqueror
• ?????

Parte del motivo per cui non può esistere una soluzione unificata semplice (sebbene lo standard XDG possa fornire alcune parti di tali) è che "linux" non è un semplice sistema operativo unificato e immagino che la stragrande maggioranza dei suoi utenti la preferisca in questo modo. Spesso non utilizzo affatto un DE e non utilizzo mai il browser di file con cui vengono forniti, ecc.

Ancora una volta, sto davvero cercando di essere d'aiuto con questo e non solo pontificato: se ci sono problemi che vuoi risolvere qui, dovrai considerare più precisamente quali sono questi problemi e quale software è effettivamente coinvolto con loro (oltre a "linux" ") se vuoi risolverli.

Penso che la ragione di base del tuo problema generale sia che un sistema Linux da solo non contenga un "registro" in quanto tale. Un file eseguibile è tutto ciò di cui hai veramente bisogno per eseguire qualcosa. Se non si desidera specificare il percorso completo dell'eseguibile, la maggior parte delle shell li cercherà nelle directory elencate nella variabile $ PATH degli ambienti. Può diventare un po 'più complesso con le librerie collegate e così via, ma normalmente non è necessario approfondire così tanto.

Diverse distribuzioni di Linux si sono standardizzate su vari layout di file system e sistemi di gestione dei pacchetti, in ciò risiede il problema. I Redhats usano rpm , Debians / Ubuntu usano i pacchetti deb. Anche Arch è andato per la sua strada . Dal punto di vista dei progetti software, a meno che tu non voglia essere incluso in una distribuzione, la tua base di utenti è interamente in una distro o un prodotto commerciale che mira a facilitare l'installazione per tutti, sono probabilmente gli unici punti che inizi a cercare di costruire vari pacchetti.

In realtà, un sorgente tar.gz che costruisce con gccè probabilmente la migliore definizione di un "pacchetto Linux" comune. Un kernel Linux con alcune utility GNU e GCC quasi il comune denominatore tra tutti i diversi tipi di sistemi operativi basati su Linux che puoi ottenere.

Non vorrei dire che "così poche" cose sono disponibili come pacchetti perché qualcosa di specifico che stai cercando non lo è. (o forse il distributore ha scelto di non preoccuparsi di tutto questo clamore del pacchetto? Come Chrome e il suo processo di aggiornamento). Ci sono così tanti pacchetti in giro per così tanti sistemi di pacchetti diversi per così tante architetture per così tanto software libero che non è divertente .

Se hai creato qualcosa che non viene fornito come pacchetto per la tua distribuzione di linux, o supporta l'opzione di compilare come pacchetto, il modo migliore per "registrarlo" come pacchetto reale è costruire un pacchetto per esso, definendo dove tutti i file dovrebbero andare in base al sistema di pacchetti scelto e installarlo in questo modo. Sii un'anima e contribuisci con il tuo lavoro di imballaggio al progetto in modo che altri possano trarne beneficio.

Ci sono varie guide sul web sulla costruzione di pacchetti . Debian è una di queste .

Se tutto ciò che vuoi fare è eseguire un pacchetto compilato, forse aggiungi il percorso binario al tuo $PATH?

Se stai facendo qualcos'altro, che cos'è?

Vorrei aggiungere che è anche possibile creare un collegamento simbolico ~/bin/anziché /usr/bin. *.desktopi file possono essere inseriti in ~/.local/share/applications/o /usr/share/applications/. Solo io uso il mio computer e mi piace evitare di toccare i file di sistema (qualsiasi cosa al di fuori della mia home directory) il più possibile.

Naturalmente, quando metti cose nella controparte "home directory", non verranno mostrate per gli altri utenti.

Questo è ciò che è incluso nell'impostazione predefinita ~/.profileper debian wheezy:

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