Qual è la differenza tra / opt e / usr / local?

Secondo il Filesystem Hierarchy Standard , /optè per "l'installazione di pacchetti software applicativi aggiuntivi". /usr/localè "per l'uso da parte dell'amministratore di sistema durante l'installazione del software in locale". Questi casi d'uso sembrano abbastanza simili. Il software non incluso con le distribuzioni di solito è configurato per impostazione predefinita per l'installazione in /usr/localo /optsenza una particolare rima o motivo per cui hanno scelto.

C'è qualche differenza che mi manca o entrambi fanno la stessa cosa, ma esistono per ragioni storiche?

Mentre entrambi sono progettati per contenere file non appartenenti al sistema operativo /opte /usr/localnon sono destinati a contenere lo stesso set di file.

/usr/localè un luogo in cui installare i file creati dall'amministratore, in genere utilizzando il makecomando (ad esempio, ./configure; make; make install). L'idea è quella di evitare scontri con i file che fanno parte del sistema operativo, che verrebbero sovrascritti o sovrascriverebbero quelli locali (ad esempio, /usr/bin/foofa parte del sistema operativo mentre /usr/local/bin/fooè un'alternativa locale).

Tutti i file sottostanti /usrsono condivisibili tra istanze del sistema operativo, sebbene ciò avvenga raramente con Linux. Questa è una parte in cui l'FHS è leggermente contraddittorio, poiché /usrè definito di sola lettura, ma /usr/local/bindeve essere letto e scritto per consentire l'installazione locale del software. Lo standard del file system SVR4, che è stata la principale fonte di ispirazione dell'FHS, raccomanda di evitare /usr/locale utilizzare /opt/localinvece per superare questo problema.

/usr/localè un'eredità del BSD originale. A quel tempo, era presente il codice sorgente dei /usr/bincomandi del sistema operativo /usr/src/bine /usr/src/usr.bin, mentre era presente la fonte dei comandi sviluppati localmente /usr/local/srce i relativi file binari /usr/local/bin. Non c'era idea di imballaggi (al di fuori dei tarball).

D'altra parte, /optè una directory per l'installazione di pacchetti disaggregati (ovvero pacchetti che non fanno parte della distribuzione del sistema operativo, ma forniti da una fonte indipendente), ognuno nella propria sottodirectory. Sono già costruiti interi pacchetti forniti da un distributore di software di terze parti indipendente. A differenza delle /usr/localcose, questi pacchetti seguono le convenzioni della directory (o almeno dovrebbero). Ad esempio, someappverrebbe installato in /opt/someapp, con uno dei suoi comandi in essere /opt/someapp/bin/foo, il suo file di configurazione sarebbe in /etc/opt/someapp/foo.conf, e i suoi file di log in /var/opt/someapp/logs/foo.access.

La differenza di base è che il /usr/localsoftware non è gestito dal system packager, ma continua a seguire le regole di distribuzione unix standard.

Ecco perché hai /usr/local/bin, /usr/local/sbin /usr/local/includeecc ...

/optd'altra parte è per software che non segue questo e viene distribuito in modo monolitico. Questo di solito include software commerciale e / o multipiattaforma confezionato in stile "Windows".

Sono davvero molto simili e l'uso dell'uno o dell'altro è più una questione di opinione. Il diario di Linux ha avuto questa discussione punto / contrappunto su questo argomento esatto qui .

Per me, personalmente, è quello che Bill ha detto nel link di @ philfr:

Su un sistema di sviluppo o su una sandbox, avere una directory / opt in cui puoi semplicemente lanciare le cose e vedere se funzionano ha molto senso. So che non passerò attraverso lo sforzo di impacchettare le cose per provarle. Se l'app non funziona, puoi semplicemente rm la directory / opt / mytestapp e quell'applicazione è cronologia. Il packaging può avere senso quando si esegue una distribuzione di grandi dimensioni (ci sono momenti in cui eseguo pacchetti di app), ma molte volte è bello gettare / optare.

Sfortunatamente, la maggior parte degli make installscript inserisce i file /usr/localinvece di creare un link simbolico lì: - /

Innanzitutto, non penso che ci sia una risposta rigorosa; amministratori diversi avranno opinioni diverse, in base al loro background. Storicamente, è /usr/localvenuto prima; era la convention di Berkley, IIRC. Ad un certo punto durante lo sviluppo di System V, se non sbaglio (è successo tanto tempo fa e non ho preso appunti), c'era una decisione o un desiderio di poter montare /usrin sola lettura, il che significa che non è possibile aggiungere nuovo software ad esso; quello potrebbe essere stato il motivo per cui è /opt stato inventato. A quanto pare, c'erano così tanti software esistenti che hanno scritto a /usrquell'idea che non è mai veramente decollata.

La mia preferenza personale è /opt, con una sottodirectory separata per ciascun prodotto; questo rende la rimozione di un prodotto un semplice caso di rm -fr. Ma se tutto il tuo software viene installato tramite un buon gestore di pacchetti, non importa, e se il software che installi non obbedisce rigorosamente a queste convenzioni e scrive configurazioni e simili da qualche parte sotto /usr, non importa neanche, anche se per le ragioni opposte.

Ho una visione leggermente diversa di questo problema.
Mentre tutto in jlliagre 's risposta è corretta, l'applicazione pratica per me, durante la distribuzione del software in un cluster, si riduce a variabili d'ambiente di default e il riutilizzo predefinito di librerie.

In parole povere - /usr/locale tutte le sue dir figlio sono negli ambienti appropriati come PATHe MANPATH, e /usr/local/lib{,64}sono in ldconfig's ( /etc/ld.so.conf.d/).

/opt/OTOH non lo è - il che è vantaggioso quando si richiedono la coesistenza di più versioni o pacchetti in conflitto nel sistema, ma richiede una sorta di gestione dell'ambiente (ad es. Moduli ambientali o raccolte di software ) e svantaggioso in quanto potenzialmente "spreca" "spazio di archiviazione duplicando le librerie condivise, poiché ogni installazione /optpuò essere completamente autonoma.

Affinché la natura condivisa /usr/localfunzioni, si presume che, ad esempio, i binari siano installati direttamente su /usr/local/bin(e le pagine man siano appropriate /usr/local/share/man/...) piuttosto che /usr/local/app/{bin,share/man,...}ecc.