Які плюси / мінуси боргу проти rpm?

З будь-яких причин я завжди використовував дистрибутиви на основі RPM (Fedora, Centos та на даний момент openSUSE). Я часто чув, як він говорив, що деб краще, ніж обороти в хвилину, але коли його запитують чому, ніколи не змогли отримати цілісну відповідь (зазвичай, замість цього, отримайте ревну рентген та велику кількість плюю).

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

Основна відмінність для сервісного пакета (я думаю, що це було б "розробником" в Debian lingo) полягає в тому, як метадані пакету та супровідні сценарії збираються разом.

У світі RPM всі ваші пакети (RPM, які ви підтримуєте) розміщені у чомусь подібному ~/rpmbuild. Знизу - SPECкаталог ваших специфікаційних файлів, SOURCESкаталог для вихідних тарболів RPMSта SRPMSкаталогів для введення новостворених RPM та SRPM, а також деякі інші речі, які зараз не актуальні.

Все, що має відношення до того, як буде створюватися RPM, знаходиться у специфікаційному файлі: які патчі будуть застосовані, можливі до- та пост-скрипти, метадані, журнал змін і все. Всі вихідні тарілки та всі виправлення всіх ваших пакетів знаходяться в ДЖЕРЕЛАХ.

Зараз особисто мені подобається те, що все переходить у файл специфікації та що файл специфікації є окремим об'єктом від вихідного тарболу, але я не надто захоплений наявністю всіх джерел у ДЖЕРЕЛАХ. ІМХО, ДЖЕРЕЛА забивається досить швидко, і ви, як правило, втрачаєте сліди того, що там є. Однак думки розходяться.

Для РПХ важливо використовувати точно такі ж тарболл як один вгору по течії релізів проекту, аж до тимчасової позначки. Як правило, з цього правила немає винятків. Пакети Debian також вимагають того ж тарболу, що і вище, хоча політика Debian вимагає перепакувати деяких тарболів (спасибі, Umang).

Пакети Debian застосовують інший підхід. (Пробачте тут будь-які помилки: я набагато менш досвідчений з deb, що я з RPM.) Файли розробки пакунків Debian містяться в каталозі на пакет.

Що мені подобається в цьому підході, це той факт, що все міститься в одному каталозі.

У світі Debian трохи більше прийнято носити патчі в пакеті, який ще не є (ще) за течією. У світі RPM (принаймні серед похідних Red Hat) це нахмуриться. Див. "FedoraProject: Близькість до проектів вище" .

Також Debian має величезну кількість скриптів, які здатні автоматизувати величезну частину створення пакету. Наприклад, створення простого пакета встановленої програми Python настільки ж просто, як створення пари файлів метаданих та запуску debuild. Однак, spec-файл для такого пакету у форматі RPM був би досить коротким, і в світі RPM теж багато матеріалів, які автоматизовані в наші дні.

Багато людей порівнюють установки програмного забезпечення з apt-getдо rpm -iі , отже , сказати , DEB краще. Однак це не має нічого спільного з форматом файлу DEB. Реальне порівняння - dpkgvs rpmі aptitude/ apt-*vs zypper/ yum.

З точки зору користувача, різниця в цих інструментах не велика. Формати RPM та DEB - це лише файли архіву, до яких додаються деякі метадані. Обидва вони однаково таємні, мають жорсткі коди встановлення (юк!) І відрізняються лише тонкими деталями. І те, dpkg -iі rpm -iінше не може зрозуміти, як встановити залежності, за винятком випадків, коли вони вказані в командному рядку.

Поверх цих інструментів існує управління сховищами у вигляді apt-...або zypper/ yum. Ці інструменти завантажують сховища, відстежують усі метадані та автоматизують завантаження залежностей. Остаточна установка кожного пакету передається інструментам низького рівня.

Протягом тривалого часу apt-getвін перевершував обробку величезної кількості метаданих дуже швидко, хоча yumце займе віки. RPM також страждав від таких сайтів, як rpmfind, де ви знайдете 10+ несумісних пакетів для різних дистрибутивів. Aptповністю приховав цю проблему для пакетів DEB, оскільки всі пакунки встановлені з одного джерела.

На мою думку, zypperце дійсно закрило прогалину aptі немає підстав соромитися використання дистрибутива на основі RPM в наші дні. Це так само добре, якщо не простіше користуватися послугою збірки openSUSE під рукою для величезного сумісного індексу пакетів.

З точки зору системного адміністратора, я виявив кілька незначних відмінностей, головним чином у наборі інструментів dpkg / rpm, а не у форматі пакету.

• dpkg-divertдає можливість власному файлу витіснити той, що надходить з пакету. Це може бути рятівником, коли у вас є програма, яка шукає файл у файлі /usrабо /libне потребує /usr/localвідповіді. Ідея була запропонована, але, наскільки я можу сказати, не прийнята, у rpm.

• Коли я востаннє керував системами на основі rpm (що, правда, було років тому, можливо, ситуація покращилася), rpm завжди перезаписував би модифіковані файли конфігурації та переміщував мої налаштування в *.rpmsave(IIRC). Це зробило роботу моєї системи хоча б раз. Dpkg запитує мене, що робити, зберігаючи мої налаштування за замовчуванням.

• Бінарний пакет rpm може оголосити залежність від файлів, а не пакунків, що дозволяє отримати більш точний контроль, ніж пакет deb.

• Ви не можете встановити пакет N rpm версії в системі з версією N-1 інструментів rpm. Це може стосуватися і dpkg, за винятком того, що формат не змінюється так часто.

• База даних dpkg складається з текстових файлів. База даних rpm - двійкова. Це робить базу даних dpkg легкою для дослідження та відновлення. З іншого боку, доки нічого не піде не так, обертання в хвилину може бути набагато швидшим (для встановлення дебюту потрібно прочитати тисячі маленьких файлів).

• Пакет Деб використовує стандартні формати ( ar, tar, gzip) , так що ви можете перевірити, і в крайньому випадку підстроювання) пакетів DEB легко. Пакети Rpm не є настільки привітними.

RPM:

• "Стандартизований" (не те, щоб не було специфікації дебюту)
• Використовується багатьма різними дистрибутивами (але пакунки з одного не обов'язково працюють над іншим)
• IIRC дозволяє залежати від файлів, а не лише від пакетів

ДЕБ:

• Зростає популярність
• Дозволяє рекомендації та пропозиції (можливо, новіший RPM дозволяє це також)

Напевно, важливішим питанням є менеджер пакунків (dpkg проти yum проти здатності тощо), а не формат пакету (оскільки обидва порівнянні).

Як сказали декілька респондентів, певний формат пакету явно не найкращий. Технічно вони можуть бути більш-менш порівняними. З моєї точки зору, багато відмінностей, і чому люди віддають перевагу одне одному, пов'язане з:

• Філософія оригінального дизайну упаковки та цільової аудиторії
• Розмір спільноти та за розширенням якість та багатство сховищ

Філософія:

У світі Ubuntu / Debian / Mint / ... користувачі очікують, що встановлений пакет "просто запрацює" після його встановлення. Це означає, що під час встановлення, очікується, що пакети подбають про все необхідне, щоб вони фактично працювали, включаючи, але не обмежуючись ними:

• налаштування необхідних або необов'язкових робочих місць для встановлення
• налаштування альтернатив / псевдонімів
• налаштування сценаріїв запуску / відключення
• включаючи всі необхідні файли конфігурації із за замовчуванням, які мають сенс
• збереження старих версій бібліотек та додавання правильних символьних посилань на бібліотеки (.so) для зворотної сумісності
• чиста підтримка мультиаркових (32 та 64 бітних) двійкових файлів на одній машині тощо.

У світі rpm - правда, така ситуація була кілька років тому, і вона, можливо, покращилася з тих пір - я виявив, що мені потрібно здійснити додаткові кроки (наприклад, chkconfig, що дозволяють виконувати завдання cron), щоб фактично змусити пакети дійсно працювати. Це може бути нормально для сисадмінів або людей, які знають про Unix, але це змушує страждати від новачків. Зауважте, що не в тому, що формат пакету RPM сам заважає цьому не статися, це просто те, що багато пакунків фактично не "повністю зроблені" з точки зору новачка.

Розмір спільноти, участь та багатство сховищ:

Оскільки спільнота ubuntu / debian / mint / ... більше, все більше людей бере участь у упаковці та тестуванні програмного забезпечення. Я визнав багатство та якість сховищ найкращими. В ubuntu мені рідко, якщо взагалі, потрібно завантажувати джерело і створювати з нього. Коли я перейшов з Red Hat на Ubuntu вдома, типовий RHEL repo мав у ньому близько 3000 пакетів, в той же час ubuntu + всесвітня + мультиварка, доступна безпосередньо з будь-якого канонічного дзеркала, мала ~ 30 000 пакетів (приблизно в 10 разів). Більшість пакетів, які я шукав у форматі RPM, були недоступні за допомогою простого пошуку та натискання у менеджері пакетів. Вони потребували переходу на альтернативні сховища, пошук веб-сайту служби rpmfind тощо. Це, в більшості випадків, а не вирішує проблему, зламав мою установку, не вдавшись обмежити, які залежності можна або не можна правильно оновити. Я потрапив на явище "пекло залежності", як описано вище Шоном Дж. Гоффом.

На відміну від Ubuntu / Debian я виявив, що мені майже ніколи не потрібно будувати з джерела. Також через:

• Швидкий цикл випуску Ubuntu (6 місяців)
• Наявність повністю сумісних ППА, які працюють нестандартно
• Єдине джерело сховищ (усі розміщені Canonical) не потребує пошуку альтернативних / додаткових репост
• Безкоштовний користувацький досвід від натискання до запуску

Мені ніколи не доводилося йти на компроміси щодо старих версій пакетів, про які я піклувався, навіть коли вони не підтримувались офіційними (Canonical) розробниками. Мені ніколи не довелося залишати улюбленого дружнього менеджера пакунків GUI, щоб здійснити зручний пошук за ключовими словами, знайти та встановити будь-який пакет, який я хотів. Крім того, кілька разів я встановлював пакети debian (не Canonical) на Ubuntu, і вони працювали чудово, незважаючи на те, що сумісність офіційно не гарантована.

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

Я думаю, що упередження відбувається не від формату пакету, а від невідповідностей, які існували у сховищах RedHat.

Коли ще RedHat був розповсюдженням (до часів RHEL, Fedora та Fedora Core), люди іноді опинялися в "Пекло RPM" або "Пекло залежності". Це сталося, коли сховище закінчилось пакетом, який мав залежності (зазвичай кілька глибоких шарів), які взаємно виключали. Або виникне, коли два різні пакети мали дві взаємовиключні залежності. Це була проблема зі станом сховища, а не з форматом пакета. "Пекло RPM" залишило неприємність для систем RPM серед деякої кількості користувачів Linux, які отримали опік від цієї проблеми.

Існує також "філософська" різниця, де в пакунках Debian можна задавати питання і цим блокувати процес встановлення. Погана сторона цього полягає в тому, що деякі пакети будуть блокувати ваші оновлення, поки ви не отримаєте відповідь. Хороша сторона цього, як філософська різниця, в системах на базі Debian, коли встановлений пакет, він налаштовується (не завжди так, як вам хотілося) і працює. Не в системах на базі Redhat, де потрібно створити / скопіювати з / usr / share / doc / * файл конфігурації за замовчуванням / шаблон.

Одне, що мені подобається в RPM, - це (недавнє?) Додавання дельта-оборотів. Це дозволяє простіше оновлювати, зменшуючи необхідну пропускну здатність.

ДЕБ - це стандартні файли ar (з більш стандартними архівами всередині), RPM - це "власні" двійкові файли. Я особисто думаю, що колишньому зручніше.

Тільки дві речі, які я можу придумати вгорі голови. Обидва дуже порівнянні. Обидва мають чудові інструменти для упаковки. Я не думаю, що є стільки достоїнств одне над іншим чи навпаки.

Служба openSUSE Build Service (OBS) та блискавка - це причина, з якої я віддаю перевагу RPM над дебютом з точки зору пакувальника та користувача. Блискавка пройшла довгий шлях і досить швидко бовтається. OBS, хоча він може обробляти налагодження, дійсно приємно, коли справа стосується упаковки RPM для різних платформ, таких як openSUSE, SLE, RHEL, centos, fedora, mandriva тощо.

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

Ось досить хороша довідка для порівняння деяких конкретних функцій, які доступні для кожного конкретного формату упаковки: http://debian-br.sourceforge.net/txt/alien.htm (за даними веб-сервера, цей документ є досить старим : Остання зміна: Вс, 15 жовтня 2000, тому це може бути не найкращим посиланням.)

Для пакунків Debian є великий набір допоміжних сценаріїв, послідовний посібник з політики та принаймні один спосіб робити практично все. Залежності обробляються дуже добре і їх можна визначити дуже добре. Повторне створення пакунків дуже просто за допомогою пакунків debian і добре підтримується наявними інструментами.

Жоден з інших відповідей не стосується того, як наступні три основні відмінності мають реальні наслідки:

1. debФайли - це лише arархіви, що містять дві стислі тарболи
2. debпакунки та dpkgсистема зберігають ваші сценарії підтримки, як окремі файли
3. dpkgта rpmпід час оновлення запустіть сценарії підтримки в іншому порядку.

Разом ці відмінності значно полегшили мені виправити проблеми, спричинені поганими пакунками, і змусити пакети вести себе так, як мені потрібно, на debсистемах на rpmбазі, ніж на системах, що базуються, і як системний адміністратор, і як пакувач .

Через номер 1, якщо мені потрібно змінити debфайл, я можу тривіально відкрити його, внести будь-які зміни, які я хочу, і перепакувати його, використовуючи стандартні інструменти, які існують у більшості систем .

Сюди входить зміна / додавання / видалення будь-яких залежностей, будь-яких файлів пакету, будь-якого сценарію технічного обслуговування або зміна версії або назви пакета.

З-за №2, якщо в скрипті "видалити", встановленому вже встановленим пакетом , є проблема , я можу тривіально її виправити, використовуючи стандартні інструменти, які існують у будь-якій системі .

Через # 3 я можу виконати деякі з цих виправлень, лише випустивши нову версію свого пакету, оскільки під час оновлення dpkgзапускає сценарій "перед встановленням" нової версії пакета перед сценарієм "видалити" стара версія.

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

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