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

Question

De acordo com o Padrão de Hierarquia do Sistema de Arquivos , /opt é para "a instalação de adicionar -em pacotes de software de aplicação ". /usr/local é "para uso pelo 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 ser instalado em /usr/local ou /opt sem nenhuma rima ou motivo específico para o que eles escolheram.

Existe alguma diferença que eu sinto falta ou ambos fazem a mesma coisa, mas existem por razões históricas?

    

Answer 1

Embora ambos sejam projetados para conter arquivos que não pertencem ao sistema operacional, /opt e /usr/local não devem conter o mesmo conjunto de arquivos.

/usr/local é um local para instalar arquivos criados pelo administrador, geralmente usando o comando make (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 (por exemplo, /usr/bin/foo é parte do sistema operacional, enquanto /usr/local/bin/foo é uma alternativa local).

Todos os arquivos em /usr são compartilháveis entre instâncias do sistema operacional, embora isso raramente seja feito com o Linux. Essa é uma parte em que o FHS é ligeiramente autocontraditório, pois /usr é definido como somente leitura, mas /usr/local/bin precisa ser de leitura / gravação para que a instalação local do software seja bem-sucedida. O padrão do sistema de arquivos SVR4, que era a principal fonte de inspiração da FHS, recomenda evitar /usr/local e usar /opt/local para superar esse problema.

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

Por outro lado, /opt é um diretório para a instalação de pacotes não incluídos (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. Ao contrário de /usr/local stuff, esses pacotes seguem as convenções de diretório (ou pelo menos deveriam). Por exemplo, someapp seria instalado em /opt/someapp , com um de seus comandos sendo /opt/someapp/bin/foo , seu arquivo de configuração estaria em /etc/opt/someapp/foo.conf e seus arquivos de log em /var/opt/someapp/logs/foo.access .

    

Answer 2

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

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

/opt , por 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".

    

Answer 3

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

    

Answer 4

Para mim, pessoalmente, é o que Bill disse no link do @fildr:

On a development system, or a sandbox, having an /opt directory where you can just toss things and see if they work makes a whole lot of sense. I know I'm not going to go through the effort of packaging things myself to try them out. If the app doesn't work out, you can simply rm the /opt/mytestapp directory and that application is history. Packaging may make sense when you're running a large deployment (there are times when I do package apps), but lots of times, it's nice to toss stuff in /opt.

Infelizmente, a maioria dos scripts make install envia arquivos para /usr/local em vez de apenas criar um symlink: - /

    

Answer 5

Primeiro, não acho que haja uma resposta estrita; diferente os administradores terão opiniões diferentes, de acordo com fundo. Historicamente, /usr/local veio primeiro; foi o convenção em Berkley, IIRC. Em um ponto durante o desenvolvimento do System V, se não me engano (isso é tudo um longo tempo atrás, e eu não fiz anotações), houve uma decisão ou um desejo de poder montar /usr somente leitura, o que significa que você não foi possível adicionar novo software a ele; pode ter sido por isso que /opt foi inventado. Acontece que havia tanta coisa existente software que escreveu para /usr que essa ideia nunca realmente saiu do chão.

Minha preferência pessoal é /opt , com um subdiretório separado para cada produto; isso faz com que a remoção de um produto seja um caso simples de %código%. Mas se todo o seu software é instalado através de um bom gerenciador de pacotes, não importa, e se o software que você instalar não obedece estritamente a estas convenções, e escreve configurações e tal em algum lugar em rm -fr , ele não importa também, embora pelas razões opostas.

    

Answer 6

Eu tenho uma visão um pouco diferente sobre essa questão.
Enquanto tudo em jlliagre 's answer está correto, a aplicação prática para mim, ao implantar software em um cluster, se resume a variáveis de ambiente padrão e reutilização padrão de libs.

Basta colocar - /usr/local e todos os seus diretórios filhos no env vars apropriado, como PATH e MANPATH e /usr/local/lib{,64} no ldconfig ( /etc/ld.so.conf.d/ ).

/opt/ OTOH não é - o que é vantajoso ao exigir que múltiplas versões ou pacotes conflitantes coexistam no sistema, mas requer algum tipo de gerenciamento de ambiente (por exemplo, ambiente-módulos ou coleções de software ), e desvantajoso por potencialmente" desperdiçar " espaço de armazenamento duplicando as bibliotecas compartilhadas, já que cada instalação em /opt pode ser completamente independente.

Para que a natureza compartilhada de /usr/local funcione, presume-se que, por exemplo, binários são instalados diretamente em /usr/local/bin (e man pages para apropriar /usr/local/share/man/... ) ao invés de /usr/local/app/{bin,share/man,...} etc.