Primeiro de tudo, encontrei esta pergunta semelhanteComo fazer um aplicativo Linux portátil?mas isso realmente não responde às minhas dúvidas, é mais sobre como compilar para tornar o aplicativo portátil, o que eu já sei fazer (pelo menos acho que sei) e não sobre implantação, como explicarei a seguir.
Esta é a minha situação. Fomos contratados para resolver um determinado problema de um cliente, por isso estaremos desenvolvendo uma aplicação de código fechado que pretendemos vender para ele. No entanto, não recebemos quaisquer detalhes sobre onde ele deveria ser executado, com isso quero dizer qual distribuição, versão do kernel ou qualquer coisa realmente. A tarefa é bastante simples e não depende de drivers de baixo nível ou de qualquer coisa que complique sua portabilidade. No entanto, dependemos de algumas bibliotecas de terceiros. A seguir está um esquema simples das dependências:
app --+-- libA
| +-- lib1
+-- libB --+-- lib2
+-- lib3
Onde libA,B e lib1,2,3 são todos projetos de código aberto com licenças adequadas (LGPL, ASL e BSDs). Uma vez compiladas, as dependências compartilhadas do nosso programa tornam-se libA, libB, lib1, lib2, lib3 e um monte de bibliotecas de sistema, como libc, libm, libz, libstdc++, libpthread, etc.
Agora, como não temos uma distribuição alvo, queremos mantê-la independente de qualquer sistema de empacotamento como .deb ou similar. As dependências diretas (libA e libB) não são muito comuns, então a escolha óbvia é entregá-las juntas com a nossa aplicação. lib1,2,3 são na verdade mais comuns (ou seja, um deles é libpng), embora ainda não tenhamos certeza de que serão instalados no sistema de destino. Decidimos incluir todos os 5 no pacote de software final.
O que não temos ideia do que fazer são as bibliotecas do sistema. Como devemos lidar com isso? Presumimos apenas que eles terão as bibliotecas corretas e oramos pelo melhor? Nesse caso, o que aconteceria em um ou dois anos quando uma dessas bibliotecas mudasse e nosso aplicativo parasse de funcionar?
Devemos distribuir todos eles (libstdc++, glibc, etc) com nosso software? Isso não parece certo e acho que pode ir contra os termos de licenciamento neles. Eu sei que usei alguns programas no passado que carregavam sua própria cópia de [pelo menos] algumas dessas bibliotecas, na verdade me chamou a atenção porque era uma versão mais antiga que a do meu sistema e trocá-las fez tudo parar trabalhando (o que descobri por acidente).
Como isso geralmente é tratado?
Responder1
A abordagem estritamente correta para executáveis binários portáteis no Linux é trabalhar contra oBase Padrão Linuxe os seusespecificações detalhadas. O LSB foi projetado para produzir compatibilidade binária entre distribuições compatíveis, especificando versões específicas da biblioteca (ou compatibilidade com essas versões). A LSB (ou pelo menos uma versão anterior) foi formalizada comoISO/IEC 23360. Se você construir seu programa para vincular apenas bibliotecas LSB (e aquelas que ele próprio envia), ele será portátil entre todos esses sistemas.
O LSB especifica o formato RPM para pacotes, então você só precisa produzir um (estritamente). Um tarball também será suficiente, caso você renuncie à integração com o gerenciador de pacotes.
Em relação a alguns de seus pontos específicos:
Presumimos apenas que eles terão as bibliotecas corretas e oramos pelo melhor?
Um programa compatível com LSB bastante simples provavelmente será executado em muitos sistemas como estão, então você poderia fazer isso.
Além disso, diversas distribuições tentam fornecer conformidade com LSB, incluindo RHEL e SUSE. Alguns outros oferecem isso por meio de um pacote específico que extrai as dependências apropriadas. Por exemplo, o Debian temum pacotelsbque puxa lsb-coree vários outros, que por sua vez puxam as dependências apropriadas. É possível que os sistemas de destino precisem instalar esse pacote para executar o software.
O LSB é menos popular do que era antes e a compatibilidade formal diminuiu para muitos sistemas, mas na prática é possível rodar de forma portável em uma faixa bastante ampla. Mesmo alguns sistemas que aspiram à conformidade perdem alguns dos pontos mais obscuros, mas para fins comuns isso muitas vezes não importa (e os mesmos programas podem funcionar em sistemas quenãotentar ser compatível com LSB).
Nesse caso, o que aconteceria em um ou dois anos quando uma dessas bibliotecas mudasse e nosso aplicativo parasse de funcionar?
Quando seu aplicativo parar de funcionar, ele irá parar de funcionar. Esta é uma questão de processo de negócios.
Devemos distribuir todos eles (libstdc++, glibc, etc) com nosso software?
Provavelmente não. Para a libc, em particular, pode haver problemas de compatibilidade em tempo de execução ao usar múltiplas versões ao mesmo tempo em um sistema. Entretanto, existem outras implementações da libc que podem ser mais práticas de agrupar.
Embora a maioria das bibliotecas possa ser agrupada com êxito, a venda de bibliotecas é um problema de manutenção e segurança em geral, portanto, desaconselho fazê-lo sempre que puder ser evitado. Se um bug ou falha de segurança for descoberto em uma biblioteca, atualizá-lo em um local do sistema, que a distribuição irá resolver, é mais fácil e confiável do que rastrear cada cópia (e obter seus pacotes de substituição!).
Como uma etapa mais prática, talvez pergunte ao seu cliente onde ele deseja que seja executado. Você pode estar excessivamente entusiasmado.
Responder2
Na prática você precisará fazerdiversospacotes binários (por exemplo, .debpara Debian e Ubuntu, .rpmpara Fedora) para as distribuições (e versões) Linux mais comuns. Obviamente você precisará criar pacotes diferentes para o Fedora e para o Ubuntu, e talvez seja necessário criar um pacote diferente para o Debian Jessie e Ubuntu 16.04. No entanto,às vezesum pacote para Ubuntu pode ser instalado em algum Debian (particular) ou vice-versa.
No entanto, não recebemos quaisquer detalhes sobre onde ele deveria ser executado, com isso quero dizer qual distribuição, versão do kernel ou qualquer coisa realmente.
Você precisa discutir com seu cliente.
Nesse caso, o que aconteceria em um ou dois anos quando uma dessas bibliotecas mudasse e nosso aplicativo parasse de funcionar?
Você precisará construir e lançar variantes mais recentes de seus pacotes binários e gastará esforços (e dinheiro) para isso.
Você pode querer vincular (se técnica e legalmente possível) algumas bibliotecas estaticamente (lembre-se de que a licença LGPL recomenda vincular dinamicamente ou então poder vincular novamente estaticamente na máquina cliente). Por exemplo, libstdc++é muito mais sensível a versões do libcque você pode vincular estaticamente libstdc++e dinamicamente libc. Na verdade YMMV.
Observe que tendodiversosversões de uma determinada biblioteca do sistema podem ou não funcionar na prática. Algumas bibliotecas usam recursos do sistema de uma maneira específica, portanto os detalhes são muito importantes.
PS. Talvez você devesse discutir mais com seu cliente e se oferecer para fazer um software livre (código aberto). Alguns clientes podem preferir isso.