ti-enxame.com

Onde devo colocar o software que eu me compilar?

Preciso compilar algum software na minha máquina Fedora. Qual é o melhor lugar para colocá-lo para não interferir no software empacotado?

130
theotherreceive

Regra geral, pelo menos nos sistemas com sabor Debian:

  • /usr/local para itens "abrangentes ao sistema" - ou seja, /usr/local tende a estar no padrão de uma distribuição $PATH e segue uma hierarquia de diretórios UNIX padrão com /usr/local/bin, /usr/local/lib, etc.

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

92
directhex

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

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

Minha maneira favorita de instalar software compilado sob encomenda é no meu $HOME diretório. Dessa forma, você não precisa usar Sudo para nada, 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/bin para o seu $PATH.

50
Sandy

a ESF diz para colocá-lo em/usr/local onde as distribuições não devem tocá-lo. /usr/local/bin para os binários /usr/local/src para a fonte e /usr/local/lib para bibliotecas. Veja especificação FHS para obter mais informações

21
xenoterracide

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

10
Scott Anderson

Coloque-os em /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 em /usr/local/src/postgresql.

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

9
Stephen Jazdzewski

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

 ./configure
 make

seguido por

 Sudo checkinstall

para criar um arquivo . deb ...

6
Kevin Cantu

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

5
Aaron Toponce

Se houver possibilidade - sugiro compilar seu software e criar o pacote FC (acredito que 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
Eimantas

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

5
Daniel James

Duas coisas que eu recomendaria:

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 por padrão XDG .

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

4
elmarco

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. É o que faço na maioria das vezes: basta criar um pouco de rotação.

3
wzzrd

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 é agradável durante o desenvolvimento.

3
jacksonh

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.

2
Hemant

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

2
Nils

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 root), use/home/nome de usuário

1
Silviu Bogan

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 em /usr e não sob /usr/local, como todos os outros arquivos que vêm através do sistema de empacotamento.

0
user55149

A maneira mais fácil de fazer isso é pegar o pacote de origem (.src.rpm para RPMites), descompacte-o, corte a nova fonte/configuração/o que quer que seja, altere a versão adequadamente e construa-a. 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
vonbrand