Instalando a partir da fonte. Como resolver dependências sem destruir o gerenciador de pacotes

Compilar e instalar software é uma dor e um problema que não posso superar. Eu só quero passar por minha compreensão desse processo com alguém mais experiente para limpar minha mente para chegar ao próximo nível.

Muitos softwares científicos necessários não são distribuídos como pacotes. Entendo que "./configure" configura as variáveis ​​de compilação e a verificação de dependências "make" faz a compilação "sudo make install" coloca todas as bibliotecas e compartimentos em seus lugares. No entanto, isso nunca funciona. Raramente saio do estágio a) "./configure" sem entrar no inferno das dependências, e se o fizer, b) "sudo make install" provavelmente irá destruir minha caixa.

a) O inferno da dependência é muito frustrante. Às vezes tenho a biblioteca, mas ela não gosta. Ou a biblioteca não deseja instalar. Ou "configure" não pode encontrá-lo. Ou minha distro colocou em algum lugar que não deveria estar. Ou existem duas versões no meu sistema. O problema é que não consigo entender como diagnosticar e, portanto, corrigir esses problemas. Quais são algumas boas referências para aprender para alguém que não precisa se tornar um programador?

b) Meu entendimento é que "make install" substituirá algumas bibliotecas e alterará as configurações sem que meu gerenciador de pacotes esteja ciente disso. Portanto, alguns programas não serão executados, outros não poderão ser atualizados. Portanto, se eu não usar "make install" e apenas manter o binário compilado no meu diretório de usuários com um link simbólico adicionado ao PATH, ficarei claro?

Minha caixa é de usuário único, possui toneladas de HD grátis, então eu realmente não me importo em ter várias (dezenas) de cópias de bibliotecas, se isso resolver meus problemas. O espaço é barato.

A maioria dos pacotes terá um <package>-dev(para Debian) ou <package>-devel(para Red Hat) que serão as bibliotecas necessárias para vincular a construção.

Então, por exemplo, se a fonte diz que exige libxml, nos sistemas baseados no Debian você encontrará libxml2e libxml2-dev(usará apt-cache search <dependancy>para encontrá-los).

Você precisará libxml2-devcompilar e libxml2executá-lo.

A ./configureetapa geralmente suporta sinalizadores como --with-libxml=/usr/lib/apontá-la para as bibliotecas corretas ( ./configure --helpdeve listar todas as opções). Ele também geralmente suporta a alteração do local de instalação com --prefix=$HOME/sw. Usar um prefixo fora do que o gerenciador de pacotes controla é a melhor maneira de evitar conflitos com o software instalado no gerenciador de pacotes.

No Debian e derivativos, use um --prefixde /usr/local/ou /opt/local/deve ser seguro.

Se uma biblioteca (ou versão) necessária não estiver disponível no gerenciador de pacotes, basta baixar o código-fonte e compilá-lo usando opções semelhantes. O mais importante é usar uma parte --prefixexterna do seu gerenciador de pacotes e ao compilar o software que você realmente deseja usar --with-<library>=/<path/to/installed/library>.

Existe a ferramenta auto-aptque pode ser usada para isso.

Do man auto-apt :

O auto-apt é um programa que verifica o acesso a arquivos de programas em execução em ambientes de auto-apt. Se um programa acessar um arquivo de pacote não instalado, o auto-apt instalará o pacote que contém o arquivo usando o apt-get.

É usado da seguinte maneira:

auto-apt run ./configure

Outra maneira é usar apt-get build-dep <package>em distribuições baseadas no Debian.

Para distribuições baseadas em RPM, você pode tentar criar pacotes adequados (não é que difícil ...).

Os benefícios de um pacote adequado são que o gerenciador de pacotes monitora o software e você pode facilmente replicar sua configuração em outro lugar / na próxima máquina. Com um pacote de código fonte adequado para a frente (nova versão upstream, correção de bug, atualizações das bibliotecas subjacentes) é mais fácil do que ter que descobrir tudo do zero na próxima vez.