Eu acho / opt é mais padrão nesse tipo de contexto. Consulte a seção relevante no Padrão de hierarquia do sistema de arquivos .
Quais são os "padrões" - devo colocar a aplicação (não apenas distribuição binária, mas toda) em / usr / local ou / usr / local / share.
Por exemplo, scala ou weka - contém exemplos, binários, bibliotecas e assim por diante. Então seria
/usr/local/scala-2.9.1
ou
/usr/local/share/scala-2.9.1
Desde que eu sou o único administrador, não é um grande problema para mim, mas eu prefiro usar algo que é amplamente usado, não com meus próprios costumes.
Importante: não estou perguntando sobre casos, onde você deve dividir o aplicativo em / usr / local / bin, / usr / local / lib e assim por diante. Em vez disso, estou perguntando sobre o caso em que você precisa manter um diretório principal para todo o aplicativo.
Eu acho / opt é mais padrão nesse tipo de contexto. Consulte a seção relevante no Padrão de hierarquia do sistema de arquivos .
Você só deve usar / usr / local / share para arquivos que não são específicos de uma arquitetura / versão específica do sistema operacional.
Depois disso, depende de você distribuir os arquivos entre os subdiretórios existentes de / usr / local ou se você criar um novo diretório dedicado em / usr / local (mas o último já não existirá no PATH executável, LD_LIBRARY_PATH, nem o MANPATH.
Veja a FHS
Até que /opt se tornasse comum, o local habitual era /usr/local/lib/<package> .
Ao instalar aplicativos locais, existem várias opções dependendo de como você deseja acessar e atualizar. Também deve ser notado que alguns métodos se parecem mais com o sistema que você já tem e alguns são mais ad-hoc. Eu sugeriria que as "melhores" soluções são as que facilitam o gerenciamento.
Eu dividi essa resposta com base no número de pacotes para instalação personalizada. A divisão é baseada em minhas próprias experiências. Essas experiências pesam o tempo que leva para gerenciar os pacotes e os riscos de bagunçar alguma coisa. Não quero dizer que tenho o conhecimento de padrões comuns, mas quero dizer isso como um ponto de referência a ser observado ao tomar a decisão.
Para apenas alguns pacotes , eu colocaria pacotes de complemento em /opt , onde eles estão fora do caminho de todo o resto, então nada pode estragar tudo e eles podem estragar outra coisa acima. Este é o método que eu uso no meu NAS. No entanto, esse método mantém os binários fora de seu PATH, portanto, você precisará adicioná-los manualmente. Isso funciona bem se houver apenas alguns pacotes para instalar, mas se tornar uma bagunça se houver muitos.
A atualização aqui é bem fácil, já que você simplesmente sobrescreve o diretório.
Prós:
Contras:
PATH pareça confuso Para mais do que alguns pacotes , eu recomendaria usar o /usr/local/<your package> e vincular sym o executável de /usr/local/bin ou /usr/local/sbin dependendo se você precisa de privilégios de root. Isso evita que você altere seu PATH toda vez que algo novo for adicionado, para que o PATH fique limpo. Este é o método que eu uso no meu laptop Arch para todos os pacotes não-pacman e pacotes AUR.
A atualização é feita sobrescrevendo o diretório do pacote e verificando se o link simbólico ainda é válido e corrigindo se não está.
Prós
PATH bagunçado Contras:
Para muitos pacotes . Como este não é o caso que você está querendo, vou mantê-lo breve. Eu recomendaria dividir o pacote em bin , lib , share , etc. e instalá-los em /usr/local . Isso é para manter a estrutura limpa. Você também pode especificar quem pode escrever onde e mais. Por exemplo, você não quer que outras pessoas além do root modifiquem o executável.
Aqui a atualização fica um pouco mais complicada, já que você precisa escrever para mais de um diretório. Eu recomendaria empacotar tudo e deixar o gerenciador de pacotes cuidar do resto.
A partilha
O diretório share em si é para arquivos independentes de arquitetura, conforme observado no link e os arquivos dependentes da arquitetura devem ir para lib , lib32 , lib64 , etc.