Содержание
dists/stable/main
?pool
?Есть три основных дистрибутива: стабильный («stable»), тестируемый («testing») и нестабильный («unstable»). Тестируемый дистрибутив иногда «замораживается» (смотрите Раздел 6.5.1, «Что происходит с «testing»? Как его «замораживают»?»). Кроме этого, есть ещё старый стабильный дистрибутив («oldstable») (т. е. предыдущий стабильный) и экспериментальный дистрибутив («experimental»).
Experimental is used for packages which are still being developed, and with a high risk of breaking your system. It's used by developers who'd like to study and test bleeding edge software. Users shouldn't be using packages from there, because they can be dangerous and harmful even for the most experienced people.
Чтобы определиться с выбором дистрибутива Debian, см. Глава 3, Выбор дистрибутива Debian.
Это всего лишь «кодовые имена». Когда дистрибутив Debian находится в
состоянии разработки, ему присваивается не номер версии, а кодовое имя. Эти
имена облегчают зеркалирование дистрибутивов Debian (если бы настоящее имя
каталога, например unstable
, вдруг изменилось на
stable
, то пришлось бы без реальной необходимости
скачивать кучу пакетов заново).
Сейчас stable
— это символьная ссылка на
bookworm
(т. е. на Debian GNU/Linux 12), а
testing
— это символьная ссылка на
trixie
. Это означает, что
bookworm
сейчас является стабильным дистрибутивом, а
trixie
— текущим тестируемым.
unstable
— это постоянная символьные ссылка на
sid
, так как имя sid
навсегда
закреплено за нестабильным дистрибутивом(смотрите Раздел 6.3, «Что такое «sid»?»).
Aside bookworm
and
trixie
, other codenames that have been already
used are: buzz
for release 1.1, rex
for release 1.2, bo
for releases 1.3.x,
hamm
for release 2.0, slink
for
release 2.1, potato
for release 2.2,
woody
for release 3.0, sarge
for
release 3.1, etch
for release 4.0,
lenny
for release 5.0, squeeze
for
release 6.0, wheezy
for release 7,
jessie
for release 8, stretch
for
release 9, buster
for release 10,
bullseye
for release 11, bookworm
for
release 12.
Уже давно они выбираются из имён героев мультфильма «История игрушек» (Toy Story) компании Pixar.
buzz (Debian 1.1) was the spaceman Buzz Lightyear,
rex (Debian 1.2) was the tyrannosaurus,
bo (Debian 1.3) was Bo Peep, the girl who took care of the sheep,
hamm (Debian 2.0) was the piggy bank,
slink (Debian 2.1) was Slinky Dog, the toy dog,
potato (Debian 2.2) was, of course, Mr. Potato,
woody (Debian 3.0) was the cowboy,
sarge (Debian 3.1) was the sergeant of the Green Plastic Army Men,
etch (Debian 4.0) was the toy whiteboard (Etch-a-Sketch),
lenny (Debian 5.0) was the toy binoculars,
squeeze (Debian 6) was the name of the three-eyed aliens,
wheezy (Debian 7) was the rubber toy penguin with a red bow tie,
jessie (Debian 8) was the yodeling cowgirl,
stretch (Debian 9) was the rubber toy octopus with suckers on her eight long arms.
buster (Debian 10) was Andy's pet dog.
bullseye (Debian 11) was Woody's wooden toyhorse.
bookworm (Debian 12) was a green toy worm with a built-in flashlight who loves reading books.
trixie (Debian 13) was a blue plastic triceratops.
sid — это имя злого соседского мальчишки, который ломает игрушки.
Решение использовать имена из Истории игрушек было принято Брюсом Перенсом, который, будучи Лидером Проекта Debian, работал в мультипликационной компании Pixar (эта компания и создала указанные мультфильмы).
sid или unstable — это место, куда попадает большая часть пакетов при первоначальной закачке. Он никогда не будет выпущен, так как пакет сначала должен быть включён в testing, а позже в stable. sid содержит пакеты для выпускаемых и невыпускаемых архитектур.
Имя «sid» также взято из мультфильма «История Игрушек»: там Sid — это соседский мальчишка, который ломает игрушки :-)
stable/main/: В этом каталоге находятся пакеты, официально составляющие последний выпуск системы Debian GNU/Linux.
Эти пакеты соответствуют критериям Debian по определению Свободного ПО (DFSG) и могут свободно использоваться и распространяться.
stable/non-free/: В этом каталоге находятся пакеты, распространение которых ограничено требованиями, указанными в их лицензии.
Например, в лицензиях некоторых пакетов запрещается их коммерческое распространение. Другие пакеты могут распространяться третьими лицами, но только как условно-бесплатное и несвободное ПО. Перед включением таких пакетов в какие бы то ни было дистрибутивы для дальнейшего распространения (например, на CD-диски) требуется изучение и, возможно, обсуждение лицензии каждого из них.
stable/contrib/: В этом каталоге находятся пакеты, которые свободны в полном соответствии с DFSG и сами по себе распространяются свободно, но каким-либо образом зависят от НЕсвободных пакетов, доступных только в разделе non-free.
Пакеты попадают в каталог «testing» после того, как пройдут некоторое тестирование в unstable.
They must be in sync on all architectures where they have been built and mustn't have dependencies that make them uninstallable; they also need to have fewer release-critical bugs than the versions currently in unstable. This way, we hope that "testing" is always close to being a release candidate.
Более подробную информацию как о «testing» вообще, так и о его пакетах можно найти здесь.
When the "testing" distribution is mature enough, the release manager starts "freezing" it. The normal propagation delays are increased to ensure that as few new bugs as possible from "unstable" enter "testing".
Спустя какое-то время дистрибутив «testing» становится по-настоящему «замороженным». Это означает, что новые версии пакетов, за исключением лишь тех, что содержат исправления критических ошибок, больше в «testing» не попадают. В таком же состоянии глубокой заморозки дистрибутив может оставаться на время так называемого «тестового периода» перед выпуском.
Когда дистрибутив «testing» «замораживают», дистрибутив «unstable» также становится частично замороженным. Разработчики перестают добавлять очень новое ПО в нестабильный дистрибутив из-за боязни, что замороженное ПО в «testing» потребует небольших обновлений и исправлений критичных для выпуска ошибок, которые не дают «testing» стать «stable».
Для дистрибутива «testing» мы ведём учёт как тех ошибок, что не дают отдельным пакетам попасть в следующий выпуск, так и тех, что и вовсе могут задержать выход новой версии дистрибутива. Подробности см. в описании текущего состояния тестируемого выпуска.
Как только количество ошибок понижается до минимально приемлемого значения, замороженный дистрибутив «testing» объявляется стабильным и выпускается с новым номером версии.
Наиболее важно количество критичных для выпуска ошибок, за которым можно следить на странице статуса критических для выпуска ошибок. Общей целью выпуска является NoRCBugs, что означает, что дистрибутив не должен содержать ошибки степени critical, grave или serious. Полный список проблем, считающихся критическими, можно найти в Документации по политике RC.
Каждый раз при выпуске новой версии предыдущий дистрибутив «stable» становится устаревшим и перемещается в архив. Подробности см. на странице архива Debian.
В каталоге «unstable» находится «срез» текущей разработки системы. Пользователи вполне могут использовать и тестировать пакеты оттуда, если они осознают степень их готовности. Преимущество использования нестабильного дистрибутива в том, что у вас всегда будут самые передовые достижения программной индустрии GNU/Linux, ну а если какая программа и сломается, у вас будет целых две половинки :-)
В «unstable» тоже есть подкаталоги main, contrib и non-free, содержащие пакеты, разделённые по тем же признакам что и в «stable».
На каждом сервере-зеркале Debian всё ПО, которое было упаковано для Debian GNU/Linux, распределено по нескольким каталогам.
Каталог dists
— это сокращённое название
«distributions» (дистрибутивы); это канонический путь доступа к имеющимся на
данный момент выпускам Debian (и предварительным выпускам).
В каталоге pool
содержатся собственно пакеты, см. Раздел 6.10, «Что находится в каталоге pool
?».
Есть несколько вспомогательных каталогов:
Утилиты DOS для создания загрузочных дискет, разметки жёсткого диска, сжатия/распаковки файлов и загрузки Linux.
Основная документация Debian, например ЧаВо по Debian, инструкции по отправке сообщений об ошибках и т. д.
Различные индексные файлы (файл Maintainers и файлы переназначений).
В основном, материалы для разработчиков и некоторые другие файлы.
Within each of the major directory trees[3], there are three sets of subdirectories containing index files.
Есть набор подкаталогов
binary-
с индексными
файлами для двоичных пакетов для каждой доступной компьютерной архитектуры,
например что-то
binary-i386
— для пакетов, собранных для
компьютеров Intel x86, или binary-sparc
— для машин
Sun SPARCStation.
Полный список доступных архитектур для каждого выпуска есть на веб-странице выпуска. Для списка текущего выпуска см. Раздел 4.1, «На каких архитектурах/системах работает Debian GNU/Linux?».
Индексные файлы в binary-* называются Packages(.gz, .bz2) и включают сводку
по каждому двоичному пакету, вошедшему в дистрибутив. Реальные файлы
двоичных пакетов находятся на самом верхнем уровне дерева в каталоге pool
.
Кроме этого, есть подкаталог с именем source/, в котором находятся индексные файлы вошедших в дистрибутив пакетов с исходными кодами. Индексный файл называется Sources(.gz, .bz2).
И последнее, но не менее важное: есть набор подкаталогов, предназначенных
для индексных файлов системы установки, они называются
debian-installer/binary-
.
архитектура
Исходные коды в Debian есть для каждого пакета. Более того, в лицензиях большинства программ содержатся требования распространять вместе с ними и их исходные коды, либо сопровождать их предложением о том, откуда их можно получить.
The source code is distributed in the pool
directory (see
Раздел 6.10, «Что находится в каталоге pool
?») together with all the architecture-specific binary
directories. To retrieve the source code without having to be familiar with
the structure of the archive, try a command like apt-get source
mypackagename
.
Из-за ограничения в лицензиях исходный код пакетов в разделах "contrib" и
"non-free" либо может, либо не может быть доступен, формально эти разделы не
являются частью системы Debian. Двоичные файлы, не имеющие исходного кода,
могут распространяться лишь в некоторых случаях (напр., см.:
firmware-misc-nonfree
); в других случаях лицензия
запрещает распространение собранных двоичных файлов, но разрешает
распространение пакетов с исходным кодом, которые могут быть скомпилированы
пользователями самостоятельно (см.: broadcom-sta-dkms
).
Пакеты содержатся в огромном «пуле», структурированном по именам пакетов с исходным кодом. Для большей управляемости пул разбит по разделам («main», «contrib» и «non-free») и по первым буквам имён пакетов с исходным кодом. В этих каталогах содержится по несколько файлов: двоичные пакеты для каждой архитектуры и пакеты с исходным кодом, из которых были собраны двоичные пакеты.
Чтобы выяснить, где находится определённый пакет, можно воспользоваться
командой apt-cache showsrc имя_пакета
и посмотреть на
строку «Directory:». Например, пакеты apache
находятся в
pool/main/a/apache/
.
Также, из-за того, что пакетов, начинающихся с lib*
,
слишком много, они распределены чуть по-другому: например, пакеты libpaper
находятся в pool/main/libp/libpaper/
.
После того как разработчик закачал пакет, до того, как он будет проверен на подлинность, и ему будет разрешено попасть в архив, он какое-то время хранится в каталоге входящих пакетов «incoming»
Обычно никто не должен устанавливать пакеты из этого каталога. Однако, на случай крайней необходимости, каталог incoming доступен по адресу https://incoming.debian.org/. Оттуда можно вручную выкачать нужные пакеты, проверить подпись GPG и контрольную сумму MD5 в файлах .changes и .dsc и установить их.
Old releases are removed from the main archive and mirrors, which only keep the content of the releases up to "oldstable" (the stable release before the current one). If you are interested in obtaining older versions of packages, go to https://snapshot.debian.org/.
The snapshot archive is a wayback machine that allows access to old packages based on dates and version numbers. It consists of all past and current packages the Debian archive provides. It provides a valuable valuable resource for tracking down when regressions were introduced, or for providing a specific environment that a particular application may require to run. The snapshot archive is accessible like any normal apt repository, allowing it to be easily used by all.
Если собрали какие-то свои собственные пакеты Debian, которые вы хотели бы установить, используя стандартные инструменты по управлению пакетами Debian, вы можете настроить свой собственный архив пакетов с поддержкой apt. Это также полезно в том случае, если вы хотите поделиться своими пакетами Debian, даже несмотря на то, что они не распространяются Проектом Debian. Инструкции о том, как это сделать приведены в вики Debian.
[2] When the present-day sid did not exist, the FTP site organization had one major flaw: there was an assumption that when an architecture is created in the current unstable, it will be released when that distribution becomes the new stable. For many architectures that isn't the case, with the result that those directories had to be moved at release time. This was impractical because the move would chew up lots of bandwidth.
The archive administrators worked around this problem for several years by placing binaries for unreleased architectures in a special directory called "sid". For those architectures not yet released, the first time they were released there was a link from the current stable to sid, and from then on they were created inside the unstable tree as normal. This layout was somewhat confusing to users.
With the advent of package pools (see Раздел 6.10, «Что находится в каталоге pool
?»), binary
packages began to be stored in a canonical location in the pool, regardless
of the distribution, so releasing a distribution no longer causes large
bandwidth consumption on the mirrors (there is, however, a lot of gradual
bandwidth consumption throughout the development process).
[3]
dists/stable/main
,
dists/stable/contrib
,
dists/stable/non-free
, and
dists/unstable/main/
, etc.
[4] Historically, packages were kept in the subdirectory of
dists
corresponding to which distribution contained
them. This turned out to cause various problems, such as large bandwidth
consumption on mirrors when major changes were made. This was fixed with
the introduction of the package pool.
The dists
directories are still used for the index files
used by programs like apt
.