Como distribuir um programa de código fechado comercial Linux portátil? [fechadas]

Question

Primeiro, eu encontrei essa pergunta semelhante Como fazer um aplicativo Linux portátil? mas ele realmente não resolve minhas dúvidas, é mais sobre como compilar para tornar o aplicativo portátil que eu já sei como fazer (pelo menos eu acho que faço) e não sobre a implantação como Vou explicar abaixo.

Esta é a minha situação. Fomos contratados para resolver um determinado problema para um cliente, por isso estaremos desenvolvendo um aplicativo de código fechado que pretendemos vender para eles. No entanto, não nos foi dado nenhum detalhe sobre onde ele deve 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 nenhum driver de baixo nível ou de qualquer coisa que possa complicar sua portabilidade. No entanto, dependemos de algumas bibliotecas de terceiros, o seguinte é 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 se tornam libA, libB, lib1, lib2, lib3 e um monte de bibliotecas de sistema como libc, libm, libz, libstdc ++, libpthread, etc. Tudo é vinculado dinamicamente.

Agora, como não temos uma distribuição de destino, 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 completamente com nosso aplicativo. lib1, 2, 3 são na verdade mais comuns (ou seja, uma delas é libpng), embora ainda não tenham certeza de que serão instaladas no sistema de destino. Decidimos incluir todos os 5 deles no pacote de software final.

O que não temos ideia do que fazer com as bibliotecas do sistema. Como devemos lidar com isso? Nós apenas assumimos que eles terão as bibliotecas corretas e orarão pelo melhor? Nesse caso, o que aconteceria em um ano ou dois quando uma dessas bibliotecas mudasse e nosso aplicativo parasse de funcionar?

Devemos distribuir todos eles (libstdc ++, glibc, etc) com o nosso software? Isso não parece certo e acho que pode estar indo contra os termos de licenciamento neles. Eu sei que usei alguns programas no passado que na verdade carregavam sua própria cópia de [pelo menos] algumas dessas bibliotecas, na verdade chamou minha atenção porque era uma versão mais antiga que a do meu sistema e trocá-los fez tudo parar trabalhando (o que eu descobri por acidente).

Como isso é geralmente tratado?

    

Answer 1

A abordagem estritamente correta dos executáveis binários portáteis no Linux é trabalhar contra a Base Padrão do Linux e sua especificações detalhadas . O LSB foi projetado para produzir compatibilidade binária entre distribuições compatíveis, especificando versões de bibliotecas específicas (ou compatibilidade com essas versões). O LSB (ou pelo menos uma versão anterior) foi formalizado como ISO / IEC 23360 . Se você construir seu programa para vincular-se somente a bibliotecas LSB (e aquelas que ele mesmo 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 será suficiente também, se você renunciar à integração com o gerenciador de pacotes.

Em relação a alguns dos seus pontos específicos:

Do we just assume they'll have the correct libraries and pray for the best?

Um programa compatível com LSB bastante simples provavelmente será executado em muitos sistemas no estado em que se encontra, portanto, você pode fazer isso.

Além disso, várias distribuições tentam fornecer conformidade com LSB, incluindo RHEL e SUSE. Alguns outros o oferecem através de um pacote específico que puxa as dependências apropriadas. Por exemplo, o Debian tem o pacote lsb que puxa lsb-core e vários outros, que por sua vez puxam o dependências apropriadas. É possível que os sistemas de destino precisem instalar esse pacote para executar seu 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 um intervalo bastante amplo. Até mesmo alguns sistemas que aspiram à conformidade perdem alguns dos pontos mais obscuros, mas para propósitos comuns geralmente não importa (e os mesmos programas podem funcionar em sistemas que não tentam ser LSB -compliant).

In such case, what would happen in a year or two when one of those libraries changes and our application stops working?

Quando seu aplicativo parar de funcionar, seu aplicativo deixará de funcionar. Esta é uma questão do processo de negócios.

Should we distribute all of them (libstdc++, glibc, etc) with our software?

Provavelmente não. Para a libc, em particular, pode haver problemas de compatibilidade em tempo de execução ao usar várias versões de uma vez em um sistema. Existem outras implementações de libc que podem ser mais práticas para empacotar, no entanto.

Embora a maioria das bibliotecas possa ser agrupada com êxito, as bibliotecas de vendas são um problema de manutenção e segurança em geral, portanto, eu aconselharia não fazê-lo onde quer que ela possa ser evitada. Se um bug ou falha de segurança for descoberto em uma biblioteca, atualizá-lo em um lugar no sistema, que a distribuição abordará, é mais fácil e confiável do que rastrear cada cópia (e obter pacotes de substituição de você!).

Como um passo mais prático, talvez pergunte ao seu cliente onde ele quer que ele seja executado. Você pode estar sendo muito entusiasmado.

    

Answer 2

Na prática, você precisará criar vários pacotes binários (por exemplo, .deb para o Debian e Ubuntu, .rpm para o Fedora) para as distribuições (e versões) mais comuns do Linux. Obviamente você precisará fazer pacotes diferentes para o Fedora e para o Ubuntu, e você pode precisar fazer um pacote diferente para o Debian Jessie & Ubuntu 16.04. No entanto, algumas vezes um pacote para o Ubuntu pode ser instalado em algum Debian (particular) ou vice-versa.

However, we have not been given any specifics about where it should be able to run, with that I mean what distribution, kernel version or anything really.

Você precisa discutir com seu cliente.

In such case, what would happen in a year or two when one of those libraries changes and our application stops working?

Você precisará criar e liberar novas variantes de seus pacotes binários, e você gastará esforços (& dinheiro) para isso.

Você pode querer vincular (se for tecnicamente e legalmente possível) algumas bibliotecas estaticamente (lembre-se de que a licença LGPL recomenda vincular dinamicamente, ou então ser capaz de revincular estaticamente na máquina cliente). Por exemplo, libstdc++ é muito mais sensível a versões do que o libc , portanto você pode vincular estaticamente libstdc++ e dinamicamente libc . Na realidade, YMMV.

Observe que ter várias versões de uma determinada biblioteca do sistema pode ou não funcionar na prática. Algumas bibliotecas estão usando recursos do sistema de uma maneira específica, portanto, os detalhes são muito importantes.

PS. Talvez você deva discutir mais com seu cliente e oferecer para fazer um software livre (código aberto). Alguns clientes podem preferir isso.