Onde devo colocar o software que eu me compilar?


Respostas:


90

Regra geral, pelo menos nos sistemas com sabor Debian:

  • /usr/localpara o material que é -ie "de todo o sistema" /usr/localtende a ser no padrão de um distro $PATH, e segue uma hierarquia padrão diretório UNIX com /usr/local/bin, /usr/local/lib, etc.

  • /optpara coisas que você não confia para fazer todo o sistema, com per-app prefixos-ie /opt/firefox-3.6.8, /opt/mono-2.6.7e assim por diante. O material aqui requer um gerenciamento mais cuidadoso, mas também é menos provável que interrompa o sistema - e é mais fácil de remover, pois você exclui a pasta e ela desapareceu.


Curiosamente, muitos programas / aplicativos sugerem automaticamente a instalação /optse você sudoinstalar.
HongboZhu 10/09

50

Se você realmente não quer que isso interfira, não o coloque em lugar algum $PATH.

Se você quiser $PATH, pelo menos, certifique-se de não instalar o /usr/local. Descobri que muitos softwares parecem lá, mesmo que estejam instalados pela distribuição /usr.

Minha maneira favorita de instalar software compilado sob encomenda está no meu $HOMEdiretório. Dessa forma, você não precisa usar sudonada e é muito bem separado do resto do seu sistema. Por exemplo:

mkdir ~/stage
./configure --prefix=/home/username/stage && make && make install

E se você quiser, poderá adicionar /home/username/stage/binao seu $PATH.


1
Definitivamente, usar o diretório inicial é a melhor opção. IMO.
Bitek

1
+1 Concordado. Eu gosto de ~ / sbin para scripts bash / ruby ​​/ python e ~ / opt / ... para instalações compiladas, com aliases em ~ / bin.
Kris

4
+1 para usar seu diretório pessoal, pois simplifica as coisas; -1 para a sugestão de evitar $ PATH - existem diretórios "reservados para instalações locais" de acordo com os padrões (por exemplo, /usr/local).
Riccardo Murri 11/08

1
Minha sugestão para evitar / usr / local foi baseada no desejo (um tanto vago) do pôster original de não interferir no software empacotado. Como há muitos softwares empacotados que "ajudarão" procurando em / usr / local ou em $ PATH, achei que isso é considerado uma interferência. Mas isso realmente depende das necessidades e objetivos individuais de uma pessoa. / usr / local pode ser uma escolha perfeitamente adequada em muitas situações.
Sandy

ninguém percebeu o completo mal-entendido da letra "s" no comentário # 2. que deve ser excluído
meffect 5/17

20

A ESF diz colocá-lo em / usr / local onde as distribuições não deveriam estar tocando. /usr/local/binpara os binários /usr/local/srcda fonte e /usr/local/libdas bibliotecas. Consulte a especificação da FHS para obter mais informações


E a configuração? Digamos que eu instalei o MySQL sem usar o gerenciador de pacotes, ainda devo usar /etc/mysqlpara a configuração?
Hubro 01/07

Eu só notei há uma /usr/local/etcpasta por padrão, eu acho que eu deveria usar isso ... :-)
Hubro

10

Na maioria das vezes, gosto de colocar minhas próprias coisas compiladas /opt. É uma espécie de lugar pseudo-padrão. Você também pode considerar /usr/local, mas eu prefiro manter meu material 100% isolado.


1
as distros tendem a colocar algumas coisas em / opt (geralmente pacotes proprietários) / opt não diz que a distro não pode tocá-la. no entanto, diz que cerca de / usr / local
xenoterracide

1
Eu nunca vi uma distro colocar coisas /opt, no entanto, eu já vi muitas vezes onde /usr/localestá cheio de lixo que vem da distro
Scott Anderson

distro Eu uso como colocar java em / opt Eu já vi acrobat reader lá também. se eles estão colocando coisas em / usr / local, eles ignoram o FHS, que diz que precisa ser protegido contra sobrescrito nas atualizações do sistema.
Xenoterracide

Para cada um deles, eu acho. A ESF é legal, mas acho que às vezes é ignorada.
Scott Anderson

As únicas coisas em que eu já vi pacotes de distribuição /usr/localforam hierarquias de diretórios paralelas às da árvore padrão e talvez indexar arquivos para coisas como TeX.
Phil Miller

9

Coloque-os para /usr/local/src.

O que faço é extrair a fonte neste diretório. Isso criará um caminho como

/usr/local/src/postgresql-8.3.7

Então eu crio um link simbólico para ele:

/usr/local/src # ln -s  postgresql-8.3.7 postgresql

Faça todo o seu edifício /usr/local/src/postgresql.

Fazer as coisas dessa maneira ajuda quando você precisa alternar entre versões e documentos que versão está usando.


1
+1 para indicar sua lógica e como o OP pode aplicá-la, incluindo versão.
samt

6

Isso me lembra que eu preciso usar o checkinstall com mais frequência! Dessa forma, eu apenas faço o de sempre

 ./configure
 make

Seguido por

 sudo checkinstall

para criar um arquivo .deb ...


2
Não responde a pergunta.
JBentley 15/02

5

Se houver possibilidade - sugiro compilar seu software e criar o pacote FC (acredito que ele esteja usando o yum para instalar pacotes de software). Em seguida, você pode instalar esse pacote do seu próprio software compilado e removê-lo sem bagunçar todo o sistema.


5

Se você deseja instalar e remover facilmente vários aplicativos criados por você, pode usar o Stow como um gerenciador de pacotes simples.


5

Pelo FHS , /usr/local/é usado para aplicativos compilados a partir da fonte, enquanto /opt/é usado para aplicativos de terceiros não suportados pelo fornecedor do sistema operacional.


4

Duas coisas que eu recomendaria:

Em todo o sistema: use stow e instale em / usr / local / stow / package-version. Então você pode alternar facilmente entre as versões.

Na minha casa, ou se eu não tiver permissões de gravação / usr / local, instalo pessoalmente programas em ~ / .local, sugerido pelo padrão XDG .

Você também pode usar o stow localmente, embora nunca o tenha feito :)


3

Eu tenho uma configuração um pouco diferente da maioria das pessoas, porque desenvolvo muito. Eu tenho um diretório / home / jackson / bin / no qual eu instalo o material e editei meu arquivo .bashrc adicionando isto:

export PATH=/home/jackson/bin/bin::$PATH
export LD_LIBRARY_PATH=/home/jackson/bin/lib:$LD_LIBRARY_PATH
export PKG_CONFIG_PATH=/home/jackson/bin/lib/pkgconfig:$PKG_CONFIG_PATH

Eu não faria isso por tudo, mas é bom durante o desenvolvimento.


3

Na verdade, não é tão difícil criar deb ou rpm a partir de um tarball de origem. Dessa forma, você pode usar os recursos do gerenciador de pacotes da sua distribuição para manter seu sistema limpo. É isso que faço na maioria das vezes: basta criar um pouco de rotação.


2

se você estiver compilando um aplicativo, poderá adicionar o caminho dos executáveis ​​na variável env PATH. isso não afetará outros usuários.


Eu me pergunto por que os votos negativos? +1 para "equilibrar"
phunehehe 11/08/10

Também estou me perguntando por que :-). Eu usei a mesma solução para usar o cscope onde não tenho permissões de instalação.
Hemant

@phunehehe Provavelmente porque nem tenta responder à pergunta. A pergunta pergunta onde colocar o software. Esta resposta fornece uma dica sobre o que você poderia fazer depois de colocá-lo em algum lugar. Pode ser melhorado, dando algumas sugestões sobre quais pastas usar.
JBentley 15/02

2

Sempre existe a opção de "colocá-lo onde ele pertence", mas escrever uma rpm simples, primeiro.


1

Se você deseja que seu aplicativo esteja disponível para todos os usuários do sistema e tenha as permissões necessárias, use / opt. Se você deseja que o aplicativo esteja disponível apenas para você (e raiz), use / home / nome de usuário


0

A maneira mais fácil de fazer isso é pegar o pacote fonte ( .src.rpmpara RPMites), descompactá-lo, hackear a nova fonte / configuração / o que quer que seja, alterar a versão adequadamente e compilar. A instalação disso torna seu gerenciador de pacotes ciente do novo pacote, permite considerá-lo para dependências e desinstalar / atualizar.

Esta é uma tarefa árdua na primeira vez, mas se uma nova versão (ou algum patch crítico) for lançada, será mais fácil atualizar. Outro benefício é que você pode criar seu próprio repositório com software local, para ser compartilhado, por exemplo, pelas máquinas em um laboratório.


0

Escreva um RPM, não é difícil, tem diretrizes sobre onde colocar as coisas e facilita a desinstalação.

Se você fizer isso, instale os arquivos abaixo /usre não abaixo /usr/local, como todos os outros arquivos enviados pelo sistema de empacotamento.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.