<?xml version='1.0' encoding='utf-8'?>
<!-- -*- DocBook -*- -->
<chapter id="ftparchives"><title>FTP-архіви Debian</title>
<section id="dirtree"><title>Що означають всі ті теки на ftp-архівах Debian?</title>
<para>
Програмне забезпечення у вигляді пакунків
для Debian GNU/Linux доступне у одному з декількох
дерев тек на кожному дзеркальному сайті
Debian.
</para>
<para>
Тека <literal>dists</literal> це скорочення від
„distributions“ (дистрибутиви, збірки); вона є
канонічним шляхом для отримання доступу до
існуючих на даний момент версій Debian.
</para>
<para>
Тека <literal>pool</literal> містить поточні пакунки,
перегляньте <xref linkend="pools"/>.
</para>
<para>
Існують такі додаткові теки:
</para>
<variablelist>
<varlistentry>
<term><emphasis>/tools/</emphasis>:</term>
<listitem>
<para>
DOS-утиліти для створення завантажувальних
дисків, поділу вашого диску на розділи,
стиснення/розстиснення файлів та
завантаження Linux.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis>/doc/</emphasis>:</term>
<listitem>
<para>
Основна документація Debian, така як FAQ,
інструкції до системи відслідковування
помилок та ін.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis>/indices/</emphasis>:</term>
<listitem>
<para>
Файл Maintainers та файли override.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis>/project/</emphasis>:</term>
<listitem>
<para>
Переважно матеріали, що призначені для
розробників, наприклад:
</para>
<variablelist>
<varlistentry>
<term><emphasis>project/experimental/</emphasis>:</term>
<listitem>
<para>
Ця тека містить пакунки та інструменти, які
все ще розробляються і знаходяться в
режимі попереднього тестування.
Користувачі не повинні використовувати
пакунки звідси, тому що це може бути
небезпечно і завдати шкоди навіть для
системи під керуванням доволі досвідченої
людини.
</para>
</listitem>
</varlistentry>
</variablelist>
</listitem>
</varlistentry>
</variablelist>
</section>

<section id="dists"><title>Скільки збірок Debian знаходиться в теці <literal>dists</literal>?</title>
<para>
Є три збірки — стабільна (stable), тестова
(testing) та нестабільна (unstable).  Тестова збірка
іноді „заморожується“ (frozen) (див.  <xref
linkend="frozen"/>).
</para>
</section>

<section id="codenames"><title>Що означають всі ці імена на кшталт slink, potato та ін.?</title>
<para>
Це просто умовні кодові назви.  Коли збірка
Debian знаходиться в стадії розробки, вона не
має номера версії, а лише умовну назву.
Вони використовуються щоб полегшити
віддзеркалення збірок Debian (якщо справжня
тека, наприклад, <literal>unstable</literal> раптом
змінить свою назву на <literal>stable</literal>,
потрібно буде заново переписувати занадто
багато файлів).
</para>
<para>
На даний момент <literal>stable</literal> є
символічним посиланням на <literal>stretch</literal>
(себто Debian GNU/Linux 9), а <literal>testing</literal> — на
<literal>buster</literal>.  Тобто <literal>stretch</literal> є
поточною стабільною версією, а
<literal>buster</literal> — тестовою.
</para>
<para>
<literal>unstable</literal> є постійним символічним
посиланням на <literal>sid</literal>, оскільки
<literal>sid</literal> — це завжди нестабільна
збірка (перегляньте <xref linkend="sid"/>).
</para>
<section id="oldcodenames"><title>Які кодові назви вже використовувались?</title>
<para>
Окрім вищезгаданих використовувались
наступні кодові назви: <literal>buzz</literal> для
версії 1.1, <literal>rex</literal> для версії 1.2,
<literal>bo</literal> для версій 1.3.x, <literal>hamm</literal> для
версії 2.0, <literal>slink</literal> для версії 2.1,
<literal>potato</literal> для версії 2.2 та <literal>woody</literal>
для версії 3.0.
</para>
</section>

<section id="sourceforcodenames"><title>Звідки беруться всі ці імена?</title>
<para>
Це все імена персонажів з мультфільму „Toy
Story“ компанії Pixar.
</para>
<itemizedlist>
<listitem>
<para>
<emphasis>buzz</emphasis> (Buzz Lightyear) був космонавтом,
</para>
</listitem>
<listitem>
<para>
<emphasis>rex</emphasis> був тиранозавром,
</para>
</listitem>
<listitem>
<para>
<emphasis>bo</emphasis> (Bo Peep) дівчинка, котра
опікувалась овечкою,
</para>
</listitem>
<listitem>
<para>
<emphasis>hamm</emphasis> був поросям-скарбничкою,
</para>
</listitem>
<listitem>
<para>
<emphasis>slink</emphasis> (Slinky Dog®) був іграшковим
песиком,
</para>
</listitem>
<listitem>
<para>
<emphasis>potato</emphasis> це, звісно, пан Potato®,
</para>
</listitem>
<listitem>
<para>
<emphasis>woody</emphasis> був ковбоєм,
</para>
</listitem>
<listitem>
<para>
<emphasis>sarge</emphasis> був сержантом Зеленою
Пластикової Армії,
</para>
</listitem>
<listitem>
<para>
<emphasis>etch</emphasis> це іграшкова класна дошка
(Etch-a-Sketch®).
</para>
</listitem>
<listitem>
<para>
<emphasis>sid</emphasis> був сусідським хлопчаком,
котрий ламав іграшки.
</para>
</listitem>
</itemizedlist>
</section>

</section>

<section id="sid"><title>Ну а як щодо „sid“?</title>
<para>
<emphasis>sid</emphasis> або <emphasis>unstable</emphasis> — це
місце куди початково завантажуються всі
пакунки.  Вони ніколи не додаються відразу
в збірку, тому що пакунки, котрі додаються
спочатку повинні бути включені до
<emphasis>testing</emphasis>, для того щоб через деякий
час бути доданими в наступний випуск
<emphasis>stable</emphasis>.  sid містить пакунки як для
випущених, так і для невипущених
архітектур.
</para>
<para>
Ім'я sid також прийшло з „Toy Story“; так звали
сусідського хлопчака, котрий ламав іграшки
:o)
</para>
<para>
<footnote><para> Коли теперішнього sid ще не було, у
організації FTP-сайтів був недолік: робилось
припущення, що архітектура, внесена до
поточної нестабільної версії, буде додана
у наступну стабільну.  Для багатьох
архітектур цього не відбувалось і в момент
випуску нової версії відповідні теки
переміщувались.  Це було непрактичним, бо
сильно навантажувало пропускні лінії.  </para>
<para> Адміністратори архівів працювали над
цією проблемою кілька років, розміщуючи
двійкові пакунки для невипущених
архітектур у спеціальну теку sid.  При
першому їх випуску робились посилання з
поточної стабільної версії у sid і відтоді
вони, зазвичай, створювались всередині
нестабільної гілки.  Таке розміщення
призводило до непорозумінь з
користувачами.  </para> <para> З появою
пакункових пулів (див.  <xref linkend="pools"/>)
двійкові пакунки почали розміщувати в теці
pool незалежно від збірки, тож випуск нової
версії перестав спричиняти інтенсивне
навантаження на канали дзеркал (натомість,
воно поступово зростає під час розробки).
</para> </footnote>
</para>
</section>

<section id="stable"><title>Що міститься в теці stable?</title>
<itemizedlist>
<listitem>
<para>
stable/main/: Ця тека містить пакунки, що
формально складають найсвіжішу версію Debian
GNU/Linux.
</para>
<para>
Всі ці пакунки сформовано згідно з <ulink
url="http://www.debian.org/social_contract#guidelines">критеріями
Debian щодо вільного програмного
забезпечення (DFSG)</ulink> і вони повністю
готові до вживання та поширення.
</para>
</listitem>
<listitem>
<para>
stable/non-free/: В цій теці знаходяться пакунки,
поширення яких обмежується в спосіб, що
вимагає від поширювача дотримуватись
специфічних копірайтних умов.
</para>
<para>
Наприклад, деякі пакунки поширюються під
ліцензіями, що забороняють комерційне
поширення.  Інші дозволяють поширювати, але
як умовно-безкоштовне, а не вільне
програмне забезпечення.  Ліцензії всіх цих
пакунків повинні бути детально вивченими
та, можливо, узгодженими, перш ніж їх додати
у якусь збірку (наприклад, на КД).
</para>
</listitem>
<listitem>
<para>
stable/contrib/: Ця тека містить пакунки, що є
вільними з точки зору DFSG та можуть
<emphasis>вільно поширюватись</emphasis> самі по
собі, але якимось чином залежать від
пакунків, що <emphasis>не</emphasis> можуть
поширюватись вільно і, отже, знаходяться у
секції non-free.
</para>
</listitem>
</itemizedlist>
</section>

<section id="testing"><title>Що міститься в теці testing?</title>
<para>
Пакунки переносяться в теку testing після
того, як пройдуть деякі етапи тестування в
<link linkend="unstable">unstable</link>.
</para>
<para>
Вони мусять узгоджуватись з усіма
архітектурами, у які їх будуть переносити
та не повинні мати залежностей, що зроблять
їх непридатними до встановлення; вони
також повинні мати якомога менше блокуючих
випуск помилок в тих версіях, що входять у
testing.  Таким чином ми сподіваємось, що testing
завжди достатньо готовий щоб бути
кандидатом до випуску.
</para>
<para>
Додаткову інформацію про статус testing в
цілому та кожного пакунка зокрема можна
отримати на <ulink
url="http://www.debian.org/devel/testing">http://www.debian.org/devel/testing</ulink>.
</para>
<section id="frozen"><title>Як щодо testing? Чому вона заморожується?</title>
<para>
Як тільки тестова збірка стає достатньо
зрілою, керівник випуску „заморожує“ її.
Прийняття пакунків до неї сповільнюється
та подовжується в часі, щоб переконатись,
що з нестабільної збірки в тестову
перейшла мінімальна кількість помилок.
</para>
<para>
Через деякий час тестова збірка стає
повністю замороженою.  Це означає, що всі
нові пакунки, які подаються до тестової
версії, не буде прийнято до тих пір, поки
вони містять критичні, блокуючі випуск
помилки.  Тестова збірка може залишатись у
такому повністю замороженому режимі під
час так званого „тестового циклу“, аж поки
випуск не стає неминучим.
</para>
<para>
Ми ведемо записи про помилки в testing, котрі
можуть затримати випуск якогось пакунка, і
помилок, що можуть затримати випуск
повністю.  За деталями зверніться до <ulink
url="http://www.debian.org/releases/testing/">інформації про
поточний тестовий випуск</ulink>.
</para>
<para>
Як тільки кількість помилок знижується до
прийнятних значень, заморожена тестова
збірка оголошується стабільною та
випускається з номером версії.
</para>
<para>
З кожним новим стабільним випуском
попередній стає застарілим та поміщається
в архів.  За додатковою інформацією
перегляньте сторінку <ulink
url="http://www.debian.org/distrib/archive">архіву Debian</ulink>.
</para>
</section>

</section>

<section id="unstable"><title>Що знаходиться в теці unstable?</title>
<para>
Тека unstable містить знімок поточної
розроблюваної системи.  Користувачів
запрошують використовувати та перевіряти
ці пакунки, але попереджають про стан їх
готовності.  Переваги використання
нестабільної версії в тому, що ви завжди
знаходитесь на вістрі індустрії
програмного забезпечення GNU/Linux, але якщо
щось зламається: you get to keep both parts :-)
</para>
<para>
В теці unstable також знаходяться підтеки main,
contrib і non-free; пакунки в них розподіляються за
тими ж критеріями, що й в stable.
</para>
</section>

<section id="archsections"><title>Що це за теки в <literal>dists/stable/main</literal>?</title>
<para>
Всередині кожного основного дерева тек
<footnote><para> <literal>dists/stable/main</literal>,
<literal>dists/stable/contrib</literal>,
<literal>dists/stable/non-free</literal>,
<literal>dists/unstable/main/</literal>, тощо; </para> </footnote>, є
три набори підтек, що містять індексні
файли.
</para>
<para>
Один набір — це теки
<literal>binary-<replaceable>дещо</replaceable></literal>, що
містять індексні файли для двійкових
пакунків кожної доступної архітектури,
наприклад <literal>binary-i386</literal> для пакунків, що
будуть виконуватись на машинах Intel x86, чи
<literal>binary-sparc</literal> для пакунків, що будуть
виконуватись на робочих станціях Sun
SPARCStations.
</para>
<para>
Повний список доступних архітектур для
кожного випуску доступний на <ulink
url="http://www.debian.org/releases/">присвяченій випуску
веб-сторінці</ulink>.  Для поточного випуску,
будь ласка, перегляньте <xref linkend="arches"/>.
</para>
<para>
Індексні файли у binary-* називаються Packages(.gz) і
містять резюме для кожного двійкового
пакунку, що включений у збірку.  Поточні
двійкові пакунки (для <emphasis>woody</emphasis> та
наступних випусків) знаходяться на
верхньому рівні <link linkend="pools">теки
<literal>pool</literal></link>.
</para>
<para>
Крім того існує підтека source/, котра містить
індексні файли для джерельних пакунків,
включених у збірку.  Індексний файл
називається Sources(.gz).
</para>
<para>
І останнє, але не менш важливе — є набір
підтек, призначених для файлів системи
встановлення.  У випуску <emphasis>woody</emphasis>
вони називаються
<literal>disks-<replaceable>архітектура</replaceable></literal>; в
<emphasis>sarge</emphasis> —
<literal>debian-installer/binary-<replaceable>архітектура</replaceable></literal>.
</para>
</section>

<section id="source"><title>А де джерельні коди?</title>
<para>
Джерельний код є для будь-чого з системи
Debian.  Більш того, ліцензійні положення
більшості програм у системі
<emphasis>вимагають</emphasis>, щоб разом з
програмою розповсюджувався джерельний
код, або ж пропонують це робити.
</para>
<para>
Джерельні коди знаходяться в теці pool (див.
<xref linkend="pools"/>) разом з усіма
архітектурно-специфічними теками для
двійкових пакунків.  Щоб отримати
джерельний код без ознайомлення з
структурою FTP-архіву, спробуйте команду на
кшталт <literal>apt-get source назва_пакунка</literal>.
</para>
<para>
Деякі пакунки поширюються винятково у
джерельних кодах через їх ліцензійні
обмеження.  В першу чергу це стосується
<literal>pine</literal>, перегляньте <xref linkend="pine"/> щоб
отримати більше інформації.
</para>
<para>
Джерельні коди можуть і не бути доступними
для пакунків, що розташовані в теках contrib та
non-free, що формально не є частиною системи
Debian.
</para>
</section>

<section id="pools"><title>Що за тека — <literal>pool</literal>?</title>
<para>
Пакунки зберігаються у величезному
сховищі (pool), структурованому за назвами
джерельних пакунків.  Щоб зробити це діло
керованим, сховище поділяється по секціям
(main, contrib та non-free) та по перших літерах назв
джерельних пакунків.  Ці теки містять
декілька файлів: двійкові пакунки для
кожної архітектури та джерельні пакунки, з
яких формуються двійкові.
</para>
<para>
Ви можете дізнатись місцезнаходження
кожного пакунка виконавши команду
<literal>apt-cache showsrc назва_пакунка</literal> та
подивившись на рядок „Directory:“.  Наприклад,
пакунки <literal>apache</literal> знаходяться в
<literal>pool/main/a/apache/</literal>.
</para>
<para>
Крім цього, оскільки пакунків <literal>lib*</literal>
дуже багато, вони розглядаються особливим
чином: наприклад, пакунки libpaper знаходяться
в теці <literal>pool/main/libp/libpaper/</literal>.
</para>
<para>
<footnote><para> Історично склалося так, що
пакунки зберігались у підтеці
<literal>dists</literal> збірки, до котрої вони
належали.  Це спричиняло деякі проблеми, як
наприклад велике завантаження пропускних
каналів дзеркал при виході нових версій.
Ця проблема була вирішена введенням
єдиного сховища пакунків.  </para> <para> Теки
<literal>dists</literal> досі використовуються для
зберігання індексних файлів, котрі в свою
чергу використовуються програмами на
кшталт <literal>apt</literal>.  Ви також можете
зустріти шляхи <literal>dists/potato</literal> чи
<literal>dists/woody</literal> у полі заголовку Filename
деяких старих пакунків.  </para> </footnote>
</para>
</section>

<section id="incoming"><title>Що таке incoming?</title>
<para>
Після того, як супроводжувач завантажує
пакунок на сервер сховища, він деякий час
знаходиться в теці „incoming“, доки не буде
перевірено, що він є справжнім і додано
його до архіву.
</para>
<para>
Як правило, ніхто не повинен встановлювати
пакунки звідти, проте, на випадок деяких
рідкісних, надзвичайних ситуацій тека incoming
доступна за адресою <ulink
url="http://incoming.debian.org/">http://incoming.debian.org/</ulink>.  Ви
можете вручну викачувати пакунки і,
перевіривши PGP-підписи та md5-суми в файлах
.changes i.dsc, встановлювати їх.
</para>
</section>

<section id="ownrepository"><title>Як мені створити своє власне apt-сумісне сховище?</title>
<para>
Якщо ви хочете збудувати деякі власні
пакунки Debian, які б ви хотіли встановлювати
за допомогою стандартних інструментів
управління пакунками Debian, ви можете
створити ваш власний apt-сумісний архів
пакунків.  Це також корисно, якщо ви не
хотіли б оприлюднювати ваші пакунки, доки
їх не буде включено до проекту Debian.
Вказівки щодо того, як це можна зробити ви
знайдете в <ulink
url="http://www.debian.org/doc/manuals/repository-howto/repository-howto">Debian
Repository HOWTO</ulink>.
</para>
</section>

</chapter>