it-swarm.it

Dove devo mettere il software che compilo da solo?

Devo compilare del software sulla mia macchina Fedora. Qual è il posto migliore per metterlo in modo da non interferire con il software in pacchetto?

130
theotherreceive

Regola empirica, almeno sui sistemi basati su Debian:

  • /usr/local per cose che sono "a livello di sistema", ovvero. /usr/local tende ad essere nel default di una distro $PATH e segue una gerarchia di directory UNIX standard con /usr/local/bin, /usr/local/lib, eccetera.

  • /opt per cose di cui non ti fidi a rendere a livello di sistema, con prefissi per app, ad es. /opt/firefox-3.6.8, /opt/mono-2.6.7, e così via. Le cose qui richiedono una gestione più attenta, ma hanno anche meno probabilità di rompere il sistema, ed è più facile da rimuovere poiché basta eliminare la cartella e non c'è più.

92
directhex

Se davvero non vuoi che interferisca affatto, non metterlo da nessuna parte nel tuo $PATH.

Se lo vuoi in $PATH, almeno assicurati di non installare su /usr/local. Ho scoperto che un sacco di software guarda lì anche se è installato dalla distribuzione in /usr.

Il mio modo preferito di installare software compilato su misura è nel mio $HOME directory. In questo modo non devi usare Sudo per nulla ed è ben separato dal resto del tuo sistema. Per esempio:

mkdir ~/stage
./configure --prefix=/home/username/stage && make && make install

E se lo desideri, puoi aggiungere /home/username/stage/bin alla tua $PATH.

50
Sandy

FHS dice di metterlo in/usr/local dove le distribuzioni non dovrebbero toccarlo. /usr/local/bin per i binari /usr/local/src per l'origine e /usr/local/lib per le biblioteche. Vedi FHS spec per maggiori informazioni

21
xenoterracide

Il più delle volte, mi piace inserire le mie cose compilate in /opt. È una specie di posto pseudo-standard. Puoi anche considerare /usr/local, ma preferisco mantenere le mie cose isolate al 100%.

10
Scott Anderson

Mettili in /usr/local/src.

Quello che faccio è estrarre la fonte in questa directory. Creerà un percorso simile

/usr/local/src/postgresql-8.3.7

Quindi creo un link simbolico ad esso:

/usr/local/src # ln -s  postgresql-8.3.7 postgresql

Fai tutto il tuo edificio in /usr/local/src/postgresql.

Fare le cose in questo modo aiuta quando è necessario passare da una versione all'altra tra documenti e versioni.

9

Questo mi ricorda che devo usare checkinstall più spesso! In questo modo faccio solo il solito

 ./configure
 make

seguito da

 Sudo checkinstall

per creare un file . deb ...

6
Kevin Cantu

Per FHS , /usr/local/ viene utilizzato per le applicazioni compilate dal sorgente, mentre /opt/ viene utilizzato per applicazioni di terzi non supportate dal fornitore del sistema operativo.

5
Aaron Toponce

Se c'è possibilità, suggerirei di compilare il tuo software e quindi di creare un pacchetto FC (credo che stia usando yum per installare i pacchetti software). Quindi è possibile installare quel pacchetto del proprio software compilato e rimuoverlo senza rovinare l'intero sistema.

5
Eimantas

Se vuoi installare e rimuovere facilmente diverse applicazioni che hai creato tu stesso, puoi usare Stow come semplice gestore di pacchetti.

5
Daniel James

Due cose che consiglierei:

A livello di sistema: utilizzare stow e installare in/usr/local/stow/versione-pacchetto. Quindi puoi passare facilmente da una versione all'altra.

A casa mia, o se non ho i permessi di scrittura/usr/local, installo personalmente i programmi sotto ~/.local, che è suggerito da standard XDG .

Puoi anche usare stow localmente, anche se non l'ho mai fatto :)

4
elmarco

In realtà non è poi così difficile creare deb o rpm da un tarball sorgente. In questo modo, è possibile utilizzare le funzionalità del gestore pacchetti della distro per mantenere pulito il sistema. Questo è quello che faccio, il più delle volte: basta creare un piccolo numero di giri.

3
wzzrd

Ho un setup un po 'diverso rispetto alla maggior parte delle persone perché faccio molto sviluppo. Ho una directory/home/jackson/bin/in cui installo roba e ho modificato il mio .bashrc aggiungendo questo:

export PATH=/home/jackson/bin/bin::$PATH
export LD_LIBRARY_PATH=/home/jackson/bin/lib:$LD_LIBRARY_PATH
export PKG_CONFIG_PATH=/home/jackson/bin/lib/pkgconfig:$PKG_CONFIG_PATH

Non lo farei per tutto, ma è bello durante lo sviluppo.

3
jacksonh

se stai compilando un'applicazione, puoi aggiungere il suo percorso eseguibile nella variabile ENV PATH. questo non avrà alcun impatto sugli altri utenti.

2
Hemant

C'è sempre la possibilità di "metterlo dove appartiene" ma prima di tutto scrivi un semplice numero di giri.

2
Nils

Se si desidera che l'applicazione sia disponibile per tutti gli utenti del sistema e si disponga delle autorizzazioni necessarie, utilizzare/opt. Se vuoi che l'applicazione sia disponibile solo per te (e root), usa/home/username

1
Silviu Bogan

Scrivi un RPM, non è difficile, ha delle linee guida su dove mettere le cose e semplifica la disinstallazione.

In questo caso, installa i file in /usr e non in /usr/local, come tutti gli altri file che arrivano attraverso il sistema di packaging.

0
user55149

Il modo più semplice per farlo è quello di prendere il pacchetto sorgente (.src.rpm per RPMites), scompattalo, modifica il nuovo sorgente/configurazione/qualunque cosa in esso, cambia la versione in modo appropriato e costruisci. L'installazione di questo rende il gestore pacchetti consapevole del nuovo pacchetto, consente di considerarlo per le dipendenze e disinstallare/aggiornare.

Questo è un lavoro ingrato la prima volta, ma se esce una nuova versione (o qualche patch critica), è più semplice aggiornarlo. Un altro vantaggio è che puoi creare il tuo repository con software locale, da condividere ad es. dalle macchine in un laboratorio.

0
vonbrand