Onde devo colocar software eu me compilar?

Question

Eu preciso compilar algum software na minha máquina do Fedora. Onde é o melhor lugar para colocá-lo de modo a não interferir com o software empacotado?

    

Answer 1

Regra geral, pelo menos em sistemas com sabor do Debian:

• /usr/local para material que é "todo o sistema", por exemplo. /usr/local tende a estar em um padrão de distribuição $PATH da distribuição e segue uma hierarquia de diretório padrão do UNIX com /usr/local/bin , /usr/local/lib , etc.

• /opt para itens em que você não confia para fazer 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 quebre o sistema - e é mais fácil de remover, já que você acabou de excluir a pasta e desapareceu.

Answer 2

Se você realmente não quiser interferir, não coloque em nenhum lugar em $PATH .

Se você quiser em $PATH , pelo menos não instale em /usr/local . Eu descobri que muitos softwares parecem lá, mesmo que sejam instalados pela distro em /usr .

Minha maneira favorita de instalar softwares compilados sob encomenda está no meu diretório $HOME . 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 quiser, você pode adicionar /home/username/stage/bin ao seu $PATH .

    

Answer 3

A FHS diz para colocar em / usr / local onde as distribuições não devem tocá-lo. /usr/local/bin para os binários /usr/local/src para a origem e /usr/local/lib para bibliotecas. Consulte as Especificações da FHS para obter mais informações

    

Answer 4

Na maioria das vezes, gosto de colocar meu próprio material compilado 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.

    

Answer 5

Coloque-os em /usr/local/src .

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

/usr/local/src/postgresql-8.3.7

Em seguida, 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 inserir entre versões e documentos a versão que está usando.

    

Answer 6

Isso me lembra que preciso usar checkinstall mais frequentemente! Assim, faço o que é habitual

 ./configure
 make

seguido por

 sudo checkinstall

para criar um arquivo .deb ...

    

Answer 7

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

    

Answer 8

Se você quiser instalar e remover facilmente vários aplicativos criados por você mesmo, use Stow como um gerenciador de pacotes simples.

    

Answer 9

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

    

Answer 10

Duas coisas que eu recomendaria:

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

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

Você também pode usar a armazenagem localmente, embora eu nunca tenha feito:)

    

Answer 11

Eu tenho uma configuração um pouco diferente da maioria das pessoas porque eu faço muito desenvolvimento. Eu tenho um diretório / home / jackson / bin / que eu instalo coisas e editei meu .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 para tudo, mas é bom durante o desenvolvimento.

    

Answer 12

Na verdade, não é tão difícil criar deb's ou rpms 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 é o que eu faço na maioria das vezes: basta criar um pouco de rpm.

    

Answer 13

se você estiver compilando uma aplicação, você pode adicionar seu caminho executável em sua variável PATH env. isso não afetará outros usuários.

    

Answer 14

Há sempre a opção de "colocá-lo no lugar certo", mas escreva um simples rpm primeiro.

    

Answer 15

Se você quiser que seu aplicativo esteja disponível para todos os usuários no sistema e tenha as permissões necessárias, use / opt. Se você quiser que o aplicativo esteja disponível apenas para você (e root), use / home / username

    

Answer 16

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

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

    

Answer 17

Escreva um RPM, não é difícil, tem orientações sobre onde colocar as coisas e torna a desinstalação rápida.

Se você fizer isso, instale os arquivos em /usr e não em /usr/local , como todos os outros arquivos que chegam pelo sistema de empacotamento.