Представьте себе огромное количество разного ПО от маленьких (но важных) проектов по отдельным библиотекам до огромных типа KDE, GNOME, Libre- и OpenOffice, ядра Linux. Все эти отдельные проекты развиваются каждый сам по себе, иногда с оглядкой на остальные, иногда нет. Конечно, каждый может собрать это все ПО вместе и объявить дистрибутивом Linux, но в случае серьезных дистрибутивов (я к ним отношу те, что занимают первые 10 мест в рейтинге Distrowatch) все обычно гораздо сложнее.

Немного о терминах.
Разработчиками дистрибутива (или майнтейнерами) обычно называют тех, кто берет какое-то ПО и упаковывает его в пакет для конкретного дистрибутива (пакетная система, для чего она нужна и что делает — отдельный большой вопрос).
Место, откуда это ПО берется — называется апстрим (от английского upstream). Адекватного перевода на русский язык я пока не нашел, да и слово апстрим стало уже устоявшимся термином. Для серьезных дистрибутивов апстримом являются конкретные проекты свободного (и не очень) ПО. Для производных дистрибутивов — другие дистрибутивы Linux. Например, для CentOS — апстримом является Red Hat Enterpise Linux, для Ubuntu — Debian, для Debian — оригинальные разработчики ПО. Еще раз — апстрим это или разработчик конкретной программы, или родительский дистрибутив.
Пакетом называется отдельный атом дистрибутива (в смысле неделимости), который несет в себе конкретную программу (или набор программ), библиотеку (или набор библиотек), документацию, темы оформления или что-то еще. Короче говоря, все, что составляет дистрибутив Linux — это меньшее или большее количество пакетов. Пакет — это обычно:

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

Пакетная система — то, что помогает пользователям дистрибутива искать, ставить, обновлять пакеты и автоматически отслеживать зависимости между ними. Пакетные системы в мире Linux делятся на три больших и хорошо очерченных класса:

• пакетная система Debian и ее deb-пакеты.
• пакетная система rpm, придуманная в свое время Red Hat и теперь имеющая не всегда совместимые между собой пакеты разных rpm-дистрибутивов (Red Hat/Fedora, SUSE, Mandriva и т.п.). Имеется в виду, что, например, пакет для Mandriva может и встанет на SUSE (зависит от положения звезд на небе), но работать скорее всего откажется.
• все остальные пакетные системы. В качестве примера сюда можно отнести и пакеты ArchLinux, и Slackware, и отчасти Gentoo.

Важный составляющих элемент пакетной системы — менеджер пакетов. Это программа, позволяющая управлять пакетами на конкретной машине. И обычно она имеет только текстовый интерфейс, но разработчики большинства дистрибутивов, как правило, поставляют графические утилиты, взаимодействующие с пакетным менеджером и таким образом значительно облегчающие жизнь тех, кто еще не познакомился с консолью Linux или не хочет с ней знакомится вовсе.
Вопрос какая пакетная система лучше, какая хуже — относится к сфере личных пристрастий и потому спорный. Желающие могут в этом убедиться, открыв на каком-нибудь Linux-форуме тему «Что лучше rpm или deb?». Если Вас сразу не забанят модераторы форума за провокац
ию, то флейм по этому поводу займет не один десяток страниц.
Зависимости — это следующая непонятная новичкам штука. Бывают жесткие и мягкие. Жесткая зависимость в общем виде — это все то, без чего содержимое пакета работать не будет. Обычно это какие-то библиотеки, обеспечивающие функционал конкретной программы. Мягкая зависимость — это то, что обеспечивает дополнительный функционал для программы. Такой тип зависимостей есть, по большому счету, только в deb-пакетах.
Следующее непонятное определение — репозиторий пакетов. Это место, откуда пользователи берут ПО для своего дистрибутива. Обычно это некое сетевое (но может быть и локальным) хранилище пакета, в котором помимо собственно пакетов для дистрибутива находится набор метаданных, которые используются пакетным менеджером для управления ПО на машине пользователя. Именно благодаря этим метаданным пользователям достаточно легко найти нужные пакеты в репозитории, а пакетному менеджеру выяснить, какое ПО требует обновлений.
По способу поддержки репозитория можно выделить три типа дистрибутивов:

1. Дистрибутивы со скользящим релизом (или безрелизные). На английском они обычно называются rolling release. Типичный (и достаточно популярный) тут — Archlinux. В таких дистрибутивах после обычно малого периода тестирования пакеты попадают к пользователям практически сразу после релиза конкретного пакета его разработчиком. Главное преимущество таких дистрибутивов — то, что в репозитории находится очень свежее ПО. Это имеет и обратную сторону (за все в жизни приходится платить) — в этом ПО зачастую имеются ошибки, которые с переменным успехом отлавливаются пользователями такого дистрибутива. По причине того, что большая часть проектов развивается без оглядки друг на друга, иногда встречается какая-либо несовместимость между какими-то пакетами, вызывающая неработоспособность определенной программы. Иногда (при серьезных изменениях) меняется формат конфигурационного файла программы или демона, что требует работы руками. Но те, кто используют такие дистрибутивы, обычно знают, на что идут, и достаточно квалифицированы для того, чтобы решить все возникающие проблемы. Тут из всех дистрибутивов, на мой взгляд, самый выдержанный подход у Gentoo, который представляет собой дистрибутив с rolling release-моделью, но тем не менее все пакеты попадают в его стабильную ветвь после значительного периода тестирования, что обеспечивает достаточно высокую надежность его работы.
2. Дистрибутивы с релизной моделью. Проблема получения стабильного дистрибутива давно уже решена и используется большинством разработчиков разных дистрибутивов Linux, таких как Debian, Ubuntu, Red Hat, SUSE и проч. У таких дистрибутивов есть обычно тестовая ветвь с rolling release-моделью, на которой обкатываются (и решаются) разные проблемы несовместимости и нестабильной работы конкретного ПО. Периодически эту ветвь замораживают, блокируя попадание туда новых пакетов. Затем в таком репозитории вычищают по максимуму все имеющиеся в нем проблемы и ошибки. Когда ошибок, по мнению разработчиков, уже достаточно малое количество, выпускается очередной релиз, на протяжении жизни которого в нем не будут уже меняться версии имеющегося ПО. Обновления такого дистрибутива включают в себя исправление оставшихся ошибок и устранение возникающих время от времени уязвимостей. Иногда ошибки устраняют и разработчики апстрима. Тогда задача майнтейнера пакета проанализировать исходный код разработчиков ПО (он же открыт) и выделить из него только те изменения, которые отвечают за исправление ошибок. Затем эти изменения накладываются на те программы и библиотеки, которые находятся в стабильном релизе. Благодаря этому получается, что версия ПО в стабильном дистрибутиве старая, но тем не менее в ней исправлено большинство уязвимостей, найденных к этому моменту. Другое дело, что длительная поддержка ПО по такой схеме — вещь трудная. Ведь чем больше проходит времени с момента релиза, тем более высокая квалификация требуется от разработчика, чтобы выделить только то, что исправляет ошибки и ни в коем случае не ломает совместимость с другими программами и библиотеками. Именно по этой причине длительную поддержку релиза могут позволить себе немногие. По сути лишь те, кто
   имеет большое количество квалифицированных программистов, то есть коммерческие компании Red Hat и Novell. Такие дистрибутивы прекрасно подходят для консервативной корпоративной среды, где редко происходят сильные изменения и поэтому нужна высокая стабильность работы.
3. Дистрибутивы со смешанным циклом. В таких дистрибутивах стабилизируется (замораживается) только одна часть репозитория. Как правило, это все, что относится к сборочной среде, — компилятор, библиотека C, разные важные библиотеки, ядро Linux. А ПО, относящееся к десктопам (типа Firefox, OpenOffice, разные игры), обновляется регулярно (но обязательно после продолжительного тестирования).

Для таких популярных дистрибутивов как openSUSE и Ubuntu есть выбор — либо использовать стабильную базу конкретного релиза их дистрибутива, или подключить дополнительные репозитории (репозитории OBS для SUSE и ppa для Ubuntu), получая таким образом более свежее ПО для своей системы.
Вроде как все, что хотелось бы сказать по данному поводу. Если что осталось неясно, постараюсь ответить в комментариях на вопросы, касающиеся данной статьи. В меру сил и наличия свободного времени постараюсь внести все необходимые изменения, если потребуется в приведенный текст статьи.