Назва дистрибутива, glibc чи компілятор: що перевіряє інсталятор
Інсталятор, який відхиляє ваш похідний дистрибутив, може читати назву дистрибутива, версію середовища виконання або компілятор. Лише одне з них вирішує, чи зможе бінарний файл працювати.
Інсталятор друкує “unsupported distribution”, ви правите один рядок, і він продовжує, доки за хвилину не впаде з помилкою завантажувача. Ця послідовність і є симптом, який варто розпізнавати: перша невдача була перевіркою розпізнавання, а друга — межею сумісності. Це дві різні проблеми, що випадково опинилися в одному терміналі. Правка перевірки може лише перенести вас від першої до другої.
Симптом: інсталятор зупиняється на вашому похідному дистрибутиві
Скрипт, який читає назву дистрибутива і відмовляється продовжувати, повідомляє вам, що його автор не тестував ваш похідний дистрибутив. Це заява про підтримку, а не технічний факт, і часто вона помилкова в тому сенсі, що пакунок чудово працював би.
Біда починається, коли обхідний шлях стає планом. Правка файлу ідентичності пропускає перевірку, і пакунок потім завантажується або не завантажується проти того середовища виконання, яке справді встановлене. Якщо там він падає, жодна подальша правка ідентичності не допоможе.
Тому корисний крок — з'ясувати, яке питання поставив інсталятор, а потім з'ясувати, чи мала б відповідь значення. Це два окремі дослідження, і лише друге передбачає, чи працюватиме пакунок.
Три версії, які люди називають версією системи
Випуск дистрибутива називає упаковане середовище. Версія бібліотеки C називає реалізацію середовища виконання та її випуск. Версія компілятора називає ланцюжок інструментів. У розмові люди називають усі три “версією системи”, але в інсталяторі вони не взаємозамінні.
cat /etc/os-release ldd --version | head -1 gcc --version | head -1 uname -m
Заздалегідь зібраний застосунок розраховує на середовище виконання, яке було під час його компонування. Заміна компіляторів на хості не перекомпоновує його, а новіший ланцюжок інструментів нічого не змінює в символах завантажувача, які запитує бінарний файл. Архітектура знову важлива окремо, бо 32-бітний пакунок у 64-бітній системі падає з причин, яких не пояснює жоден рядок версії.
Збережіть чотири виводи разом зі звітом. Їхній збір займає десять секунд, і вони відповідають на більшість питань, які супровідник інакше поставив би вам поштою.
Читайте помилку, а не перевірку
Перша помилка запуску — це доказ. Повідомлення про відсутній спільний об'єкт або про версію символу, яку завантажувач не може задовольнити, — це проблема залежності від середовища виконання. Повідомлення, що повторює назву дистрибутива, — це знову перевірка розпізнавання, в іншому місці.
документація динамічного компонувальника описує, як працює пошук бібліотек і де шукає завантажувач. Правка мітки дистрибутива не додає каталог до цього шляху пошуку, тому друга невдача виглядає не пов'язаною з першою.
Не хапайтеся за ldd на завантаженому виконуваному файлі як за звичайний перший крок. Його власний посібник попереджає, що за деяких обставин він може виконати програму, а запуск недовіреного інсталятора — це саме той випадок, про який це попередження.
Чому правка рядка не допомагає
Фальсифікація ідентичності операційної системи змінює те, як кожна програма на машині бачить себе. Менеджери пакунків, інструменти підтримки та інші застосунки читають той самий файл, і значення, яке задовольняє один інсталятор, може через місяці заплутати щось інше.
Заміна бібліотек хоста файлами з іншого дистрибутива гірша. Вона може зламати стороннє програмне забезпечення, вона невидима для менеджера пакунків, і їй потрібен план обслуговування, якого ніхто не пише. Ці зміни не виправдати одним обмежувальним інсталятором.
Якщо перевірка справді є дефектом розпізнавання, супровідник може це підтвердити й описати підтримуване виправлення. Якщо це не дефект, підтримуваний шлях — збирання для вашої платформи, і ця відповідь не змінюється від того, що рядок відредагували.
Напишіть звіт, за яким супровідник зможе діяти
Запишіть дистрибутив і випуск, архітектуру, випуск VPN, точну умову, яку було відхилено, і першу помилку середовища виконання, якщо ви дійшли до неї. Зазначте, чи ви щось змінювали, бо звіт із зміненої системи — це інший звіт.
Залиште початковий інсталятор без змін і опишіть перевірку замість того, щоб обходити її. Ця різниця дозволяє супровіднику відокремити надто вузьке правило розпізнавання від справжньої межі бінарної сумісності, а це дві дуже різні помилки з двома дуже різними виправленнями.
Якщо відповідь буде, що ваша платформа не підтримується, це придатний результат. Він каже шукати підтримуване збирання замість того, щоб провести ще один вечір над файлами ідентичності, які ніколи не були проблемою.