Estou tentando instalar php-5.3no Arch Linux, mas bisoné muito novo, então criei uma versão mais antiga a bisonpartir dos fontes. E parece que ele se instala /usr/localpor padrão. (Isso é algum tipo de convenção?) Agora estou me perguntando se posso instalar mais de uma versão bison, ou seja, lado a lado com a versão padrão do sistema e aquela que acabei de instalar. É provável que esse tipo de coisa raramente seja necessário. Estou apenas curioso sobre isso. Isso é algo difícil de fazer? Como devo fazer isso?
Responder1
Alguns softwares específicos podem ser configurados com --program-suffix=-my-version-suffix. Pode ser necessário personalizar alguns dos outros diretórios, mas se você deixar o --prefixpadrão ( /usr/local), isso não colidirá com o pacote da distribuição no /usr.
Noem geralNo entanto, a única distro que tenta permitir a co-instalação de versões arbitrárias éNix, no entantoGentootenta obter mais pacotes do que a maioria das distros (embora para Bison ele permita apenas uma versão por vez - pelo menos oferece uma escolha).
Observe, entretanto, que se o seu código-fonte quebrar com versões mais recentes do bison, isso geralmente significa um problema simples com o seu código-fonte. Geralmente há algum %option(ou --argument) que pode consertar isso.
Responder2
Uma maneira de tratar esse problema de forma consistente é usar omodulespacote. Funciona alterando variáveis ambientais (por exemplo, os caminhos para seus binários).
O pacote Environment Modules fornece a modificação dinâmica do ambiente de um usuário por meio de modulefiles. Os módulos podem ser carregados e descarregados de forma dinâmica e atômica, de forma limpa
por exemplo
$ module load gcc/3.1.1
$ which gcc
/usr/local/gcc/3.1.1/linux/bin/gcc
$ module switch gcc gcc/3.2.0
$ which gcc
/usr/local/gcc/3.2.0/linux/bin/gcc
No seu caso, a bisonversão que vem primeiro na sua PATHvariável ambiental é selecionada. Para inspecionar ou alterar esta variável manualmente para o terminal atual, execute
$ echo $PATH
....
priorize /opt/bin_pre_pendendo-o no PATH:
$ export PATH="/opt/bin:$PATH"
ou anexe /opt/bin/ao PATH(só será selecionado se nenhum binário com o mesmo nome for encontrado em outro lugar em PATH)
$ export PATH="$PATH:/opt/bin"
Responder3
Apenas para dar uma resposta mais atualizada:
Sim, isso é definitivamente possível hoje em dia.
O inferno da dependência é coisa do passado, a menos que a distribuição também o seja. :)
Arch não resolve isso. Você precisa de uma distribuição baseada na fonte. Como as dependências seriam codificadas (para certas definições de codificadas), e ambas as instalações apontariam para as mesmas bibliotecas, etc.
Mas ao construir a partir do código-fonte, você pode construí-lo com caminhos diferentes a cada vez.
O Gentoo tem um recurso chamado “slotting” há muito tempo, o que torna tudo trivial. As dependências de uma versão de um pacote podem ser especificadas como um determinado “slot” de outro pacote. Um slot é uma série de versões que não entram em conflito com nenhum outro slot. (Para a maioria dos pacotes que vi, qualquer versão pode ter seu próprio slot. Especialmente para bibliotecas. Mas às vezes um pacote não consegue lidar com isso porque depende de coisas das quais existe apenas uma. Ou porque requer um pouco de trabalhe no gerenciador de pacotes [por exemplo, para modificar os arquivos de configuração instalados na instalação])
Mas tenho certeza de que qualquer outra distribuição completa terá algo semelhante.
Caso contrário, uma solução alternativa é sempre configurar o mesmo sistema de compilação com o qual os pacotes da sua distribuição são construídos pelos mantenedores, clonar os pacotes necessários com um novo nome e alterar o processo de compilação para apontar para as diferentes versões das dependências. e, em seguida, basta construí-lo em um novo pacote não-fonte, como fariam os mantenedores do pacote da sua distribuição. (Francamente, achei o Gentoo mais fácil de instalar. :)