Deb пакети використовуються в таких популярних дистрибутивах, як Debian і Ubuntu. На відміну від різних RPM-base дистрибутивів структура цих пакетів анітрохи не відрізняється один від одного. З цього буде зовсім не складно пересобрать пакет з одного дистрибутива під інший.
Deb-пакет являє собою gzip-архів, а також скрипти і додаткові файли. Ось типовий приклад назви пакета:
Як ми бачимо ім'я пакета відділяється від версії символом підкреслення, також як і архітектура пакета. Через символ "-" вказується певна подоба release, хоча точного поняття, як в RPM для нього не існує.
Архітектури бувають i386 (як в rpm), amd64 (64-х бітний пакет, названий на честь перших процесорів AMD), all (теж що noarch в RPM, незалежний від архітектури), powerpc, а також різні екзотичні архітектури, які я наводити не буду.
Думаю буде корисно провести деякий поверхневе порівняння RPM і DEB. Відмінностей багато, однак з боку кінцевого користувача вони будуть не так помітні. Взагалі коли за нас хтось все робить (причому якісно), все добре. Як тільки ми починаємо намагатися робити щось самі - все погано.
Отже, найвідомішою відмінною рисою Deb є наявність м'яких залежностей (Recomends і Suggest). Багато користувачів бачать в цьому надприродну силу і міць DEB, хоча що з цими залежностями робити далі, ймовірно, вони не знають. Apt-get не вміє обробляти їх, Aptitude вміє за допомогою двох опцій в налаштуваннях apt:
У будь-якому випадку в м'які залежності прописуються пакети, без яких наш пакет працювати буде в будь-якому випадку. І на мій погляд абсолютно все одно жорстка залежність або м'яка, так як ми або ставимо все пакети з Recomends або Suggest, або не ставимо нічого, або система буде чистенька з урізаними функціями деяких пакетів, або брудненька з купою всіляких пакетів.
Другим корисним відмінністю є можливість вказівки в залежностях логічного або.
В RPM подібна проблема виправлялася додаванням Provides в пакет, від якого залежить збирається пакет. Однак набагато простіше зробити так, як це робиться в DEB.
Ще в якості корисності можна виділити ось що. Всі скрипти і службові файли лежать в каталозі / var / lib / dpkg / info /. Так що ми можемо швидко на них поглянути, а не мучиться з різними командами.
Власне на цьому все. За Deb пакету не можна визначити на якій машині він був зібраний, у пакета немає різних макросів, як в RPM.
Загалом як видно, переваги і недоліки одного та іншого досить сумнівні. Але це тільки по відношенню до кінцевого користувача. Як тільки ми починаємо збирати свій власний пакет (майже з нуля), недоліки Deb стають більш очевидними.
До них можна віднести:
- Безліч файлів конфігурації (проти 1-го spec у rpm);
- Безліч службових dh_ * команд, які не зовсім зрозуміло що роблять;
- Исходник йде не одним файлом, а 2-а, 3-я;
- Складність в накладанні патчів;
- Можливість робити одне і теж кількома різними способами.
Внутрішній мову dh_make теж не робить збірку особливо привабливою.
Окремо хочеться сказати про цифровий підпис до пакету. Сам Deb пакет, на відміну від RPM, не підписується, а підписуються різні текстові файли, що містять контрольні суми. В остаточному підсумку все доходить до підпису Release.gpg в репозиторії. Так що якщо ви якимось чином підсуне в головний репозиторій лівий пакет, то ідентифікувати його справжність буде неможливо. Більш того, зазвичай для підпису самого сховища використовується ключ з порожнім паролем.
Хоча пакети для Debian і Ubuntu і лежать всі в одному місці, але через різні репозиторіїв і системи pool знайти що-небудь буває складно. Я рекомендую скористатися відповідно сайтами packages.debian.org і packages.ubuntu.com. На них ви зможете легко зрозуміти до якого дистрибутива, який пакет належить.
У наступній частині ми поговоримо про збірку Deb-пакетів.
Сторінка 1 з 1 1