Как уже замечено, большинство дистрибутивов ГНУ/Линукс, включая самые популярные, предусматривают установку с первоначальной настройкой и обновление с использованием прекомпилированных программ, собранных в пакеты. Пакет, который может включать одну или более программ, файлы конфигурации, документацию и т. п. является минимальной единицей установки или обновления штатными для дистрибутива средствами. В отдельные пакеты составителями собираются также исходные коды, соответствующие каждому прекомпилированному пакету. Процедуры установки, удаления, обновления пакетов называются управлением пакетами.

Стандарта на пакетирование и управление пакетами не существует. Распространение получили три формата пакетов: rpm (впервые появившийся в дистрибутиве RedHat и применяемый сегодня большинством составителей дистрибутивов), deb (применяемый в Дебиан) и tgz (применяемый Slackware). От формата пакета зависит программа управления пакетами (rpm для rpm, setup для tgz и dpkg для deb). Важнейшая задача этих программ — отслеживать зависимости между пакетами: ситуации, когда для нормальной работы программы из одного пакета требуется программа (возможно, определенная версия) из другого пакета, или, наоборот, когда программы из разных пакетов являются взаимоисключающими в рамках одной системы. Разрешение всех зависимотей и устранение конфликтов между пакетами называется поддержанием целостности системы.

В последние годы развиваются усовершенствованные средства управления пакетами, позволяющие преодолевать некоторые ограничения, свойственные rpm и dpkg. В частности, они позволяют отслеживать ситуацию смены имени пакета (в отличие от номера версии). В качестве примеров таких средств можно назвать apt (дистрибутивы Дебиан, Альт Линукс и Conectiva) и yum (дистрибутив ASPLinux).

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

В сообществе BSD в качестве штатной процедуры установки принято портирование, т. е. автоматизированная компиляция и сборка пакетов для целевой машины из исходников. В сообществе ГНУ/Линукс в качестве штатной процедуры установки принята распаковка бинарных (прекомпилированных) пакетов. Все дистрибутивы технически поддерживали именно этот способ установки до недавнего времени, когда появились так называемые source-based дистрибутивы (основанные на исходных кодах). Хотя, разумеется, администратор всегда имел возможность самостоятельно скомпилировать любой пакет.

Преимущество установки из исходников — оптимизация под конкретную машину и меньший объем пакетов. Преимущество бинарной установки — более высокая скорость. Следует иметь в виду, что сборка некоторых пакетов на компьютере персонального класса может длиться более десяти часов, и пересборка всех часто использующихся программ может занять несколько суток.

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

Наконец, следует обратить внимание на аппаратные платформы, на которые ориентирован дистрибутив. Более половины существующих дистрибутивов ориентированы исключительно на IA-32 (IBM PC-совместимые компьютеры), большинство остальных поддерживает две-три аппаратные платформы, а Дебиан — целых десять, включая достаточно экзотические. Поддержка даже ненужного вам «железа» при прочих равных, тем не менее, является признаком зрелости дистрибутива.

Функция разработчика дистрибутива заключается не в том, чтобы просто «собрать программы в кучу», красиво упаковать и продать, а, скорее, в том, чтобы обеспечить эффективную коммуникацию между авторами программ (и прочих произведений, входящих в дистрибутивы) с одной стороны и конечными пользователями с другой. Упрощенно структуру дистрибутива можно представить как коллектив мэйнтейнеров (от англ. maintainer) — лиц, отвечающих за поддержание пакетов (единиц в системе) в хранилище в актуальном состоянии и системной целостности в соответствии с некоторой концепцией в интересах сообщества пользователей. Поставка очередного выпуска дистрибутива (на дисках или через Сеть) — лишь один из шагов в этой коммуникации. Команда разработки обычно разворачивает ряд сервисов для сообщества пользоваталей (служба поддержки, разработка на заказ, обеспечение поддержки нового оборудования, консультации). Как правило, именно такие сервисы являются основным бизнесом компании или команды, а продажа коробок с дистрибутивом — низкорентабельные издательские проекты, в лучшем случае окупающие управление самим изданием.

Выбор дистрибутива для конечного пользователя — больше, чем просто выбор товара; по сути дела, это выбор «узла присоединения к инфраструктуре». Не все аспекты функционирования ОС, а тем более прикладных платформ и пакетов, стандартизованы, поэтому часть знаний и навыков администратора специфичны для каждого дистрибутива.

Однако еще важнее, что дистрибутив определяет ближайший круг общения и стиль общения, в которое неизбежно вступает конечный пользователь. Большая часть литературы, в которой различные дистрибутивы сравниваются между собой^[7], сосредоточена на технических различиях, однако, гуманитарные и «коммунитарные» (относящиеся к жизни сообщества) аспекты представляются более важными.