Effetto della compilazione dall'origine su applicazioni già installate


8

Uso Ubuntu 12.04. Supponiamo di aver installato package xdal repository (con tutte le sue dipendenze) alla versione 1.7 ma ho bisogno di alcune funzionalità che sono disponibili solo nella versione 1.8, quindi scarico il tar di origine e lo compilo:

./configure  
make  
make install
  • Questo sovrascrive i binari 1.7 esistenti?
  • Se i file binari esistenti vengono sovrascritti, il gestore pacchetti riflette la nuova versione (1.8) e può package xessere aggiornato dal gestore pacchetti in futuro?
  • Se package yha una dipendenza di package x 1.8- sarà soddisfatto?

Ho cercato di trovare una buona fonte online che spieghi questo. Se avete suggerimenti, per favore fatemelo sapere.


Se eludere deliberatamente il gestore dei pacchetti, cosa diavolo ti fa pensare che in seguito riconoscerà ciò che hai installato?
Shadur,

@Shadur Questo aspetto di questa domanda dipende fondamentalmente dal problema di ciò che accade, esattamente quando si installa il software dal sorgente usando make install. Penso che sia chiaro dalle risposte che essenzialmente tutto ciò che sta accadendo è che i file vengono copiati nelle directory all'interno del prefisso di installazione (anche se si scopre che ciò è con la possibilità che alcuni file di configurazione possano essere inseriti /etce alcuni dati modificabili dinamicamente che rappresentano un'iniziale lo stato di qualcosa può essere inserito /var). Tuttavia, se ritieni che ciò non sia chiaro, sarei felice di modificare la mia risposta per spiegare.
Eliah Kagan,

@EliahKagan Ero principalmente retorico con Filippo, lì.
Shadur,

Risposte:


12

La stragrande maggioranza dei .debpacchetti, indipendentemente dal fatto che siano forniti o meno dai repository ufficiali, si installa con il prefisso /usr.

Ciò significa che gli eseguibili che devono essere eseguiti dall'utente entrano /usr/bino /usr/sbin(o /usr/gamesse si tratta di un gioco), entrano le librerie condivise, entrano /usr/libi dati condivisi indipendenti dalla piattaforma /usr/share, entrano i file di intestazione /usr/includee entra automaticamente il codice sorgente installato /usr/src.

Una piccola percentuale di pacchetti utilizza /come prefisso. Ad esempio, il bashpacchetto inserisce l' basheseguibile /bin, non /usr/bin. Questo è per i pacchetti che forniscono lo stretto necessario per l'esecuzione in modalità utente singolo (come la modalità di ripristino) e per avviare la modalità multi-utente (ma ricordate, che spesso include funzionalità per montare alcuni tipi di condivisioni di rete ... nel caso in cui /usrè un file system remoto).

Una piccola percentuale di .debpacchetti, principalmente quelli creati con Quickly , crea una cartella specifica per pacchetto all'interno /opte vi mette tutti i file. Oltre a ciò, la maggior parte delle volte /optè la posizione utilizzata dal software installato da un programma di installazione eseguibile che non utilizza il gestore pacchetti del sistema ma non comporta la compilazione dall'origine. (Ad esempio, se installi un programma proprietario come MATLAB, probabilmente lo inserirai /opt.)

Al contrario di tutto ciò, quando scarichi un archivio di origine (o ottieni codice sorgente da un sistema di controllo di revisione come Bazaar o git), lo costruisci e lo installi, di solito si installa nel prefisso /usr/local(a meno che tu non gli dica di farlo altrimenti). Ciò significa che i file eseguibili vanno in /usr/local/bin, /usr/local/libo /usr/local/games, le librerie in /usr/local/lib, e così via.

Ci sono alcune eccezioni a questo: alcuni programmi, per impostazione predefinita, si installano nel /usrprefisso e quindi sovrascriverebbero le installazioni degli stessi programmi dai .debpacchetti. In genere puoi impedirlo eseguendolo ./configure --prefix=/usr/localinvece che ./configurequando li costruisci. Sottolineo nuovamente che di solito questo non è necessario.

(È per questo motivo che ha molto senso inserire il codice sorgente che stai costruendo e che installerai per l'uso a livello di sistema /usr/local/src, che esiste a tale scopo.)

Supponendo che la versione in pacchetto sia installata /usre la versione installata dal sorgente sia in /usr/local:

  • I file dal pacchetto installato non verranno sovrascritti.

    In genere, la versione più recente verrà eseguita quando si richiama manualmente il programma dalla riga di comando (presupponendo /usr/local/bino ovunque siano installati gli eseguibili nella PATHvariabile di ambiente e appare prima della corrispondente /usrdirectory prefissata, ad esempio /usr/bin).

    Ma potrebbero esserci dei problemi con ciò che i lanciatori vengono creati e resi accessibili attraverso i menu o la ricerca. Inoltre, se hai installato più di una versione di una libreria in luoghi diversi, può diventare un po 'più complicato determinare quale sarà utilizzato da quale software.

    Se non stai effettivamente utilizzando entrambe le versioni del programma o della libreria, spesso dovresti rimuovere quella che non stai utilizzando, anche se in situazioni limitate potresti voler mantenere un pacchetto installato per soddisfare le dipendenze.

Tuttavia, se per qualsiasi motivo i file vengono sovrascritti (ad esempio, se il codice sorgente è installato /usranziché /usr/local):

  • Il gestore pacchetti non saprà nulla su come è stato modificato il software installato. Penserà che la vecchia versione sia installata. Potrebbero verificarsi problemi. Dovresti evitare questo. Se hai creato questa situazione, dovresti disinstallare il software che hai installato dal sorgente (di solito con sudo make uninstallnella directory), quindi disinstallare il pacchetto oi pacchetti che forniscono i file che sono stati sovrascritti (poiché non verranno ripristinati disinstallando la versione installata dalla fonte). Quindi reinstallare la versione che si desidera avere./usr/local/src/program-or-library-name

Per quanto riguarda le dipendenze soddisfacenti:

  • Se esiste un .debpacchetto che dipende dal software installato dall'origine e richiede la versione installata dall'origine (o successiva), tale pacchetto non verrà installato correttamente. (O, per essere più precisi, potresti essere in grado di "installarlo" ma non sarà mai "configurato", quindi non sarai in grado di usarlo.) Le dipendenze sono risolte da quali versioni di pacchetti sono installati, non da quale software hai effettivamente.

    Allo stesso modo, il software tenterà almeno di installarsi completamente anche se sono stati eliminati manualmente i file forniti dai pacchetti da cui dipende il software da installare. (Non dovresti generalmente provare a sfruttarlo per qualsiasi scopo. Il gestore di pacchetti che opera in base a informazioni false è quasi sempre una cosa negativa.)

Pertanto, se non riesci a trovare un pacchetto che fornisce la versione del software di cui hai bisogno, potresti dover creare il tuo .debpacchetto dal software che hai compilato e installarlo da quel pacchetto. Quindi il gestore dei pacchetti saprà cosa sta succedendo. Creare un pacchetto per uso personale, che non è necessario per funzionare correttamente sui computer di altre persone, in realtà non è molto difficile. (Ma sento che potrebbe essere al di fuori del campo di applicazione della tua domanda, come è attualmente formulato.)


Grazie per la tua risposta dettagliata, ha chiarito molti concetti
Philip D'Rozario,

5

Ciò che si installa dal centro software o con un comando APT ( apt-get, aptitude) o con dpkgè noto al sistema di gestione dei pacchetti. dpkgè lo strumento di manipolazione dei pacchetti di basso livello, APT e gli amici sono strumenti di livello superiore che invocano dpkgper eseguire l'installazione effettiva e gestiscono anche dipendenze e download di pacchetti.

Se si compila un programma dal sorgente, non sarà noto al gestore dei pacchetti. La convenzione su Linux, che dovresti seguire con il dolore di non riuscire a tenere traccia delle cose e di sovrascrivere le tue installazioni, è:

  • /bin, /lib, /sbin, /usrSono riservate al gestore dei pacchetti;
  • tranne che /usr/localè per l'amministratore di sistema - rispetta la gerarchia di directory lì, ma sei solo per gestire i file.

Vedi il modo migliore per aggiornare vim / gvim a 7.3 in Ubuntu 10.04? per un elenco di modi per ottenere versioni più recenti del software. Il modo più semplice è ottenere un PPA , se ce n'è uno. Se ricevi un pacchetto binario o compili dal sorgente, ti consiglio di usare stow per gestire il tuo software installato manualmente. In alternativa, crea il tuo .debpacchetto - è più lavoro, ma paga se aggiorni spesso (di solito la ripetizione del pacchetto per la prossima versione secondaria è molto veloce) o se distribuisci su molte macchine che eseguono la stessa distribuzione.

Con la maggior parte dei programmi, se eseguito ./configure && make && sudo make install, il programma è installato in /usr/local. Controlla la documentazione fornita con l'origine (in genere in un file chiamato READMEo INSTALL) o esegui ./configure --helpper verificare che sia così. Se il programma è installato in /usr/local, non interferirà con la versione fornita dal gestore pacchetti. /usr/local/binviene prima sul sistema PATH. Nota che dovrai eseguire make installcome amministratore (root); non compilare come root. Come notato sopra, ti consiglio di usare stow invece di installarlo direttamente in /usr/local.


1

Questo dipende dal pacchetto e da molte altre cose

  1. convenzioni di denominazione utilizzate: il binario contiene numeri di versione nei nomi dei file
  2. posizione di installazione - è di default in opt, ma la versione in pacchetto è in / usr
  3. molte più possibilità

Per farla breve:
non esiste una risposta generica. Dipende fortemente dal pacchetto. Dovresti usare PPA +1 ufficiali se possibile invece di compilare dalla fonte.


1
In realtà è abbastanza insolito che i programmi o le librerie compilati dal sorgente siano installati /opt. /usr/localè il prefisso standard e persino /usrè un prefisso predefinito più comune di /opt. /optè più comunemente usato per software che si installa all'interno di una directory dedicata chiamata per la particolare applicazione (quindi, ad esempio, un'applicazione chiamata Foo potrebbe essere installata con tutti i suoi file all'interno /opt/foo).
Eliah Kagan,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.