Devo compilare del software sulla mia macchina Fedora. Qual è il posto migliore per metterlo in modo da non interferire con il software in pacchetto?
Risposte:
Regola empirica, almeno sui sistemi basati su Debian:
/usr/localper le cose che è "a livello di sistema", cioè /usr/localtende ad essere in difetto di una distro $PATH, e segue una gerarchia di directory standard di UNIX con /usr/local/bin, /usr/local/libe così via
/optper le cose che non ti fidi di fare a livello di sistema, con per-app-prefissi cioè /opt/firefox-3.6.8, /opt/mono-2.6.7e 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ù.
/optse lo si sudoinstalla.
Se davvero non vuoi che interferisca affatto, non metterlo da nessuna parte nel tuo $PATH.
Se lo desideri $PATH, almeno assicurati di non installarlo /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 è nella mia $HOMEdirectory. In questo modo non devi usare sudonulla 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 aggiungerlo /home/username/stage/binal tuo $PATH.
/usr/local.).
FHS dice di metterlo in / usr / local dove le distribuzioni non dovrebbero toccarlo. /usr/local/binper i binari /usr/local/srcper l'origine e /usr/local/libper le librerie. Vedi le specifiche FHS per maggiori informazioni
/etc/mysqlper la configurazione?
/usr/local/etccartella per impostazione predefinita, immagino che dovrei usarla ... :-)
Il più delle volte, mi piace inserire le mie cose compilate /opt. È una specie di posto pseudo-standard. Puoi anche considerare /usr/local, ma preferisco mantenere le mie cose isolate al 100%.
/opt, tuttavia ho visto molte volte dove /usr/localè disseminata di spazzatura che proviene dalla distribuzione
/usr/localerano le gerarchie di directory che erano parallele a quelle dell'albero standard e forse indicizzavano i file per cose come TeX.
Mettili a /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 /usr/local/src/postgresql.
Fare le cose in questo modo aiuta quando è necessario passare da una versione all'altra tra documenti e versioni.
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 ...
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 incasinare l'intero sistema.
Se vuoi installare e rimuovere facilmente diverse applicazioni che hai creato tu stesso, puoi usare Stow come un semplice gestore di pacchetti.
Secondo FHS , /usr/local/viene utilizzato per le applicazioni compilate dall'origine, mentre /opt/viene utilizzato per applicazioni di terze parti non supportate dal fornitore del sistema operativo.
Due cose che consiglierei:
A livello di sistema: usa stow e installa 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 dallo standard XDG .
Puoi anche usare stow localmente, anche se non l'ho mai fatto :)
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.
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.
se stai compilando un'applicazione, puoi aggiungere il suo percorso eseguibile nella variabile ENV PATH. questo non avrà alcun impatto sugli altri utenti.
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
Il modo più semplice per farlo è quello di prendere il pacchetto sorgente ( .src.rpmper RPMites), decomprimerlo, hackerare il nuovo sorgente / configurazione / qualunque cosa in esso, cambiare la versione in modo appropriato e compilare. 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 è possibile creare il proprio repository con software locale, da condividere ad esempio con le macchine in un laboratorio.