Como podemos “persuadir” o fink, port, & brew a coexistir em paralelo no OSX Mavericks?

Question

Gostamos de usar brew , mas ela não tem muitas fórmulas gnome toolset , e podemos instalar gnome-terminal rapidamente com FinkCommander . Criamos várias partes de gnome a partir do zero, mas criar uma fórmula brew apenas para obter o gnome-terminal parece um exagero, quando já estiver disponível.

Independentemente disso, estávamos tendo problemas para criar gnome-terminal com FinkCommander , ou seja, removemos todas as referências do componente brew installed das variáveis de ambiente; Certamente tivemos que usar /usr/local/bin e /usr/local/opt/gnu-tar/libexec/gnubin de $PATH , e apenas para pontapés, garantimos que ${DY}LD_LIBRARY_PATH não apontasse para /usr/local/lib , etc. Isso permitiu que gnome-terminal criasse & instalar com sucesso com FinkCommander .

Além disso, temos o software que queremos instalar via brew , fink , e port - mas brew não joga bem com os outros . Isso levou à questão mais geral: basta alternar caminho e variáveis de ambiente para alternar entre brew e fink / port constrói ambientes e instalações ? Sabemos que precisamos ocultar brew de fink por meio de variáveis de ambiente ao criar gnome-terminal com FinkCommander , e a suposição é que para alguma fórmula definida de brew , o inverso é verdadeiro .

O que, em geral, devemos fazer para ter o melhor dos três mundos? Ou seja, o que fazer para ter todos os três, brew , fink e port , criados e instalados em paralelo? Como todos os pacotes gerenciados foram construídos do zero, cada pacote deve saber onde suas próprias bibliotecas vinculadas dinamicamente estão localizadas. É o suficiente para confundir os $PATH , $MANPATH , & $DYLD_LIBRARY_PATH variáveis de ambiente on the fly para colocar uma instalação na frente de outra para usar suas ferramentas definidas? Estamos sentindo falta de alguma coisa?

    

Answer 1

Deixe-me responder que, da perspectiva MacPorts, eu venho, como esses problemas de ferramentas de gerenciamento de software coexistentes não são desconhecidos lá. Mais importante, simplesmente não há como remover /usr/local dos caminhos de pesquisa padrão do compilador. Isso pode levar a problemas com algumas compilações, especialmente durante uma compilação +universal de arquitetura múltipla.

No início do projeto, há muitos anos, o MacPorts mudou para /opt/local para evitar problemas com outro software. O isolamento total de /usr/local parece não ser possível apenas pelos sinalizadores de configuração do compilador. Infelizmente, os desenvolvedores do Homebrew deliberadamente ignoraram isso e escolheram / usr / local como padrão. Embora pareça uma boa ideia, como já estaria listado no PATH, na configuração padrão /usr/local/bin ocorre somente após /usr/bin , tornando impossível sobrescrever qualquer ferramenta de linha de comando. Portanto, não há vantagem em usar /usr/local .

A melhor solução é instalar o Homebrew em qualquer outro caminho (por exemplo /opt/homebrew ) ou renomear / usr / local temporariamente antes de construir e renomeá-lo depois:

sudo mv /usr/local /usr/local.off
... # do your compilation work
sudo mv /usr/local.off /usr/local

Como uma observação para o futuro, enquanto o MacPorts em sua versão atual já está usando uma sandbox para todas as compilações, há melhorias nessa área para a versão 2.3.0 ou posterior. O novo modo de rastreio atualmente em desenvolvimento permitiria limitar todo o acesso a arquivos aos arquivos necessários apenas para a tarefa de construção específica, ocultando locais como /usr/local e /sw completamente do processo de construção. No entanto, isso não ajudará em outras ferramentas, a menos que elas também adotem esse recurso.

    

Answer 2

Como cada sistema de porta geralmente vem com peculiaridades diferentes (e a porta ocasional não consegue ser construída devido a alguma estranheza escondida em seu caminho de dependências), eu tenho um sistema com HomeBrew, MacPorts e FreePorts instalado em paralelo. Para o ambiente de compilação, geralmente é suficiente impedir que eles detectem as outras instalações do sistema de portas durante o tempo de compilação e compilação para mantê-los separados, para que não entrem em dependências uns dos outros, ou piores falhas e danos devido a uma dependência detectada a árvore de portas errada.

Até agora, foi suficiente inicializar um ambiente de construção limpo que tenha apenas os diretórios do sistema (certifique-se de evitar /usr/local para MacPorts, Fink, FreePorts, consulte Resposta do Raims ) + seus próprios diretórios de destino em seus caminhos de busca, caminho do vinculador, etc., da maneira já descrita na Pergunta acima.

Para a construção, prefiro a árvore de sistemas de portas na ordem dos diretórios pesquisados, para evitar reclamações de tempo de configuração sobre versões desatualizadas detectadas no MacOSX padrão pelo sistema de compilação de porta. Para o usuário que está executando a porta, é mais seguro anexar essas árvores, para dar preferência aos binários fornecidos pelo SO.

Se você precisar copiar as árvores de portas instaladas, ditto seria a ferramenta de escolha. A partir do manpage:

ditto will preserve resource forks and HFS meta-data information when copying unless instructed otherwise using --norsrc . Similarly, ditto will preserve extended attributes and Access Control Lists (ACLs) unless --noextattr or --noacl is passed.

Outra opção seria /usr/bin/rsync -avSEH :

• a rchive mode,
• v erbose é opcional,
• E para preservar atributos estendidos e ACLs,
• S para manipular arquivos esparsos corretamente (sem expandi-los para sua capacidade total, ocupando mais espaço que o original) e
• H para preservar os links físicos.

Para um tar que lida com as ACLs (explicou aqui ) e os atributos estendidos, faça uma olhe para star , uma implementação muito madura (1982) tar que ainda é ativamente mantida por seu autor original. Você pode compilá-lo usando um dos sistemas de portas mencionados anteriormente ou instalá-lo como parte de schilytools .