[ назад ] [ Зміст ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ далі ]


FAQ Debian GNU/Linux
Глава 5 - FTP-архіви Debian


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

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

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

Тека pool містить поточні пакунки, перегляньте Що за тека — pool?, розділ 5.10.

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

/tools/:

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

/doc/:

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

/indices/:

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

/project/:

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

project/experimental/:

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


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

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


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

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

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

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


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

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


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

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


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

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

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

[1]


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


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

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

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

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


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

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

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

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

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

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


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

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

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


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

Всередині кожного основного дерева тек [2], є три набори підтек, що містять індексні файли.

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

Повний список доступних архітектур для кожного випуску доступний на присвяченій випуску веб-сторінці. Для поточного випуску, будь ласка, перегляньте На яких апаратних архітектурах та системах запускається Debian GNU/Linux?, розділ 3.1.

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

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

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


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

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

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

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

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


5.10 Що за тека — pool?

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

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

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

[3]


5.11 Що таке incoming?

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

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


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

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


[ назад ] [ Зміст ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ далі ]


FAQ Debian GNU/Linux

версія CVS від 19 червня 2006 року

Автори перераховані в Debian FAQ Authors