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


9

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

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

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


ПРИМЕЧАНИЕ . Под управлением пакетами Debian я имею в виду APT, aptitude и dpkg. Я не знаком с инструментами Arch, поэтому я не знаю, есть ли что-нибудь кроме Pacman.
Чепанг

Ответы:


7

Я просто регулярно использую 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 легок, единственная реальная причина в том, что он поставляется с несколькими пакетами, установленными по умолчанию, и вам рекомендуется добавлять то, что вам нужно, поэтому, вероятно, не установка дополнительных зависимостей по умолчанию побуждает пользователей к установке, чтобы избежать раздувания.


Я не могу разобрать это: но я могу обойтись без этого и, кстати, знаю, что я делаю лучше . В последнем предложении также есть опечатка.
Чепанг

На каком языке написан менеджер пакетов pacman? Имеет ли он низкоуровневую и высокоуровневую функциональность управления пакетами, аналогичную dpkg / apt, и если да, то как они называются?
Фахим Митха

@Tshepang: извините, не носитель английского языка здесь. Я имел в виду «для меня нет ничего особенного в том, чтобы не иметь такой функциональности (debconf), и, заставляя меня делать что-то вручную, это заставляет меня знать, что именно делается».
gentledevil

@Faheem Mitha: Pacman написан на C и является интерфейсом к libalpm, который обрабатывает управление пакетами как «высокого уровня», так и «низкого уровня».
gentledevil

@zanko: Я тоже не носитель языка. Все, что я хотел, чтобы вы сделали, это сделать предложение более четким, и не в комментарии, а в самом посте. Кстати, опечатка, которую я упомянул, является опциональной . Я мог бы отредактировать пост сам, но я подумал, что вы могли бы также исправить это вместе с пояснительной частью.
Чепанг

6

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

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

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


1
Кроме того, хотя пакет не является репозиторием, вы можете использовать powerpillоболочку для pacman для параллельной загрузки нескольких пакетов, поэтому вместо pacman -S libfoo libbar libbazзагрузки каждого пакета один за другим вместо этого будут загружаться все три одновременно, что значительно увеличивает скорость обновления для улучшения соединений.
Hanetzer

-1

Прежде чем я зайду слишком далеко, изучите временную шкалу 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 с подключенными пользователями совершенно отличается от запуска настольного ПК для просмотра веб-страниц и чтения электронной почты.
  • Уровень комфорта: пользовательский уровень не выдерживает, если вы технически опытны, но не хотите проводить выходные, составляя систему, вы выберете основного родителя, независимо от того, выбирают ли все, кого вы знаете, что-то еще.

Это больше сфокусировано на генеологии дистрибутивов, а не на сравнении инструментов управления пакетами pacman и Debian ...
jasonwryan

@jasonwryan Это точка, так как все менеджеры пакетов выполнить ту же задачу, то есть emerge packagenameтакой же , как sudo apt-get install packagename.
eyoung100

На этом уровне, да; но это полностью упускает суть вопроса, т. е. что отличает pacman от {apt, aptitude}.
Джейсонвриан

@jasonwryan Я ответил на это в разделе «Мост». Кроме этого, нет никакой разницы. Единственные различия семантические, то есть одна команда против другой. Если ОП ищет семантические различия, для этого есть руководство.
eyoung100

-3

Это ни в коем случае не является полным или исчерпывающим ответом - постеры передо мной уже дали очень хорошие оценки, я просто хотел бы добавить свои 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, что объясняется простотой его использования, является относительной негибкостью.


1
Если не считать исчерпывающего отсутствия ответа, есть ряд моментов, которые вы затронули и которые действительно являются результатом незнакомства с pacman. Например pacman -Qo $file, расскажет вам, какому пакету принадлежит $ file. Кроме того, весь ваш ответ - бесполезный, так как OP явно спросил о различиях между Arch и Debian - не yumимеет к этому никакого отношения ...
jasonwryan

вот почему я четко раскрыл этот факт в начале своего ответа. Что касается файла -Qo $ - пробовали ли вы когда-нибудь это для пакета, который еще не установлен?
Dani_l

Нет смысла пробовать его для неустановленного пакета; Есть и другие инструменты для этого. И раскрытие не смягчает тот факт, что вы не ответили на вопрос: «сравнение» между yum и pacman не то же самое, что различия между менеджерами пакетов Debian и Arch.
jasonwryan

@jasonwryan Конечно, есть смысл. То, что вам не нужно выяснять, какому пакету может принадлежать файл, даже если он еще не установлен, не означает, что такой необходимости не существует. Это было главное. Что касается других инструментов - они на основе знания должны? Пакман - менеджер пакетов. Что касается вашего основного вопроса - я мог бы полностью неправильно понять вопрос, но я предположил, что речь идет об упрощенном PM против более сложного PM. Я полагаю, что apt / dpkg, по крайней мере, такой же сложный, как yum / rpm, с точки зрения возможностей.
Dani_l

Я хочу сказать, что вы отвечаете на вопрос о сравнении яблок с апельсинами, сравнивая ваше ограниченное понимание яблок с грушами. И да, вы совершенно неправильно поняли вопрос ...
jasonwryan
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.