# FTP-архіви Debian

## Що означають всі ті теки на ftp-архівах Debian?

Програмне забезпечення у вигляді пакунків для Debian GNU/Linux доступне у одному з декількох дерев тек на кожному дзеркальному сайті Debian.

Тека `dists` це скорочення від „distributions“ (дистрибутиви, збірки); вона є канонічним шляхом для отримання доступу до існуючих на даний момент версій Debian.

Тека `pool` містить поточні пакунки, перегляньте pools.

Існують такі додаткові теки:

/tools/:

- DOS-утиліти для створення завантажувальних дисків, поділу вашого диску на розділи, стиснення/розстиснення файлів та завантаження Linux.

/doc/:

- Основна документація Debian, така як FAQ, інструкції до системи відслідковування помилок та ін.

/indices/:

- Файл Maintainers та файли override.

/project/:

- Переважно матеріали, що призначені для розробників, наприклад:

  project/experimental/:

- Ця тека містить пакунки та інструменти, які все ще розробляються і знаходяться в режимі попереднього тестування. Користувачі не повинні використовувати пакунки звідси, тому що це може бути небезпечно і завдати шкоди навіть для системи під керуванням доволі досвідченої людини.

## Скільки збірок Debian знаходиться в теці `dists`?

Є три збірки — стабільна (stable), тестова (testing) та нестабільна (unstable). Тестова збірка іноді „заморожується“ (frozen) (див. frozen).

## Що означають всі ці імена на кшталт slink, potato та ін.?

Це просто умовні кодові назви. Коли збірка Debian знаходиться в стадії розробки, вона не має номера версії, а лише умовну назву. Вони використовуються щоб полегшити віддзеркалення збірок Debian (якщо справжня тека, наприклад, `unstable` раптом змінить свою назву на `stable`, потрібно буде заново переписувати занадто багато файлів).

На даний момент `stable` є символічним посиланням на `stretch` (себто Debian GNU/Linux 9), а `testing` — на `buster`. Тобто `stretch` є поточною стабільною версією, а `buster` — тестовою.

`unstable` є постійним символічним посиланням на `sid`, оскільки `sid` — це завжди нестабільна збірка (перегляньте sid).

### Які кодові назви вже використовувались?

Окрім вищезгаданих використовувались наступні кодові назви: `buzz` для версії 1.1, `rex` для версії 1.2, `bo` для версій 1.3.x, `hamm` для версії 2.0, `slink` для версії 2.1, `potato` для версії 2.2 та `woody` для версії 3.0.

### Звідки беруться всі ці імена?

Це все імена персонажів з мультфільму „Toy Story“ компанії Pixar.

- buzz (Buzz Lightyear) був космонавтом,

- rex був тиранозавром,

- bo (Bo Peep) дівчинка, котра опікувалась овечкою,

- hamm був поросям-скарбничкою,

- slink (Slinky Dog®) був іграшковим песиком,

- potato це, звісно, пан Potato®,

- woody був ковбоєм,

- sarge був сержантом Зеленою Пластикової Армії,

- etch це іграшкова класна дошка (Etch-a-Sketch®).

- sid був сусідським хлопчаком, котрий ламав іграшки.

## Ну а як щодо „sid“?

sid або unstable — це місце куди початково завантажуються всі пакунки. Вони ніколи не додаються відразу в збірку, тому що пакунки, котрі додаються спочатку повинні бути включені до testing, для того щоб через деякий час бути доданими в наступний випуск stable. sid містить пакунки як для випущених, так і для невипущених архітектур.

Ім'я sid також прийшло з „Toy Story“; так звали сусідського хлопчака, котрий ламав іграшки :o)

Коли теперішнього sid ще не було, у організації FTP-сайтів був недолік: робилось припущення, що архітектура, внесена до поточної нестабільної версії, буде додана у наступну стабільну. Для багатьох архітектур цього не відбувалось і в момент випуску нової версії відповідні теки переміщувались. Це було непрактичним, бо сильно навантажувало пропускні лінії.

Адміністратори архівів працювали над цією проблемою кілька років, розміщуючи двійкові пакунки для невипущених архітектур у спеціальну теку sid. При першому їх випуску робились посилання з поточної стабільної версії у sid і відтоді вони, зазвичай, створювались всередині нестабільної гілки. Таке розміщення призводило до непорозумінь з користувачами.

З появою пакункових пулів (див. pools) двійкові пакунки почали розміщувати в теці pool незалежно від збірки, тож випуск нової версії перестав спричиняти інтенсивне навантаження на канали дзеркал (натомість, воно поступово зростає під час розробки).

## Що міститься в теці stable?

- stable/main/: Ця тека містить пакунки, що формально складають найсвіжішу версію Debian GNU/Linux.

  Всі ці пакунки сформовано згідно з критеріями Debian щодо вільного програмного забезпечення (DFSG) і вони повністю готові до вживання та поширення.

- stable/non-free/: В цій теці знаходяться пакунки, поширення яких обмежується в спосіб, що вимагає від поширювача дотримуватись специфічних копірайтних умов.

  Наприклад, деякі пакунки поширюються під ліцензіями, що забороняють комерційне поширення. Інші дозволяють поширювати, але як умовно-безкоштовне, а не вільне програмне забезпечення. Ліцензії всіх цих пакунків повинні бути детально вивченими та, можливо, узгодженими, перш ніж їх додати у якусь збірку (наприклад, на КД).

- stable/contrib/: Ця тека містить пакунки, що є вільними з точки зору DFSG та можуть вільно поширюватись самі по собі, але якимось чином залежать від пакунків, що не можуть поширюватись вільно і, отже, знаходяться у секції non-free.

## Що міститься в теці testing?

Пакунки переносяться в теку testing після того, як пройдуть деякі етапи тестування в unstable.

Вони мусять узгоджуватись з усіма архітектурами, у які їх будуть переносити та не повинні мати залежностей, що зроблять їх непридатними до встановлення; вони також повинні мати якомога менше блокуючих випуск помилок в тих версіях, що входять у testing. Таким чином ми сподіваємось, що testing завжди достатньо готовий щоб бути кандидатом до випуску.

Додаткову інформацію про статус testing в цілому та кожного пакунка зокрема можна отримати на http://www.debian.org/devel/testing.

### Як щодо testing? Чому вона заморожується?

Як тільки тестова збірка стає достатньо зрілою, керівник випуску „заморожує“ її. Прийняття пакунків до неї сповільнюється та подовжується в часі, щоб переконатись, що з нестабільної збірки в тестову перейшла мінімальна кількість помилок.

Через деякий час тестова збірка стає повністю замороженою. Це означає, що всі нові пакунки, які подаються до тестової версії, не буде прийнято до тих пір, поки вони містять критичні, блокуючі випуск помилки. Тестова збірка може залишатись у такому повністю замороженому режимі під час так званого „тестового циклу“, аж поки випуск не стає неминучим.

Ми ведемо записи про помилки в testing, котрі можуть затримати випуск якогось пакунка, і помилок, що можуть затримати випуск повністю. За деталями зверніться до інформації про поточний тестовий випуск.

Як тільки кількість помилок знижується до прийнятних значень, заморожена тестова збірка оголошується стабільною та випускається з номером версії.

З кожним новим стабільним випуском попередній стає застарілим та поміщається в архів. За додатковою інформацією перегляньте сторінку архіву Debian.

## Що знаходиться в теці unstable?

Тека unstable містить знімок поточної розроблюваної системи. Користувачів запрошують використовувати та перевіряти ці пакунки, але попереджають про стан їх готовності. Переваги використання нестабільної версії в тому, що ви завжди знаходитесь на вістрі індустрії програмного забезпечення GNU/Linux, але якщо щось зламається: you get to keep both parts :-)

В теці unstable також знаходяться підтеки main, contrib і non-free; пакунки в них розподіляються за тими ж критеріями, що й в stable.

## Що це за теки в `dists/stable/main`?

Всередині кожного основного дерева тек

`dists/stable/main`, `dists/stable/contrib`, `dists/stable/non-free`, `dists/unstable/main/`, тощо;

, є три набори підтек, що містять індексні файли.

Один набір — це теки `binary-`дещо``, що містять індексні файли для двійкових пакунків кожної доступної архітектури, наприклад `binary-i386` для пакунків, що будуть виконуватись на машинах Intel x86, чи `binary-sparc` для пакунків, що будуть виконуватись на робочих станціях Sun SPARCStations.

Повний список доступних архітектур для кожного випуску доступний на присвяченій випуску веб-сторінці. Для поточного випуску, будь ласка, перегляньте arches.

Індексні файли у binary-* називаються Packages(.gz) і містять резюме для кожного двійкового пакунку, що включений у збірку. Поточні двійкові пакунки (для woody та наступних випусків) знаходяться на верхньому рівні теки `pool`.

Крім того існує підтека source/, котра містить індексні файли для джерельних пакунків, включених у збірку. Індексний файл називається Sources(.gz).

І останнє, але не менш важливе — є набір підтек, призначених для файлів системи встановлення. У випуску woody вони називаються `disks-`архітектура``; в sarge — `debian-installer/binary-`архітектура``.

## А де джерельні коди?

Джерельний код є для будь-чого з системи Debian. Більш того, ліцензійні положення більшості програм у системі вимагають, щоб разом з програмою розповсюджувався джерельний код, або ж пропонують це робити.

Джерельні коди знаходяться в теці pool (див. pools) разом з усіма архітектурно-специфічними теками для двійкових пакунків. Щоб отримати джерельний код без ознайомлення з структурою FTP-архіву, спробуйте команду на кшталт `apt-get source назва_пакунка`.

Деякі пакунки поширюються винятково у джерельних кодах через їх ліцензійні обмеження. В першу чергу це стосується `pine`, перегляньте pine щоб отримати більше інформації.

Джерельні коди можуть і не бути доступними для пакунків, що розташовані в теках contrib та non-free, що формально не є частиною системи Debian.

## Що за тека — `pool`?

Пакунки зберігаються у величезному сховищі (pool), структурованому за назвами джерельних пакунків. Щоб зробити це діло керованим, сховище поділяється по секціям (main, contrib та non-free) та по перших літерах назв джерельних пакунків. Ці теки містять декілька файлів: двійкові пакунки для кожної архітектури та джерельні пакунки, з яких формуються двійкові.

Ви можете дізнатись місцезнаходження кожного пакунка виконавши команду `apt-cache showsrc назва_пакунка` та подивившись на рядок „Directory:“. Наприклад, пакунки `apache` знаходяться в `pool/main/a/apache/`.

Крім цього, оскільки пакунків `lib*` дуже багато, вони розглядаються особливим чином: наприклад, пакунки libpaper знаходяться в теці `pool/main/libp/libpaper/`.

Історично склалося так, що пакунки зберігались у підтеці `dists` збірки, до котрої вони належали. Це спричиняло деякі проблеми, як наприклад велике завантаження пропускних каналів дзеркал при виході нових версій. Ця проблема була вирішена введенням єдиного сховища пакунків.

Теки `dists` досі використовуються для зберігання індексних файлів, котрі в свою чергу використовуються програмами на кшталт `apt`. Ви також можете зустріти шляхи `dists/potato` чи `dists/woody` у полі заголовку Filename деяких старих пакунків.

## Що таке incoming?

Після того, як супроводжувач завантажує пакунок на сервер сховища, він деякий час знаходиться в теці „incoming“, доки не буде перевірено, що він є справжнім і додано його до архіву.

Як правило, ніхто не повинен встановлювати пакунки звідти, проте, на випадок деяких рідкісних, надзвичайних ситуацій тека incoming доступна за адресою http://incoming.debian.org/. Ви можете вручну викачувати пакунки і, перевіривши PGP-підписи та md5-суми в файлах .changes i.dsc, встановлювати їх.

## Як мені створити своє власне apt-сумісне сховище?

Якщо ви хочете збудувати деякі власні пакунки Debian, які б ви хотіли встановлювати за допомогою стандартних інструментів управління пакунками Debian, ви можете створити ваш власний apt-сумісний архів пакунків. Це також корисно, якщо ви не хотіли б оприлюднювати ваші пакунки, доки їх не буде включено до проекту Debian. Вказівки щодо того, як це можна зробити ви знайдете в Debian Repository HOWTO.