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

404

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?

Patches
fonte
3
Meu entendimento é que /usr/localé uma versão local do /usrsistema de arquivos, enquanto que /opté um espaço reservado para coisas diversas.
yasouser
5
Pergunta semelhante no Ask Ubuntu , superuser
kenchew
Fora do tópico por razões históricas: Entendendo a divisão bin, sbin, usr / bin, usr / sbin .
Alexey

Respostas:

357

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.

jlliagre
fonte
53
/ usr / local, para software próprio, interno, compilado e mantido. / opt é para a área de instalação de pacotes binários / aplicativos não próprios, externos e pré-empacotados. Hmmm ... não temos C: \ Program Files para tudo ;-)
Nikhil Mulley
2
"Por outro lado, / opt é um diretório onde instalar pacotes desagrupados" O que os pacotes 'desagrupados' significam aqui?
Kevin Wheeler
1
@KevinWheeler Isso é explicado na próxima frase. Desagrupado significa pacotes que não fazem parte da distribuição do sistema operacional, mas são fornecidos por uma fonte independente.
Jlliagre
2
@jlliagre the centos docs * state "Por exemplo, se o diretório / usr / for montado como um compartilhamento NFS somente leitura de um host remoto, ainda é possível instalar um pacote ou programa no diretório / usr / local /" Não sei quem está certo, mas isso parece estar em contradição com a sua afirmação sobre uma área em que a ESF é fraca. (* source centos.org/docs/5/html/5.1/Deployment_Guide/… )
Kevin Wheeler
1
@KevinWheeler Essa é precisamente a fraqueza à qual estou me referindo. Instalar um pacote ou programa em um diretório remoto somente leitura é impossível. A solução alternativa seria montar um sistema de arquivos local em / usr / local, mas isso parece mais um trabalho improvisado do que algo projetado adequadamente.
Jlliagre 6/12/15
84

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".

Deixe me ser
fonte
12
Discordo do seu ponto de vista monolítico. O padrão FHS diz que os pacotes instalados nos subdiretórios / opt devem ter seus arquivos específicos do host fora de / opt, respectivamente em / etc / opt / package para arquivos de configuração e / var / opt / package para logs, spool e similares. / opt está realmente mais próximo das regras de implantação do unix do que / usr / local, que coloca tudo em um diretório que deve ser somente leitura, mas não pode ser por razões óbvias.
Jlliagre #
5
Claro, se eu estivesse fazendo um pacote opt e desejasse reivindicar a conformidade com a ESF. Caso contrário, o padrão é mais o que você chamaria de "diretrizes". Só porque o NetBeans não usa / etc / opt / netbeans não me impede de colocá-lo em / opt para todo o sistema ou $ HOME / .local / opt para um usuário único.
JLA
1
@jla Suponho que seu último comentário foi direcionado a mim, portanto, use @ xxx ao responder a outra pessoa que o OP ou o autor da resposta. Sobre o / etc / opt, a ESF não diz que é um local recomendado (como orientação), mas um local obrigatório. Você ou o desenvolvedor do Netbeans é livre para violar esse padrão, pois não há autoridade para aplicá-lo, mas não diga que fazer errado é o caminho a seguir. É apenas um infeliz mal-entendido ou violação deliberada.
Jlliagre
8
@jlliagre Como administrador do meu sistema, a ESF é um conjunto de diretrizes. O diretório / opt é o local bem estabelecido e de bom senso para colocar o software monolítico / opt / <package> ou / opt / <provider>. Quando instalo um pacote que deseja usar <package | provider> / all / data / required / to / support, ele entra em opt / mesmo que o provedor não siga todos os detalhes do FHS mais recente. Posso enviar um e-mail ou relatar um bug, mas não vou colocar esse pacote monolítico em outro lugar para me sentir melhor sobre a ESF no meu sistema.
JLA
1
@ jlliagre Instalei muitas coisas em / opt e nenhum arquivo foi criado em / etc / opt. Devemos?
precisa saber é
18

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 .

philfr
fonte
9
Oh céus. Eu não quis me arrastar para uma "guerra santa".
Patches
13

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: - /

pepoluan
fonte
2
Qual seria o objetivo? Se você deseja fazer o link simbólico de qualquer maneira, por que não colocar o arquivo original em primeiro lugar?
Let_Me_Be
8
Apenas para comentar sobre o make installdestino que envia os arquivos /usr/local; esta funcionalidade é facilmente alterável pela passagem de um --prefix=parâmetro de linha de comando para o ./configureroteiro, ou se não houver nenhum ./configurescript, você pode passar um parâmetro para o makealvo assim: make --prefix=/usr install.
Sean C.
3
/ Opt é um diretório padrão incluído no $ PATH? Eu sei / usr / local é.
18711 LawrenceC
5
@Let_Me_Be O benefício seria que é muito fácil manter versões mais antigas. Digamos que eu tenha 2 versões do 'foo', localizadas em /opt/foo-1.1e /opt/foo-1.2. Quando eu atualizo, o foolink simbólico /usr/local/binaponta para foo-1.2. Se, por algum motivo, eu precisar reverter, basta substituir o link simbólico por um que aponte para foo-1.1. Se rm -rf /opt/foo-1.1a versão 1.2 estiver correta após várias semanas, uma rápida removerá a versão mais antiga de forma rápida e limpa.
pepoluan
7
@ultrasawblade não, não é. e nunca deveria ser. afinal, de acordo com a ESF, / opt deve ser subdividido em subdiretórios com o nome da embalagem. colocar tudo no PATH é uma maneira infalível de desastre. em vez disso, os aplicativos devem instalar-se em / opt e vincular seus programas invocados pelo usuário em / usr / local / bin (ou sbin).
pepoluan
11

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.

James Kanze
fonte
1
"" "todo o seu software é instalado através de um bom gerenciador de pacotes" "" que é impossível, a menos que você use apenas o software usado com freqüência.
Pacerier
1
@Pacerier é possível, depende da distro que você está usando. Qualquer que seja o software, ele provavelmente está no Arch User Repository e, se não estiver, um PKGBUILD é relativamente fácil de escrever.
#
9

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.

Dani_l
fonte