Devo inserire l'applicazione in / usr / local o / usr / local / share?

Quali sono gli "standard" - dovrei mettere l'applicazione (non solo binaria, ma l'intera distribuzione) in / usr / local o / usr / local / share.

Ad esempio scala o weka: contiene esempi, binari, librerie e così via. Così sarebbe

/usr/local/scala-2.9.1 

o

/usr/local/share/scala-2.9.1

Dal momento che sono l'unico amministratore non è un grosso problema per me, ma preferisco usare qualcosa che è ampiamente usato, non con i miei costumi.

Importante: non sto chiedendo dei casi in cui dovresti dividere l'app in / usr / local / bin, / usr / local / lib e così via. Piuttosto, sto chiedendo il caso in cui devi mantenere una directory principale per l'intera applicazione.

Penso che / optare sia più standard in questo tipo di contesto. La sezione pertinente nel Filesystem Hierarchy Standard è citata di seguito.

Le distribuzioni possono installare il software in / opt, ma non devono modificare o eliminare il software installato dall'amministratore di sistema locale senza il consenso dell'amministratore di sistema locale.

 Motivazione L'uso di / opt per il software aggiuntivo è una pratica consolidata nella comunità UNIX. L'interfaccia binaria dell'applicazione System V [AT&T 1990], basata sulla definizione dell'interfaccia System V (terza edizione), prevede una struttura / opt molto simile a quella qui definita.

Intel Binary Compatibility Standard v. 2 (iBCS2) fornisce anche una struttura simile per / opt.

In generale, tutti i dati richiesti per supportare un pacchetto su un sistema devono essere presenti all'interno di / opt /, inclusi i file che devono essere copiati in / etc / opt / e / var / opt / nonché le directory riservate in / opt.

Le restrizioni minori sulle distribuzioni che utilizzano / opt sono necessarie perché sono possibili conflitti tra software installato nella distribuzione e installato localmente, specialmente nel caso di percorsi fissi trovati in alcuni software binari.

La struttura delle directory sottostanti / opt / è lasciata al packager del software, sebbene si raccomanda che i pacchetti siano installati in / opt // e seguano una struttura simile alle linee guida per / opt / package. Un motivo valido per divergere da questa struttura è per i pacchetti di supporto che possono avere file installati in / opt // lib o / opt // bin.

Si dovrebbe usare solo /usr/local/shareper file che non sono specifici di una particolare architettura / versione del sistema operativo.

Dopodiché tocca a te se distribuire i file tra i sottodirectory esistenti di /usr/localo se crei una nuova directory dedicata in /usr/local(ma quest'ultima non esisterà già sull'eseguibile PATH, il LD_LIBRARY_PATH, né il MANPATH).

Dai un'occhiata a FHS

Fino a quando non /optdivenne comune, il solito posto era /usr/local/lib/<package>.

Quando si installano applicazioni locali, ci sono più opzioni a seconda di come si desidera accedere e aggiornare. Inoltre, va notato che alcuni metodi assomigliano più al sistema che hai già e alcuni sono più ad-hoc. Suggerirei che le soluzioni "migliori" sono quelle che semplificano la gestione delle cose.

Ho diviso questa risposta in base al numero di pacchetti per cui effettuare installazioni personalizzate. La divisione si basa sulle mie esperienze. Queste esperienze pesano il tempo necessario per gestire i pacchetti e i rischi di incasinare qualcosa. Non intendo che ho la conoscenza di standard comuni, ma intendo questo come un punto di riferimento da considerare quando si prende la decisione.

Solo per pochi pacchetti , metterei i pacchetti aggiuntivi /opt, in modo che siano lontani da tutto il resto in modo che nulla possa rovinarli e che possano rovinare qualcos'altro. Questo è il metodo che uso sul mio NAS. Questo metodo, tuttavia, mantiene i binari lontani dal tuo PERCORSO, quindi dovrai aggiungerli manualmente. Funziona bene se ci sono solo pochi pacchetti da installare, ma diventa un bel casino se ce ne sono molti.

L'aggiornamento qui è abbastanza semplice poiché si sovrascrive semplicemente la directory.

Professionisti:

• semplice
• veloce da configurare
• nessuna possibilità di influenzare altre parti del sistema
• disinstallare è facile come installare

Contro:

• Diventa piuttosto noioso se il numero di pacchetti da installare è grande
• Sembra PATHdisordinato

Per più di alcuni pacchetti , consiglierei di usare il /usr/local/<your package>sym-linking e l'eseguibile da /usr/local/bino a /usr/local/sbinseconda se hai bisogno dei privilegi di root. Questo ti evita di cambiare il tuo PERCORSO ogni volta che viene aggiunto qualcosa di nuovo in modo che il PERCORSO rimanga pulito. Questo è il metodo che uso sul mio laptop Arch per tutti i pacchetti non pacman e AUR.

L'aggiornamento avviene sovrascrivendo la directory del pacchetto e controllando che il collegamento simbolico sia ancora valido e risolvendolo se non lo è.

Professionisti

• Non fa PATHcasino
• Non influisce sul sistema di base
• Ancora molto semplice rimuovere tutti i componenti aggiuntivi e tornare a un sistema di base pulito

Contro:

• Più lavoro da configurare
• La rimozione di un solo pacchetto richiede alcune ricerche

Per molti pacchetti . Poiché non è questo il caso che desideri, lo terrò breve. Suggerirei dividere il pacchetto in bin, lib, share, ecc e la loro installazione a /usr/local. Questo per mantenere pulita la struttura. Puoi anche specificare chi può scrivere dove e altro. Ad esempio, non vuoi che persone diverse da root modifichino l'eseguibile.

Qui l'aggiornamento diventa un po 'più complicato in quanto è necessario scrivere in più di una singola directory. Consiglierei di imballare il tutto e lasciare che il gestore dei pacchetti gestisca il resto.

La condivisione

La sharedirectory stessa è per l'architettura file indipendenti come indicato nella Faheem di collegamento ei file dipendenti architettura dovrebbe andare a lib, lib32, lib64, etc.