Различия в управлении пакетами между Debian и Arch

Обсуждение этого поста заставило меня задуматься о различиях между управлением пакетами Debian и Arch. Кроме того, люди склонны говорить, что Arch очень легкий, поэтому мне интересно, как это связано с управлением пакетами. Может быть, это связано с тем, что Debian по умолчанию рассматривает Recommended как жесткие зависимости?

Можете ли вы также упомянуть гибкость / мощь между двумя менеджерами пакетов: какой из двух позволяет вам делать больше.

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

Я просто регулярно использую arch уже несколько недель и не являюсь экспертом в этой области, поэтому этот ответ ни в коем случае не является исчерпывающим, лишь несколько замечаний о «гибкости / мощи», которые я отметил:

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

• Это также очень быстро (из-за оптимизации, а также, вероятно, из-за нескольких вещей (см. Ниже)). В последнем выпуске (pacman 3.5, несколько дней назад) была предпринята попытка повысить производительность за счет уменьшения количества задействованных файлов базы данных.

• Хотя arch ориентирован на использование бинарных пакетов, он также имеет преимущества при сборке пакетов из исходного кода, а система сборки похожа на порты BSD (ABS).

• Создать пакеты очень просто и быстро, всего несколько строк в файле PKGBUILD, и все готово, не нужно иметь дело с control / rules / copyright / changelog / независимо от пакетов Debian. И несколькими щелчками по веб-интерфейсу ваш пакет доступен всем на AUR (Arch User Repository).

Вещи, которые я получаю в Debian, а не в arch:

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

• debconf (ничего страшного и, кстати, заставляя меня делать что-то вручную, это заставляет меня знать, что именно делается) и правильную обработку новых файлов конфигурации (я бы по крайней мере хотел, чтобы pacman знал, когда файл конфигурации в новом пакете версия отличается от установленной, потому что она была изменена в новой версии или потому что я изменил ее локально).

• подписание пакета (кажется, над ним работают ).

Из-за того, что arch легок, единственная реальная причина в том, что он поставляется с несколькими пакетами, установленными по умолчанию, и вам рекомендуется добавлять то, что вам нужно, поэтому, вероятно, не установка дополнительных зависимостей по умолчанию побуждает пользователей к установке, чтобы избежать раздувания.

Я начал свое путешествие по Linux с Ubuntu lucid и сейчас использую Arch. Я написал несколько пакетов Arch, и я скажу, что это намного проще, чем написание пакетов Debian. Но я хотел бы указать @gentledevil, что Arch имеет систему перехватов для пакетов, известную как install file.

По сути, он назван ${pkgname}.installи содержит несколько функций для предварительной / последующей установки / удаления / обновления; просто поместите туда обновления шрифта кеша и так далее, и он работает примерно так же, как и хуки Debian.

Также я заметил, что вы упомянули «закрепление» приложения с помощью инструментов управления пакетами Debian; В пакете Arch pacman также есть встроенная функция, которая /etc/pacman.confпринимает ряд параметров, в том числе IgnorePkg =предотвращающих обновление любых пакетов, перечисленных после равенства (разделенный пробелами).

Прежде чем я зайду слишком далеко, изучите временную шкалу Linux для изображений

Чтобы понять различия в менеджерах пакетов, вы должны понять принципы ОС, изображенных выше

Три главных родителя

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 с нуля . По сути, это дистрибутив Linux от Scratch плюс менеджер пакетов, который называется Portage / emerge
3. SourceMage - менеджер пакетов Волшебство

Эти родители незначительны, потому что их пользовательская база торгует скоростью и простотой установки с мощностью и простотой настройки. Каждый пакет загружается и компилируется с нуля, используя переменные и файлы конфигурации.

Мост

Arch был создан как мост между бинарным дистрибутивом, как один из 3-х главных родителей, и дистрибутивом на основе источника, как один из 3-х младших родителей. Таким образом, он получает статус родителя на временной шкале, потому что никакой другой родитель не предоставил эту функцию. Pacman обладает гибкостью, позволяющей пользователю устанавливать бинарный пакет из официального репозитория или пользовательский пакет, используя систему Arch Build System. Эта концепция обеспечивает баланс между властью, которую наделяют несовершеннолетние родители, и простотой установки, которую дают старшие родители.

По моему мнению, это не менеджер пакетов, который демонстрирует мощь системы, поскольку все менеджеры пакетов выполняют одну и ту же задачу - управлять и поддерживать работоспособную систему. Таким образом, система, которую вы используете, должна определяться такими факторами, как:

• Уровень пользователя: Кто-то новичок в Linux должен начинать с Major Parent, тогда как кто-то технически опытный найдет баланс.
• Что вы хотите сделать со своей системой: запуск сервера LAMP с подключенными пользователями совершенно отличается от запуска настольного ПК для просмотра веб-страниц и чтения электронной почты.
• Уровень комфорта: пользовательский уровень не выдерживает, если вы технически опытны, но не хотите проводить выходные, составляя систему, вы выберете основного родителя, независимо от того, выбирают ли все, кого вы знаете, что-то еще.

Это ни в коем случае не является полным или исчерпывающим ответом - постеры передо мной уже дали очень хорошие оценки, я просто хотел бы добавить свои 2 цента. Другое дело - я никогда не привык к apt / dpkg. Это всегда казалось мне слишком сложным, я действительно чувствую себя комфортно с ням / об / мин.

Пакет pacman очень прост в использовании - это «за» и «против» - вы можете научиться использовать его (помимо сборки пакетов) за один день - он использует в основном интуитивно понятные и полные функции управления пакетами, но - и это большое, но - это чрезвычайно негибко.

Если дизайнеры не подумали о какой-то функции заранее, вы облажались.

Несколько примеров: в pacman нет собственных версий. Если вы хотите понизить версию пакета - вам нужно скачать эту конкретную версию пакета и использовать опцию -U (обновление) для установки из файла. Он очень ориентирован на постоянное использование новейших пакетов в вашей системе.

Нет реальной очистки внутреннего кеша / полной перестройки. Если (из-за проблем с сетью) загрузка пакета была повреждена, например, во время -Syu, сообщение об ошибке, хотя и точное, не принесет особой пользы - оно не будет точно определять поврежденный пакет даже при «полной» детализации и включенной отладке. и никакое количество -Syyc не будет действительно очищать кеш и перезагружать пакеты. Хорошая новость заключается в том, что -Sc сообщит вам, где находятся загруженные пакеты, так что вы можете просто удалить один из нарушающих (если вы сможете выяснить, какой именно) или все из них и перезапустить -Syu.

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

Еще один анекдот о его негибкости - как уже говорилось, я привык к rpm / yum. Если у меня есть файл в моей системе, и я хочу знать, какому пакету принадлежит он, я могу запустить yum обеспечивает / path / to / file и получить ВСЕ пакеты, которые могут поместить его туда, даже если ни один из них не установлен. Если файл был помещен вручную, и теперь я хочу установить пакет - он переименует новый (добавит расширение .rpmnew) и позволит выбрать, что использовать.

pacman просто выдает ошибку, что файл уже существует, но с совершенно несущественным сообщением об ошибке - он жалуется на конфликты между «истинным» владельцем файла и текущим установленным пакетом «файловых систем», как будто он также является владельцем того же файла. Кроме того, он в основном ориентирован на локально установленную информацию - попытка получить информацию (такую ​​как списки файлов и владельцы) о еще не установленных пакетах менее интуитивна.

Проще говоря - он не такой зрелый, как yum, и, вероятно, dpkg, что объясняется простотой его использования, является относительной негибкостью.