Repackaging software proprietário

Question

Eu estava pensando em tentar empacotar o Matlab (um software proprietário) para o Arch Linux, criando um PKGBUILD para lidar com instalações, dependências e conflitos. Com o instalador padrão do Matlab Linux, ele coloca tudo em um diretório local e não requer muitos pacotes externos.

Dito isso, ele fornece vários arquivos de biblioteca padrão (por exemplo, libgcc_s.so e libstdc ++. so), além de um JRE completo. Esses tipos de arquivos podem ser removidos (possivelmente substituídos por links) e fornecidos por dependências adicionais de pacotes?

    

Answer 1

Eu tento manter o pacote PHP App Engine no AUR e estou instalando em /opt , onde você deve colocar um pacote Matlab independente (em algo como /opt/matlab ) e sym-link o executável de volta para /usr/bin e outras coisas de volta para /usr/share/applications e quais não.

Eu daria uma olhada em alguns outros pacotes que re-empacotam binários para arch. Como o Dropbox ou . O pacote do Chrome, em particular, depende do binário do Debian, assim eles descartam as especificidades do Debian ao instalar no arco.

Por outro lado, se você soltar tudo em /opt/matlab como está, em vez de remover bibliotecas comuns e o JRE, é muito mais provável que você tenha um Matlab funcional que não quebre ou precise ser testado novamente e reempacotado toda vez que uma dependência muda.

Você pode oferecer dois sabores: um pacote completo do Matlab e um pacote mínimo do Matlab.

    

Answer 2

Não vejo por que a remoção seria um problema e a substituição por links, supondo que eles sejam idênticos às versões incluídas na instalação do Matlab. Mas de alguma forma parece que você está fazendo muito trabalho para si mesmo.

Quando eu costumava dar suporte a um grupo onde mantivemos muitas versões de pacotes proprietários, como o Matlab, nosso grupo os instalava em diretórios independentes e usava uma ferramenta semelhante a modules para manter o gerenciamento do ambiente do usuário quando eles quiserem trocá-lo para que possam usar esses pacotes.

Veja este P & D Q & A intitulado: Adicione vários subdiretórios no mesmo diretório pai ao PATH onde discuto várias táticas para gerenciar a variável de ambiente $PATH do sistema. Essas mesmas táticas também podem ser aplicadas a praticamente qualquer variável de ambiente. Geralmente, são eles que controlam a funcionalidade de aplicativos proprietários.

    

Answer 3

Existem dois motivos pelos quais os aplicativos grandes vêm com bibliotecas agrupadas. Uma razão é que ele evita que os usuários tenham que rastrear todas as bibliotecas, descobrir qual pacote os contém em sua distribuição, garantir que eles tenham as versões corretas, etc. Manter pacotes binários que funcionam em todas as distribuições é complicado porque em um determinado ponto Com o tempo, as distribuições geralmente enviam diferentes versões de bibliotecas. Se o seu pacote é para uma determinada versão de uma determinada distribuição, então confiar na versão da distribuição não é um problema. Mas com o Arch Linux, devido à falta de versões estáveis, você terá que atualizar seu pacote com muita frequência se você não empacotar pelo menos as bibliotecas que mudam rapidamente.

O outro motivo para agrupar bibliotecas é que às vezes os programas têm dependências em versões de bibliotecas específicas. Em princípio, as bibliotecas têm números de versão de duas partes: um número de versão principal que muda sempre que a ABI¹ muda de uma maneira incompatível e um número de versão menor que muda sempre que algo muda (por exemplo, uma correção de bug ou um novo recurso que não quebrar a compatibilidade com versões anteriores). (Muitas bibliotecas têm um número de versão do formato MAJOR.MINOR, mas isso não é universal.) Binários de bibliotecas com diferentes versões principais têm sonames diferentes. , para que possam ser instalados juntos, ao passo que os binários de bibliotecas que diferem apenas por sua versão secundária têm o mesmo nome, de modo que somente um é encontrado por meio de vinculação dinâmica. Se o programa foi construído e testado para a versão 1.2, mas você tem a versão 1.3, o programa deve ainda funcionar. No entanto, às vezes, os programas usam interfaces não documentadas que não fazem parte da ABI e que podem ser quebradas em 1.3. Como o teste com todas as combinações de versão de biblioteca possíveis seria um pesadelo de suporte, os distribuidores de binários preferem que todos os usuários usem as mesmas versões de biblioteca (com uma exceção para algumas bibliotecas do sistema, especialmente a libc).

¹ _{Interface Binária do Aplicativo: a especificação da interface entre a biblioteca compilada e o programa compilado.}