Чому я не можу встановити кілька версій спільної бібліотеки?

Часто трапляються випадки, коли певна програма буде залежати від версії бібліотеки xy, а інша - від xz, але, наскільки мені відомо, жоден менеджер пакунків не дозволить мені встановити і xy, і xz. Іноді вони дозволять обидві основні версії (наприклад, qt4 і qt5, які можна встановити одночасно), але (здавалося б) ніколи не другорядні версії.

Чому це? Як у, що є обмежуючим фактором, який перешкоджає цьому? Я припускаю, що має бути вагома причина, щоб не дозволяти цей, здавалося б, корисний функціонал. Наприклад, чи не існує поля, яке б вказувало, яку версію завантажувати під час завантаження спільного об'єкта, і, отже, Linux не може знати, як вирішити, яку завантажувати? Або справді немає причини для цього? Як і всі незначні версії повинні бути сумісними так чи інакше?

Насправді ви можете встановити кілька версій спільної бібліотеки, якщо це зроблено належним чином.

Спільні бібліотеки зазвичай називають так:

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

Далі є бібліотечні посилання на такі назви:

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

Коли розробник посилається на бібліотеку для створення бінарного файлу, саме ім'я файлу закінчується тим, .soщо лінкер знаходить. Дійсно, може бути лише один із встановлених одночасно для будь-якого даного, <name>але це означає лише, що розробник не може одночасно націлювати на різні версії бібліотеки. З менеджерами пакунків ця .soсимвольна посилання є частиною окремого -devпакету, який потребують лише встановлення розробників.

Коли лінкер знаходить файл із закінченим іменем .soі використовує його, він шукає всередині цієї бібліотеки поле, яке називається soname . Soname радить лінкеру, яке ім'я файлу вбудувати в отриманий бінарний файл, і таким чином, яке ім'я файлу буде шукати під час виконання. Ім'я, як передбачається, буде встановлено lib<name>.so.<api-version>.

Тому під час виконання динамічний лінкер буде шукати lib<name>.so.<api-version>і використовувати це.

Намір полягає в тому, щоб:

• <minor>оновлення не змінюють API бібліотеки, і коли <minor>натрапляють на більш високу версію, можна дозволити всім бінарним файлам оновити до нової версії. Оскільки бінарні файли шукають бібліотеку під lib<name>.so.<api-version>назвою, яке є посиланням на останню встановлену версію lib<name>.so.<api-version>.<minor>, вони отримують оновлення.
• <api-version>оновлення змінюють API бібліотеки, і не безпечно дозволяти існуючим бінарним додаткам використовувати нову версію. У випадку, якщо <api-version>значення змінено, оскільки ці програми шукають ім'я, lib<name>.so.<api-version>але мають інше значення для <api-version>, вони не підберуть нову версію.

Менеджери пакетів часто не пакують більше однієї версії однієї бібліотеки в межах однієї версії дистрибуції, оскільки весь дистрибутив, включаючи всі бінарні файли, які використовують бібліотеку, зазвичай складається для використання послідовної версії кожної бібліотеки до розповсюдження. звільнений. Переконання в тому, що все є послідовним і що все в дистрибутиві сумісне з усім іншим, є великою частиною навантаження для дистриб'юторів.

Але ви можете легко створити декілька версій бібліотеки, якщо ви оновили свою систему з однієї версії вашої дистрибуції до іншої та все ще маєте кілька старих пакетів, для яких потрібні старіші версії бібліотеки. Приклад:

• libmysqlclient16 зі старої Debian, містить libmysqlclient.so.16.0.0і посилання libmysqlclient.so.16.
• libmysqlclient18 від поточного Debian, містить libmysqlclient.so.18.0.0і посилання libmysqlclient.so.18.

Ця функціональність не заборонена, вона просто не дуже поширена внаслідок роботи більшості бібліотек і через незручності зміни назви пакетів.

Якщо застосовується пунктирна схема номера версії XYZ "Мікро" версія Z часто змінюється на виправленнях, "другорядне" число Y змінюється на зворотні сумісні зміни, а "основне" число версії X повинне змінюватися на змінах API (а іноді і на основні додаткові функціональні можливості).

Ніколи не повинно бути причин того, що ви не хочете, щоб виправляли останні помилки, а зворотні сумісні зміни також не повинні порушувати ваше програмне забезпечення.

Якщо бібліотека розроблена таким чином, ви завжди зможете замінити XYZ на X. (Y + m). (Z + n). для будь-яких заданих m і n. Тобто ви завжди повинні мати можливість замінити свою бібліотеку на останню з тієї ж великої серії номерів. І якщо розробники бібліотек обережні, і наступне основне число сумісне (наприклад, за допомогою оголошення про зняття речей, але не видалення їх ще), ви навіть можете використовувати наступне основне число.

Для розробників пакетів це означає, що вони можуть використовувати ім'я лише з одним, а то й без імені з номером, щоб дати вам останню версію, просто оновивши пакет. Якщо вони доставляють бібліотеку в пакеті, abc2вони повинні пройти обручі, щоб перемістити власне програмне забезпечення, яке покладалося на abc2оновлення до використання abc3, іноді з перехідними пакетами. Більш зручно залишати основний номер версії з бібліотеки, якщо це працює для більшості залежних пакетів. Тож навіть якщо обидва abc2і abc3повинні бути доступні в якийсь момент, доступний у дистрибутиві, abc3його часто називають abc(так само, як abc2називалося, коли ще не abc3було), і як тільки жодні пакети не залежать від abc2дистрибутиву, стає можливим скиданняabc2 взагалі.

Схеми нумерації не дотримуються рівномірно, але я можу лише уявити, що з появою в Інтернеті поширюється інформація про те, як використовувати таку схему, і тиск з боку користувачів бібліотеки (включаючи розробників дистрибутивів) зробити чіткими важливі речі, такі як зворотна сумісність прочитавши файл ЗМІНИ, що входить до бібліотеки, це сприяло тому, що це стало більш поширеним.

Одним із прикладних зустрічних прикладів, але не для бібліотеки, є інтпретер python, який не сумісний у спільних об'єктах та форматі маринування при незначній зміні числа. Тому ви побачите пакунки для python (останній у серії 2.7) та python3 (останній у поточній серії серії python3.4), а також явні пакети для python 2.6 (не менш поширені), а також python 3.3.