首先，我發現了這個類似的問題如何製作一個便攜式 Linux 應用程式？但它並沒有真正解決我的問題，更多的是關於如何編譯以使應用程式可移植，我已經知道如何做（至少我認為我知道），而不是關於部署，正如我將在下面解釋的那樣。
這就是我的情況。我們受僱為客戶解決某個問題，因此我們將開發一個閉源應用程序，並打算將其出售給他們。然而，我們還沒有得到任何關於它應該能夠在哪裡運行的具體信息，我的意思是哪個發行版、內核版本或其他任何東西。該任務相當簡單，不依賴任何低階驅動程式或任何使其可移植性變得複雜的東西。然而，我們確實依賴幾個第三方函式庫，以下是依賴項的簡單方案：
app --+-- libA
| +-- lib1
+-- libB --+-- lib2
+-- lib3
其中 libA、B 和 lib1、2、3 都是具有合適授權（LGPL、ASL 和 BSD）的開源專案。編譯後，我們程式的共享相依性變成了libA、libB、lib1、lib2、lib3和一堆系統函式庫，例如libc、libm、libz、libstdc++、libpthread等。
現在，由於我們沒有目標發行版，我們希望使其獨立於任何打包系統（如 .deb 等）。直接依賴項（libA 和 libB）並不常見，因此顯而易見的選擇是將它們與我們的應用程式一起提供。 lib1,2,3 實際上更常見（即其中一個是 libpng），儘管仍然不確定它們是否會安裝在目標系統中。我們決定將它們全部包含在最終的軟體包中。
我們不知道如何處理系統庫。我們應該如何處理這個問題？我們是否只是假設他們將擁有正確的圖書館並祈禱最好的結果？在這種情況下，當其中一個庫發生變化並且我們的應用程式停止工作時，一兩年後會發生什麼？
我們是否應該將所有這些（libstdc++、glibc 等）與我們的軟體一起分發？這感覺不對，我認為這可能違反了其中的許可條款。我知道我過去使用過一些程序，它們實際上攜帶了[至少]其中一些庫的自己的副本，它實際上引起了我的注意，因為它是比我係統中的版本舊的版本，並且交換它們使一切都停止了工作（我偶然發現的）。
通常如何處理這種情況？
答案1
在 Linux 上實現可移植二進位可執行檔的嚴格正確方法是反對Linux 標準函式庫和它的詳細規格。 LSB 旨在透過指定特定的庫版本（或與這些版本的兼容性）來產生跨相容發行版的二進位相容性。 LSB（或至少是過去的版本）被形式化為ISO/IEC 23360。如果您建立的程式僅連結到 LSB 庫（及其本身附帶的庫），那麼它將在所有這些系統之間進行移植。
LSB 指定了軟體包的 RPM 格式，因此您只需要產生一個（嚴格地）。如果您放棄與套件管理器的集成，一個 tarball 就足夠了。
關於您的一些具體觀點：
我們是否只是假設他們將擁有正確的圖書館並祈禱最好的結果？
一個相當簡單的 LSB 相容程式可能會按原樣在許多系統上運行，所以您可以這樣做。
除此之外，一些發行版嘗試提供 LSB 合規性，包括 RHEL 和 SUSE。其他一些人透過特定的套件來提供它，該套件會引入適當的依賴項。例如，Debian 有一套lsb它會引入lsb-core其他幾個，進而引入適當的依賴項。目標系統可能需要安裝這樣的軟體包才能運行您的軟體。
LSB 不再像以前那樣流行，而且許多系統的正式相容性已經減弱，但實際上它可以在相當廣泛的範圍內移植運作。即使一些確實渴望合規性的系統也會錯過一些更模糊的點，但對於常見的目的來說，這通常並不重要（並且相同的程式可能會在以下系統上運行）不嘗試符合 LSB）。
在這種情況下，當其中一個庫發生變化並且我們的應用程式停止工作時，一兩年後會發生什麼？
當您的應用程式停止工作時，您的應用程式將停止運作。這是一個業務流程問題。
我們是否應該將所有這些（libstdc++、glibc 等）與我們的軟體一起分發？
可能不會。特別是對於 libc，在系統上同時使用多個版本時可能會出現執行時間相容性問題。然而，還有其他 libc 實作可能更適合捆綁。
雖然大多數庫都可以成功捆綁，但供應庫通常是維護和安全問題，因此我建議盡可能避免這樣做。如果在庫中發現錯誤或安全缺陷，則在系統上的一個位置更新它（發行版將解決該問題）比跟踪每個副本（並從您那裡獲取替換包！）更容易、更可靠。
作為更實際的步驟，也許可以詢問您的客戶希望它在哪裡運作。你可能過於熱情了。
答案2
在實踐中你需要做一些適用於最常見的 Linux 發行版（和版本）的二進位套件（例如，.deb對於 Debian 和 Ubuntu、 Fedora）。.rpm顯然，您需要為 Fedora 和 Ubuntu 製作不同的軟體包，並且可能需要為 Debian Jessie 和 Ubuntu 16.04 製作不同的軟體包。然而，有時Ubuntu 的軟體包可能會安裝在某些（特定的）Debian 上，反之亦然。
然而，我們還沒有得到任何關於它應該能夠在哪裡運行的具體信息，我的意思是哪個發行版、內核版本或其他任何東西。
您需要與您的客戶討論。
在這種情況下，當其中一個庫發生變化並且我們的應用程式停止工作時，一兩年後會發生什麼？
您需要建立並發布二進制包的更新變體，並且您將為此花費精力（和金錢）。
您可能想要靜態鏈接（如果技術和法律上可行）某些庫（請記住 LGPL 許可證建議動態鏈接，或者能夠在客戶端計算機上靜態重新鏈接）。例如，libstdc++對版本比對版本更敏感，libc因此您可以靜態libstdc++和動態連結libc。事實上YMMV。
請注意，有一些給定係統庫的版本在實踐中可能工作也可能不工作。有些函式庫以特定的方式使用系統資源，因此細節非常重要。
附言。也許您應該與您的客戶進行更多討論並提出製作免費軟體（開源）。有些客戶可能會喜歡這樣。