Відмінності в управлінні пакунками між Debian і Arch


9

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

Чи можете ви також зазначити гнучкість / потужність між двома менеджерами пакетів: який із двох дозволяє зробити більше.

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


ПРИМІТКА . Під керуванням пакетом Debian я маю на увазі APT, здатність та dpkg. Я не знайомий з інструментами Arch, тому не знаю, чи є щось інше, ніж Pacman.
thepang

Відповіді:


7

Я просто використовую арку з декількох тижнів, і я не є експертом з цього питання, тому ця відповідь аж ніяк не є вичерпною, лише кілька пунктів, які я зазначив про "гнучкість / потужність":

  • Це лише враження, але Pacman здається більш сучасним та простим у своєму дизайні / архітектурі. Принаймні, набагато менше інструментів для боротьби. Хоча я не знаю підходящого вихідного коду, я просто трапився подивитися на libalpm-код (базову бібліотеку для pacman), щоб зробити дуже простий патч, і він здається чистим і легким для розуміння.

  • Це також дуже швидко (за рахунок оптимізації, а також, ймовірно, через турботу про мало речей (див. Нижче)). Останній реліз (pacman 3.5, кілька днів) намагався покращити продуктивність, зменшивши кількість залучених файлів баз даних.

  • Хоча арка орієнтована на використання бінарних пакетів, вона також має переваги при складанні пакетів з джерела, із системою складання, подібною до портів BSD (ABS).

  • Створювати пакети дуже просто і швидко, лише кілька рядків у файлі PKGBUILD і його виконано, не потрібно мати справу з контролем / правилами / авторськими правами / журналом змін / що завгодно з пакетами Debian. І за декілька кліків у веб-інтерфейсі ваш пакет надається всім користувачам AUR (Arch User Repository).

Речі, які я отримую в Debian, а не в арці:

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

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

  • підписання пакету (здається, над цим працює ).

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


Я не можу розібратися в цьому: але я можу обійтися без цього і до речі знати, що мені робити краще . Також є друкарська помилка останнього речення.
thepang

На якій мові написаний менеджер пакунків Pacman? Чи має функція управління пакетами низького та високого рівня схожа на dpkg / apt, і якщо так, то як вони називаються?
Faheem Mitha

@Tshepang: вибачте, тут не говорять нерічні англійські. Я мав на увазі "для мене це не велика справа, якщо я не маю цієї функціональності (debconf), і, змушуючи мене робити речі вручну, це змушує мене знати, що саме робиться".
gentledevil

@Faheem Mitha: Pacman написаний на мові C, і це фронт до libalpm, який обробляє і управління пакетами "високого рівня" та "низького рівня".
gentledevil

@zanko: Я також не є носієм мови. Все, що я хотів, щоб ви зробили це зробити вирок більш чітким, і не в коментарі, а в самій публікації. До речі, помилка, про яку я згадав, є опціональною . Я міг би сам відредагувати публікацію, але я подумав, що ви можете виправити це разом із роз'яснювальною частиною.
thepang

6

Я розпочав свою подорож по Linux з Lucid Ubuntu, і зараз використовую Arch. Я написав кілька пакунків Arch, і я скажу, що це набагато простіше, ніж писати пакети Debian. Але я хотів би зазначити @gentledevil, що Arch має систему гачків для пакетів, відому як install file.

В основному, його назва ${pkgname}.installі містить кілька функцій для встановлення / видалення / оновлення до / після публікації; просто помістіть оновлення кеш-шрифту в це і так далі, і воно працює приблизно так само, як гачки Debian.

Також я помічаю, що ви згадали про "закріплення" програми за допомогою інструментів управління пакетами debian; Пакман Arch має і цей вбудований, він /etc/pacman.confприймає ряд налаштувань, в тому числі IgnorePkg =, які запобігатимуть оновлення до будь-яких пакетів, перелічених після рівних (обмежено пробілом)


1
Крім того, хоч це не репо-пакет, ви можете використовувати powerpillобгортку для pacman для паралельного завантаження декількох пакетів, тому замість того, щоб pacman -S libfoo libbar libbazзавантажувати кожен пакет один за одним, замість цього він завантажував би всі три одночасно, значно збільшуючи швидкість оновлення для кращих з'єднань.
hanetzer

-1

Перш ніж зайти занадто далеко, вивчіть Pictorial Linux Timeline

Щоб зрозуміти відмінності у менеджерах пакунків, ви повинні зрозуміти філософії ОС, зображених вище


Три основні батьки

  1. Redhat, тепер Fedora - управління пакетами - RPM, скорочення Redhat Package Manager, командний рядок rpm
  2. Slackware - Менеджер пакунків - tgz, звичайні файли-блискавки. Хоча це лише стислі файли, вони були побудовані Slackware вище за течією та розміщені у сховищі, яке іноді називають портом
  3. Debian - DEB, скорочення для Debian, це інструмент командного рядка Aptitude or Apt

Ці Батьки є мамами та батьками більшості розподілів, про які ми знаємо сьогодні. Ідея / концепція системи управління пакунками була виведена або поділена в якійсь формі або способі. Незалежно від того, всі ці батьки є бінарними дистриб'юторами, це означає, що програма упаковується та визначається третьою стороною, потім зберігається у сховищі та споживається або встановлюється базою користувачів.

3 неповнолітні батьки

  1. Linux From Scratch - На основі джерел, немає менеджера пакунків.
  2. Gentoo - Отриманий з Linux від Scratch . Цей розподіл по суті є Linux від Scratch плюс менеджер пакунків, який називається Portage / emerge
  3. SourceMage - Волшебство менеджера пакунків

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

Міст

Арка була створена як міст між бінарним розподілом, як один із 3 основних батьків, та розподілом на основі джерела, як один із 3 неповнолітніх батьків. Як такий, він отримує статус батька на часовій шкалі, оскільки жоден інший з батьків не надав цю функціональність. Pacman має гнучкість, щоб дозволити користувачеві встановити бінарний пакет з офіційного сховища або спеціальний вбудований пакет за допомогою системи Arch Build. Ця концепція забезпечує баланс між владою, яку надають неповнолітні батьки, з легкістю встановлення, яку надають основні батьки.


На мою думку, не менеджер пакунків демонструє потужність системи, оскільки всі менеджери пакунків виконують одне і те ж завдання, а саме керувати та підтримувати здорову систему. Таким чином, систему, яку ви використовуєте, слід визначати такими факторами, як:

  • Рівень користувача: Хтось, хто є новим у Linux, повинен починати з головного батька, тоді як хтось технічно досвідчений знайде рівновагу.
  • Що ви хочете зробити зі своєю системою: Запуск LAMP-сервера з приєднаними користувачами абсолютно не відрізняється від запуску настільного ПК для перегляду веб-сторінок та читання електронної пошти.
  • Рівень комфорту: рівень користувача не витримує, якщо ви досвідчені, але не хочете проводити вихідні за складанням системи, ви оберете головного батька, незалежно від того, чи вибрали всі, кого ви знаєте.

Це більше зосереджено на генеалогії дистрибутивів, а не на порівнянні інструментів управління пакунками Pacman та Debian ...
jasonwryan

@jasonwryan У цьому справа, оскільки всі менеджери пакунків виконують одне і те ж завдання, тобто emerge packagenameте саме, що sudo apt-get install packagename.
eyoung100

На цьому рівні так; але це повністю пропускає суть питання, тобто те, що відрізняє Pacman від {apt, здатності}.
jasonwryan

@jasonwryan Я відповів, що в розділі "Міст". Крім цього, різниці немає. Єдині відмінності - семантичні, тобто одна команда проти іншої. Якщо ОП шукає смислові відмінності, для цього є посібник.
eyoung100

-3

Це аж ніяк не повна чи вичерпна відповідь - плакати перед мною вже дали дуже хороші моменти, я хотів би додати свої 2 копійки. Інша річ - я ніколи насправді не звик до apt / dpkg. Мені це завжди здається надскладним, мені справді найбільше подобається yum / rpm.

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

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

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

Немає справжнього внутрішнього очищення кеша / повного відновлення. Якщо (через мережеву проблему) завантаження пакета було пошкоджено, наприклад, під час -Syu, повідомлення про помилку, хоча і точне, не принесе великої користі - воно не буде точно визначати пошкоджений пакет навіть при включеному "повного" багатослівності та налагодження , і жодна кількість -Syyc дійсно не очистить кеш і перезавантажить пакунки. Хороша новина полягає в тому, що -Sc повідомить вам, де перебувають завантажені пакети, тож ви можете просто видалити обраний (якщо ви зможете розібратися, який є) або всі з них та перезапустити -Syu.

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

Ще один анекдот про його гнучкість - як було сказано, я звик об / хв. Якщо у мене є файл у моїй системі, і я хочу знати, який пакет належить йому, я можу запустити yum offers / path / to / file та отримати ВСІ пакети, які можуть розмістити його там, навіть якщо жоден з них не встановлений. Якщо файл був розміщений вручну, і тепер я хочу встановити пакет - він перейменує новий (додайте розширення .rpmnew), і дозвольте мені вибрати, що використовувати.

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

Простіше кажучи - він не настільки зрілий, як yum, і, ймовірно, dpkg, що надає йому простоту використання, а також відносну негнучкість.


1
За винятком вичерпної невідповіді, ви наголошуєте на кілька питань, які насправді є продуктом незнайомості з Pacman. Наприклад pacman -Qo $file, розповімо, який пакет має $ файл. Крім того, вся ваша відповідь є солом'яницею, оскільки ОП явно просила розбіжностей між Arch і Debian - yumнічого спільного з цим не має ...
jasonwryan

саме тому я чітко розкрив цей факт на початку своєї відповіді. що стосується файлу -Qo $ - ви коли-небудь пробували це для ще не встановленого пакету?
Dani_l

Немає сенсу спробувати це для невстановленого пакету; для цього є інші інструменти. І розкриття інформації не пом'якшує той факт, що ви не відповіли на питання: "порівняння" між yum і pacman - це не те саме, що відмінності між менеджерами пакетів Debian і Arch.
jasonwryan

@jasonwryan Звичайно, є сенс. Тільки тому, що ви не бачите необхідності з'ясовувати, який пакет може володіти файлом, навіть якщо він ще не встановлений, не означає, що такої потреби не існує. Це був сенс. Щодо інших інструментів - чи вони знають, що потрібно? Pacman - менеджер пакунків. Щодо вашого головного моменту - я, можливо, повністю перечитав це питання, але я припустив, що мова йде про легкий ПМ проти більш складного ПМ. Я припускаю, що apt / dpkg є щонайменше настільки ж складним, як yum / rpm, функція мудра.
Dani_l

Моя думка, ви відповідаєте на питання про порівняння яблук з апельсинами, порівнюючи своє обмежене розуміння яблук з грушами. І так, ви повністю неправильно прочитали питання ...
jasonwryan
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.