Мені цікаво, чи теоретично можливо побудувати дистрибутив Linux, який може підтримувати rpm та пакети debian.

Чи є там дистрибутиви, які підтримують обох?

А якщо ні, то це навіть можливо?

Bedrock Linux робить це. Не кажучи, що я це зробив, або що це гарна ідея, але це робиться.

Я не думав, що там існують дистрибутиви, які підтримують як вроджене, але виявляється, що в розробці є такий, Bedrock Linux (спасибі iMalinowski за інформацію). В інших дистрибутивах можна використовувати такі інструменти перетворення, як alienконвертація з одного формату в інший. Будь-яка програма, що базується на програмному забезпеченні, є достатньою, враховуючи достатньо часу та енергії, тому можна було б побудувати такий розподіл (але, враховуючи відмінності між можливостями .debта .rpmпакетами, досить складно).

Однак все це, мабуть, випливає з ідеї, що підтримка обох форматів пакунків полегшить життя, адже ви потім зможете встановлювати пакунки з будь-якого місця (ну, де б не було .debабо .rpm). По-філософськи це хибно. Розподіл - це цілісний набір пакетів; якщо ви хочете надати програмне забезпечення для цього розповсюдження, вам дійсно потрібно націлити його конкретно, що включає використання його формату пакета (і що ще важливіше - метадані). Немає сенсу підтримувати декілька форматів пакетів на самому рівні.

(У світі Debian пакети можуть працювати на варіантах, які не є їх основною ціллю, тому що номенклатура пакетів досить однорідна і через те, що більшість дистрибутивів вміщуються в дерево спадкування. Це не вірно в світі RPM. В обох випадках змішування та відповідність - погана ідея.)

Ви повинні розглядати свій розподіл як базу, на якій можна побудувати бажану систему, дотримуючись правил та екосистеми вашого розповсюдження, не змішуючи речей з іншими дистрибутивами. Вам потрібні абстракції вищого рівня для підтримки змішування та узгодження (а точніше, для забезпечення середовища перехресного розподілу): час роботи Steam, Flatpak тощо.

Ні, такого монстра не слід будувати. На відміну від, скажімо, пакету додатків MacOS, який, як правило, включає все, що потрібно для запуску операційної системи, пакети RPM та .deb майже завжди залежать від інших пакетів, таких як спільні бібліотеки. Пакети Linux перелічують інші пакети, які потрібно присутні, а менеджер пакунків допомагає виконувати ці вимоги. Крім того, дистрибутиви Linux відрізняються тим, як це робиться (наприклад, /etc/network/interfaces.dпроти /etc/sysconfig/network-scripts).

Ви навіть не повинні змішувати пакети з довільних сховищ у межах однієї групи форматів пакетів. Тобто, встановлення пакетів SuSE на машину CentOS просто задає проблеми, хоча вони обидва використовують RPM. Я навіть не встановлював пакети, призначені для іншої версії тієї ж ОС (наприклад, пакети Ubuntu 14.04 в системі 16.04), якщо я точно не знав, що я роблю.

Отже, намагатися підтримувати і RPM, і .deb в одній системі, не виникає сумніву. У певних відчайдушних ситуаціях ви можете конвертувати конкретні пакети, використовуючи alien, але слід розраховувати докласти чимало зусиль для усунення неполадок, які неминуче виникатимуть від таких хаків.

Ну, є alien( чоловік сторінка ), який може конвертувати між rpm, і debт.д., але я припускаю , що фактичні проблеми виникають від обробки залежностей (різні назви пакунків для програмного забезпечення), а також розташування файлів конфігурації.

Звичайно, якщо ви маєте на увазі, що обидва типи пакунків можуть надходити від самої дистрибуції, це, можливо, може бути розроблено, але тоді навіщо хтось це робити ... , оскільки я не думаю, що dpkgвміє читати бази даних rpmі навпаки.)

Так, це можливо, але це руйнує розподіл.

Пакети - це не просто той формат, який легко переноситься з одного формату в інший.

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

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

У Debian ми хочемо, щоб пакунки легко складалися користувачами (з джерел), щоб можна було налаштувати деякі важливі (для нього) пакети. Для цього потрібна велика інфраструктура, яку більшість авторів на початку потоку не може забезпечити (автоматична побудова та тестування на різних архітектурах, що робиться час від часу). А також специфічні для Debian вимоги до ліцензії, так що легше роздрібнити пакет чи розповсюдження, не потрібно перевіряти всі пакунки.

Зрештою, розподіл здійснюється послідовними пакетами, а не лише пакетами.

Так, і більшість дистрибуторів на основі .deb вже це роблять, але ...

Принаймні, у Debian та суміжних родинах у вас є alien, що дозволить вам встановлювати RPM-пакети.

У вас виникнуть ті самі проблеми, коли ви змішуєте пакети, які не розроблені для роботи з вашим дистрибутивом, коли ви встановлюєте закордонні пакети незалежно від формату - якщо ви встановлюєте RPM в системі на базі DEB, цей RPM повинен бути сумісним з вашою системою , як би ви встановлюєте пакет RPM в системі на основі RPM, і це але. Ти можеш це зробити, але цього, мабуть, не хочеш.

Так і ні. deb і rpm - лише формати. Ви можете підтримувати обидва формати, але безглуздо. Пакети, як правило, не можна порівняти між дистрибутивами, особливо дистрибутивами, які не базуються один на одному.

Якби всі дистрибутиви мали однакові вимоги до версії, то все розповсюдження було б вибором пакета. Ви можете встановити будь-який дистрибутив, перерахувавши пакети.

Але дистрибутиви повинні забезпечувати програмне забезпечення, яке вони можуть підтримувати. Якщо бібліотека, яка робить вашу програму роботи, не підтримується і сама вимагає бібліотеку, яку було замінено чимось іншим, як ви вирішите цей конфлікт? Менеджер пакунків не може портувати код. У різних дистрибутивах може бути обрано декілька наступників.