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.