<!-- Subversion revision of original English document "3607" -->
<chapt id="ftparchives">FTP-архіви Debian

<sect id="dirtree">Що означають всі ті теки на ftp-архівах Debian?

<p>Програмне забезпечення у вигляді пакунків для &debian; доступне у одному 
з декількох дерев тек на кожному дзеркальному сайті Debian. 

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

<p>Тека <tt>pool</tt> містить поточні пакунки, перегляньте
<ref id="pools">.

<p>Існують такі додаткові теки:
<taglist>
  <tag><em>/tools/</em>:
    <item>DOS-утиліти для створення завантажувальних дисків, поділу вашого диску 
          на розділи, стиснення/розстиснення файлів та завантаження Linux. 
  <tag><em>/doc/</em>:
    <item>Основна документація Debian, така як FAQ, інструкції до системи 
          відслідковування помилок та ін.
  <tag><em>/indices/</em>:
    <item>Файл Maintainers та файли override.
  <tag><em>/project/</em>:
    <item>Переважно матеріали, що призначені для розробників, наприклад:
    <taglist>
      <tag><em>project/experimental/</em>:
        <item>Ця тека містить пакунки та інструменти, які все ще розробляються 
        і знаходяться в режимі попереднього тестування. Користувачі не повинні 
        використовувати пакунки звідси, тому що це може бути небезпечно і завдати 
        шкоди навіть для системи під керуванням доволі досвідченої людини.
    </taglist>
</taglist>

<sect id="dists">Скільки збірок Debian знаходиться в теці <tt>dists</tt>?

<p>Є три збірки&nbsp;— стабільна (stable), тестова (testing) та нестабільна (unstable). 
Тестова збірка іноді „заморожується“ (frozen) (див. <ref id="frozen">).

<sect id="codenames">Що означають всі ці імена на кшталт slink, potato та ін.?

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

<p>На даний момент <tt>stable</tt> є символічним посиланням на <tt>&releasename;</tt> 
(себто &debian; &release;), а <tt>testing</tt>&nbsp;— на <tt>&testingreleasename;</tt>. 
Тобто <tt>&releasename;</tt> є поточною стабільною версією, а <tt>&testingreleasename;</tt>&nbsp;— 
тестовою. 

<p><tt>unstable</tt> є постійним символічним посиланням на <tt>sid</tt>, оскільки
<tt>sid</tt>&nbsp;— це завжди нестабільна збірка (перегляньте <ref id="sid">).

<sect1 id="oldcodenames">Які кодові назви вже використовувались?

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

<sect1 id="sourceforcodenames">Звідки беруться всі ці імена?

<p>Це все імена персонажів з мультфільму „Toy Story“ компанії Pixar.
<list>
  <item><em>buzz</em> (Buzz Lightyear) був космонавтом,
  <item><em>rex</em> був тиранозавром,
  <item><em>bo</em> (Bo Peep) дівчинка, котра опікувалась овечкою,
  <item><em>hamm</em> був поросям-скарбничкою,
  <item><em>slink</em> (Slinky Dog®) був іграшковим песиком,
  <item><em>potato</em> це, звісно, пан Potato®,
  <item><em>woody</em> був ковбоєм,
  <item><em>sarge</em> був сержантом Зеленою Пластикової Армії,
  <item><em>etch</em> це іграшкова класна дошка (Etch-a-Sketch®).

<!-- SID should be the last line always -->
  <item><em>sid</em> був сусідським хлопчаком, котрий ламав іграшки.
</list>

<!-- Q: Should we add the trademark info here? Maybe as a footnote
  Mr. Potato is a Registered Trademark of Playskool, Inc.,
    Pawtucket, R.I., a division of Hasbro Inc.
  Slinky Dog is a trademark of Poof Products of Plymouth, Mich.,
  Etch-a-Sketch is a trademark of The Ohio Art Company,
  other characters might also be registered trademarks...
  (jfs)
-->
<!--
  more info in http://www.pixar.com/featurefilms/ts/
  and  http://www.pixar.com/featurefilms/ts2/
  or better yet http://us.imdb.com/M/title-exact?Toy%20Story%20(1995)
  or actually:
    http://us.imdb.com/Title?0114709 for TS1
    http://us.imdb.com/Title?0120363 for TS2
  we shouldn't put the links in, Pixar needs no additional propaganda
-->
<!--
  characters not used from Toy Story (yet):
    - Andy (the kid)
    - Snake
    - Robot
    - Scud (Sid's dog)
    - Lenny the Binoculars
    - Three Eyed Alien
    - Rocky (the wrestling figure)
    - Roller Bob (the remote control car)
    - Legs (one of sid's mutant toys)
    - Hand-in-the-box (one of sid's mutant toys)
    - Duckie (one of sid's mutant toys)
  and additional characters from Toy Story 2, also not yet used:
    - Al (the propietor of Al's Toy Farm)
    - Jessie (the Yodelling Cowgirl)
    - Bullseye (Woody's toy horse)
    - Zurg (the Evil Emperor)
    - Wheezy (the penguin)
    - Hannah (owner of Jessie)
    - Stinky Pete the Prospector (the old fat guy)
    - Mrs. Davis (Andy's Mom)
    - Barbie (the Tour Guide, probably under (c))
    - Mrs. Potato Head
    - Heimlich the Caterpillar
-->
<!-- (jfs) Just in case somebody misses the "What do we do when we finish
with Toy Story characters" thread see:
http://lists.debian.org/debian-devel/2002/debian-devel-200207/msg01133.html
I, suggested we followed with either Monster's Inc or "A Bug's life" :)
-->

<sect id="sid">Ну а як щодо „sid“?

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

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

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

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

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

<sect id="stable">Що міститься в теці stable?

<p><list>
  <item>stable/main/:  Ця тека містить пакунки, що формально складають найсвіжішу версію &debian;.

  <p>Всі ці пакунки сформовано згідно з <url name="критеріями Debian щодо вільного 
  програмного забезпечення (DFSG)" id="http://www.debian.org/social_contract#guidelines"> 
  і вони повністю готові до вживання та поширення. 

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

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

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

<sect id="testing">Що міститься в теці testing?

<p>Пакунки переносяться в теку testing після того, як пройдуть деякі 
етапи тестування в <qref id="unstable">unstable</qref>.

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

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

<sect1 id="frozen">Як щодо testing? Чому вона заморожується?

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

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

<p>Ми ведемо записи про помилки в testing, котрі можуть затримати випуск якогось 
пакунка, і помилок, що можуть затримати випуск повністю. За деталями зверніться 
до  <url name="інформації про поточний тестовий випуск"
id="http://www.debian.org/releases/testing/">. 

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

<p>З кожним новим стабільним випуском попередній стає застарілим та поміщається 
в архів. За додатковою інформацією перегляньте сторінку
<url name="архіву Debian" id="http://www.debian.org/distrib/archive">. 

<sect id="unstable">Що знаходиться в теці unstable?

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

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

<sect id="archsections">Що це за теки в <tt>dists/stable/main</tt>?

<p>Всередині кожного основного дерева тек <footnote>
  <tt>dists/stable/main</tt>, <tt>dists/stable/contrib</tt>,
  <tt>dists/stable/non-free</tt>, <tt>dists/unstable/main/</tt>, тощо;
</footnote>, є три набори підтек, що містять індексні файли.

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

<p>Повний список доступних архітектур для кожного випуску доступний на 
<url name="присвяченій випуску веб-сторінці" id="http://www.debian.org/releases/">.
Для поточного випуску, будь ласка, перегляньте <ref id="arches">.

<p>Індексні файли у binary-* називаються Packages(.gz) і містять резюме 
для кожного двійкового пакунку, що включений у збірку. Поточні двійкові пакунки 
(для <em/woody/ та наступних випусків) знаходяться на верхньому рівні
<qref id="pools">теки <tt/pool/</qref>.

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

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

<sect id="source">А де джерельні коди?

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

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

<p>Деякі пакунки поширюються винятково у джерельних кодах через їх ліцензійні
обмеження. В першу чергу це стосується <tt>pine</tt>, перегляньте <ref id="pine">
щоб отримати більше інформації. 

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

<sect id="pools">Що за тека&nbsp;— <tt>pool</tt>?

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

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

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

<!-- joeyh doesn't want to maintain it so it's dead; need to integrate it
     If you want more information, see the
     <url id="http://people.debian.org/~joeyh/poolfaq"
     name="Debian Package Pools FAQ">.
-->

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

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

<sect id="incoming">Що таке incoming?

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

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

<sect id="ownrepository">Як мені створити своє власне apt-сумісне сховище?

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