Qual é a diferença entre / opt e / usr / local?

De acordo com o padrão de hierarquia do sistema de arquivos , /opté para "a instalação de pacotes de aplicativos complementares". /usr/localé "para uso do administrador do sistema ao instalar o software localmente". Esses casos de uso parecem bastante semelhantes. O software não incluído nas distribuições geralmente é configurado por padrão para instalar em uma /usr/localou /optsem rima ou motivo específico para a escolha deles.

Há alguma diferença que estou perdendo ou as duas fazem a mesma coisa, mas existem por razões históricas?

Embora os dois sejam projetados para conter arquivos que não pertencem ao sistema operacional /opte /usr/localnão pretendam conter o mesmo conjunto de arquivos.

/usr/localé um local para instalar arquivos criados pelo administrador, geralmente usando o makecomando (por exemplo, ./configure; make; make install). A idéia é evitar conflitos com arquivos que fazem parte do sistema operacional, que seriam sobrescritos ou sobrescreveriam os locais locais (por exemplo, /usr/bin/foofaz parte do sistema operacional e /usr/local/bin/fooé uma alternativa local).

Todos os arquivos abaixo /usrsão compartilháveis ​​entre instâncias do SO, embora isso raramente seja feito com o Linux. Essa é uma parte em que o ESF é um pouco autocontraditório, como /usrdefinido como somente leitura, mas /usr/local/binprecisa ser lido / gravado para que a instalação local do software seja bem-sucedida. O padrão do sistema de arquivos SVR4, que foi a principal fonte de inspiração da ESF, recomenda evitar /usr/locale usar /opt/localpara superar esse problema.

/usr/localé um legado do BSD original. Naquela época, o código fonte dos /usr/bincomandos do SO estava em /usr/src/bine /usr/src/usr.bin, enquanto a fonte dos comandos desenvolvidos localmente estava em /usr/local/srce seus binários em /usr/local/bin. Não havia noção de embalagem (tarballs externos).

Por outro lado, /opté um diretório para a instalação de pacotes desagregados (ou seja, pacotes que não fazem parte da distribuição do sistema operacional, mas são fornecidos por uma fonte independente), cada um em seu próprio subdiretório. Eles já são pacotes completos construídos, fornecidos por um distribuidor independente de software de terceiros. Diferentemente das /usr/localcoisas, esses pacotes seguem as convenções de diretório (ou pelo menos deveriam). Por exemplo, someappseria instalado /opt/someapp, com um de seus comandos /opt/someapp/bin/foo, seu arquivo de configuração /etc/opt/someapp/foo.conf, e seus arquivos de log /var/opt/someapp/logs/foo.access.

A diferença básica é que o /usr/localsoftware não é gerenciado pelo empacotador do sistema, mas ainda segue as regras de implantação padrão do unix.

É por isso que você tem /usr/local/bin, /usr/local/sbin /usr/local/includeetc ...

/optpor outro lado, é para software que não segue isso e é implantado de maneira monolítica. Isso geralmente inclui software comercial e / ou de plataforma cruzada que é empacotado no estilo "Windows".

Eles são realmente muito semelhantes, e o uso de um ou de outro é mais uma questão de opinião. O diário Linux teve essa discussão de ponto / contraponto sobre esse tópico exato aqui .

Para mim, pessoalmente, é o que Bill disse no link da @ philfr:

Em um sistema de desenvolvimento ou em uma caixa de areia, ter um diretório / opt no qual você pode simplesmente lançar as coisas e ver se elas funcionam faz muito sentido. Eu sei que não vou passar pelo esforço de empacotar as coisas para experimentá-las. Se o aplicativo não funcionar, você pode simplesmente rm o diretório / opt / mytestapp e esse aplicativo é histórico. O empacotamento pode fazer sentido quando você estiver executando uma implantação grande (há momentos em que eu faço pacotes de aplicativos), mas muitas vezes é bom lançar coisas no / opt.

Infelizmente, a maioria dos make installscripts envia arquivos para o arquivo em /usr/localvez de apenas fazer um link simbólico: - /

Primeiro, não acho que exista uma resposta estrita; diferentes administradores terão opiniões diferentes, de acordo com o seu histórico. Historicamente, /usr/localveio primeiro; foi a convenção em Berkley, IIRC. Em um ponto durante o desenvolvimento do Sistema V, se não me engano (isso já faz muito tempo, e eu não fiz anotações), houve uma decisão ou um desejo de poder montar /usrsomente leitura, o que significava que você não poderia adicionar um novo software a ele; pode ter sido por isso que /opt foi inventado. Por acaso, havia tanto software existente que gravou /usrque essa ideia nunca realmente decolou.

Minha preferência pessoal é /opt, com um subdiretório separado para cada produto; isso torna a remoção de um produto um simples caso de rm -fr. Mas se todo o seu software estiver instalado por meio de um bom gerenciador de pacotes, isso não importa, e se o software que você instala não obedece estritamente a essas convenções e grava configurações e outros itens em algum lugar abaixo /usr, também não importa. pelas razões opostas.

Tenho uma opinião um pouco diferente sobre esse assunto.
Enquanto tudo em jlliagre 's resposta está correta, a aplicação prática para mim, ao implantar o software em um cluster, se resume a variáveis de ambiente padrão e reutilização padrão de libs.

Simplificando - /usr/locale todos os seus diretórios filhos estão nos ambientes apropriados, como PATHe MANPATH, e /usr/local/lib{,64}estão no ldconfig ( /etc/ld.so.conf.d/).

/opt/O OTOH não é - o que é vantajoso ao exigir a coexistência de várias versões ou pacotes conflitantes no sistema, mas requer algum tipo de gerenciamento de ambiente (por exemplo, módulos de ambiente ou coleções de software ) e é desvantajoso, pois potencialmente "desperdiçaria" "espaço de armazenamento duplicando bibliotecas compartilhadas, pois cada instalação /optpode ser completamente independente.

Para que a natureza compartilhada /usr/localfuncione, presume-se que, por exemplo, os binários sejam instalados diretamente /usr/local/bin(e as páginas de manual sejam apropriadas /usr/local/share/man/...) e não /usr/local/app/{bin,share/man,...}etc.