Mengapa saya tidak bisa menginstal beberapa versi dari perpustakaan bersama?

Sering ada contoh di mana program tertentu akan bergantung pada versi perpustakaan xy dan yang lain pada xz tetapi, sejauh yang saya ketahui, tidak ada manajer paket yang mengizinkan saya untuk menginstal xy dan xz Kadang-kadang mereka akan mengizinkan kedua versi utama (seperti qt4 dan qt5, yang dapat diinstal pada saat yang sama), tetapi (sepertinya) tidak pernah versi kecil.

Kenapa ini? Seperti apa, faktor pembatas apa yang mencegahnya? Saya berasumsi pasti ada alasan kuat untuk tidak mengizinkan fungsi yang tampaknya bermanfaat ini. Misalnya, apakah tidak ada bidang untuk menunjukkan versi apa yang akan dimuat saat memuat objek bersama dan dengan demikian tidak ada cara bagi Linux untuk mengetahui cara memutuskan mana yang akan dimuat? Atau benar-benar tidak ada alasan untuk itu? Seperti semua versi minor yang seharusnya kompatibel pula atau apa?

Sebenarnya, Anda dapat menginstal beberapa versi dari perpustakaan bersama jika itu dilakukan dengan benar.

Pustaka bersama biasanya dinamai sebagai berikut:

lib<name>.so.<api-version>.<minor>

Berikutnya, ada symlink ke perpustakaan dengan nama-nama berikut:

lib<name>.so
lib<name>.so.<api-version>

Ketika pengembang menautkan ke perpustakaan untuk menghasilkan biner, itu adalah nama file yang diakhiri dengan .sotautan itu ditemukan. Memang hanya ada satu dari mereka yang diinstal pada waktu tertentu, <name>tetapi itu hanya berarti bahwa pengembang tidak dapat menargetkan beberapa versi perpustakaan yang berbeda secara bersamaan. Dengan manajer paket, .sosymlink ini adalah bagian dari -devpaket terpisah yang hanya perlu diinstal oleh pengembang.

Ketika linker menemukan file dengan nama yang diakhiri .sodan menggunakannya, itu akan mencari di dalam perpustakaan itu bidang yang disebut soname . Soname menyarankan linker apa nama file yang akan dimasukkan ke dalam biner yang dihasilkan dan dengan demikian nama file apa yang akan dicari saat runtime. Soname seharusnya diatur ke lib<name>.so.<api-version>.

Oleh karena itu, pada saat dijalankan, penghubung dinamis akan mencari lib<name>.so.<api-version>dan menggunakannya.

Maksudnya adalah:

• <minor>pemutakhiran tidak mengubah API perpustakaan dan ketika <minor>ditabrak ke versi yang lebih tinggi, aman untuk membiarkan semua binari memutakhirkan ke versi yang baru. Karena semua binari mencari pustaka dengan lib<name>.so.<api-version>nama, yang merupakan symlink ke instal terbaru lib<name>.so.<api-version>.<minor>, mereka mendapatkan pemutakhiran.
• <api-version>pemutakhiran mengubah API perpustakaan, dan tidak aman untuk membiarkan aplikasi biner yang ada menggunakan versi baru. Dalam hal <api-version>ini diubah, karena aplikasi tersebut mencari nama lib<name>.so.<api-version>tetapi dengan nilai yang berbeda <api-version>, mereka tidak akan mengambil versi baru.

Pengelola paket tidak sering mengemas lebih dari satu versi dari perpustakaan yang sama dalam versi distribusi yang sama karena seluruh distribusi, termasuk semua binari yang menggunakan perpustakaan, biasanya dikompilasi untuk menggunakan versi yang konsisten dari setiap perpustakaan sebelum distribusi dilakukan. dilepaskan. Memastikan bahwa semuanya konsisten dan bahwa segala sesuatu dalam distribusi kompatibel dengan yang lain adalah bagian besar dari beban kerja untuk distributor.

Tetapi Anda dapat dengan mudah berakhir dengan beberapa versi perpustakaan jika Anda telah memutakhirkan sistem Anda dari satu versi distritution Anda ke yang lain dan masih memiliki beberapa paket yang lebih lama yang membutuhkan versi perpustakaan yang lebih lama. Contoh:

• libmysqlclient16 dari Debian yang lebih lama, berisi libmysqlclient.so.16.0.0dan symlink libmysqlclient.so.16.
• libmysqlclient18 dari Debian saat ini, berisi libmysqlclient.so.18.0.0dan symlink libmysqlclient.so.18.

Fungsionalitas ini tidak dianulir, itu hanya tidak sangat umum sebagai hasil dari cara kebanyakan perpustakaan penomoran bekerja dan karena ketidaknyamanan perubahan nama paket.

Jika penggunaan skema nomor versi bertitik XYZ Versi "mikro" Z sering berubah pada perbaikan bug, "minor" angka Y berubah pada perubahan yang kompatibel ke belakang dan versi "utama" nomor X harus berubah pada perubahan API (dan kadang-kadang tidak pada fungsi tambahan utama).

Seharusnya tidak pernah ada alasan bahwa Anda tidak ingin memiliki bug terbaru diperbaiki, dan perubahan kompatibel juga tidak boleh merusak perangkat lunak Anda.

Jika perpustakaan dikembangkan dengan cara itu Anda harus selalu dapat mengganti XYZ dengan X. (Y + m). (Z + n). untuk setiap m dan n yang diberikan. Yaitu Anda harus selalu dapat mengganti perpustakaan Anda dengan yang terbaru dalam seri nomor utama yang sama. Dan jika pengembang perpustakaan berhati-hati dan nomor utama berikutnya kompatibel (misalnya dengan pengumuman untuk menghapuskan hal-hal, tetapi belum menghapusnya) Anda bahkan dapat menggunakan nomor utama berikutnya.

Untuk pengembang paket, ini berarti mereka dapat menggunakan nama hanya dengan satu, atau bahkan tanpa nama nomor untuk memberi Anda versi terbaru dengan hanya memperbarui paket. Jika mereka kapal perpustakaan dalam sebuah paket abc2maka mereka harus melalui rintangan untuk memindahkan perangkat lunak mereka sendiri yang mengandalkan pada abc2meng-upgrade ke penggunaan abc3, kadang-kadang dengan paket transisi. Lebih mudah untuk meninggalkan nomor versi utama dari perpustakaan jika itu berfungsi untuk sebagian besar paket tergantung. Jadi, bahkan jika keduanya abc2dan abc3harus tersedia di beberapa titik yang tersedia dalam distribusi, abc3sering disebut abc(sama seperti abc2dipanggil ketika abc3belum ada), dan begitu tidak ada paket tergantung pada abc2dalam distribusi itu menjadi mungkin untuk turunabc2 sama sekali.

Skema penomoran tidak diikuti secara seragam, tetapi saya hanya bisa membayangkan bahwa dengan munculnya internet menyebarkan informasi tentang cara menggunakan skema tersebut, dan tekanan dari pengguna perpustakaan (termasuk pengembang distribusi) untuk membuat hal-hal penting seperti kompatibilitas mundur jelas tanpa harus membaca file PERUBAHAN yang termasuk dalam perpustakaan, telah berkontribusi bahwa ini telah menjadi lebih umum.

Salah satu contoh counter, tetapi bukan dari perpustakaan adalah python intpreter, yang tidak kompatibel pada objek yang dibagikan dan format pengawetan pada perubahan angka minor. Oleh karena itu Anda akan melihat paket untuk python (yang terbaru dalam seri 2.7), dan python3 (yang terbaru dalam seri python3.4 saat ini) serta paket eksplisit untuk python 2.6 (tidak semakin umum) serta python 3.3.