[ назад ] [ Зміст ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ далі ]
Програмне забезпечення у вигляді пакунків для Debian GNU/Linux доступне у одному з декількох дерев тек на кожному дзеркальному сайті Debian.
Тека dists це скорочення від „distributions“ (дистрибутиви, збірки); вона є канонічним шляхом для отримання доступу до існуючих на даний момент версій Debian.
Тека pool містить поточні пакунки, перегляньте Що за тека — pool?, розділ 5.10.
Існують такі додаткові теки:
DOS-утиліти для створення завантажувальних дисків, поділу вашого диску на розділи, стиснення/розстиснення файлів та завантаження Linux.
Основна документація Debian, така як FAQ, інструкції до системи відслідковування помилок та ін.
Файл Maintainers та файли override.
Переважно матеріали, що призначені для розробників, наприклад:
Ця тека містить пакунки та інструменти, які все ще розробляються і знаходяться в режимі попереднього тестування. Користувачі не повинні використовувати пакунки звідси, тому що це може бути небезпечно і завдати шкоди навіть для системи під керуванням доволі досвідченої людини.
Є три збірки — стабільна (stable), тестова (testing) та нестабільна (unstable). Тестова збірка іноді „заморожується“ (frozen) (див. Як щодо testing? Чому вона заморожується?, розділ 5.6.1).
Це просто умовні кодові назви. Коли збірка Debian знаходиться в стадії розробки, вона не має номера версії, а лише умовну назву. Вони використовуються щоб полегшити віддзеркалення збірок Debian (якщо справжня тека, наприклад, unstable раптом змінить свою назву на stable, потрібно буде заново переписувати занадто багато файлів).
На даний момент stable є символічним посиланням на sarge (себто Debian GNU/Linux 3.1), а testing — на etch. Тобто sarge є поточною стабільною версією, а etch — тестовою.
unstable є постійним символічним посиланням на sid, оскільки sid — це завжди нестабільна збірка (перегляньте Ну а як щодо „sid“?, розділ 5.4).
Окрім вищезгаданих використовувались наступні кодові назви: 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 або unstable — це місце куди початково завантажуються всі пакунки. Вони ніколи не додаються відразу в збірку, тому що пакунки, котрі додаються спочатку повинні бути включені до testing, для того щоб через деякий час бути доданими в наступний випуск stable. sid містить пакунки як для випущених, так і для невипущених архітектур.
Ім'я sid також прийшло з „Toy Story“; так звали сусідського хлопчака, котрий ламав іграшки :o)
[1]
stable/main/: Ця тека містить пакунки, що формально складають найсвіжішу версію Debian GNU/Linux.
Всі ці пакунки сформовано згідно з критеріями
Debian щодо вільного програмного
забезпечення (DFSG)
і вони повністю
готові до вживання та поширення.
stable/non-free/: В цій теці знаходяться пакунки, поширення яких обмежується в спосіб, що вимагає від поширювача дотримуватись специфічних копірайтних умов.
Наприклад, деякі пакунки поширюються під ліцензіями, що забороняють комерційне поширення. Інші дозволяють поширювати, але як умовно-безкоштовне, а не вільне програмне забезпечення. Ліцензії всіх цих пакунків повинні бути детально вивченими та, можливо, узгодженими, перш ніж їх додати у якусь збірку (наприклад, на КД).
stable/contrib/: Ця тека містить пакунки, що є вільними з точки зору DFSG та можуть вільно поширюватись самі по собі, але якимось чином залежать від пакунків, що не можуть поширюватись вільно і, отже, знаходяться у секції non-free.
Пакунки переносяться в теку testing після того, як пройдуть деякі етапи тестування в unstable.
Вони мусять узгоджуватись з усіма архітектурами, у які їх будуть переносити та не повинні мати залежностей, що зроблять їх непридатними до встановлення; вони також повинні мати якомога менше блокуючих випуск помилок в тих версіях, що входять у testing. Таким чином ми сподіваємось, що testing завжди достатньо готовий щоб бути кандидатом до випуску.
Додаткову інформацію про статус testing в
цілому та кожного пакунка зокрема можна
отримати на http://www.debian.org/devel/testing
.
Як тільки тестова збірка стає достатньо зрілою, керівник випуску „заморожує“ її. Прийняття пакунків до неї сповільнюється та подовжується в часі, щоб переконатись, що з нестабільної збірки в тестову перейшла мінімальна кількість помилок.
Через деякий час тестова збірка стає повністю замороженою. Це означає, що всі нові пакунки, які подаються до тестової версії, не буде прийнято до тих пір, поки вони містять критичні, блокуючі випуск помилки. Тестова збірка може залишатись у такому повністю замороженому режимі під час так званого „тестового циклу“, аж поки випуск не стає неминучим.
Ми ведемо записи про помилки в testing, котрі
можуть затримати випуск якогось пакунка, і
помилок, що можуть затримати випуск
повністю. За деталями зверніться до інформації про
поточний тестовий випуск
.
Як тільки кількість помилок знижується до прийнятних значень, заморожена тестова збірка оголошується стабільною та випускається з номером версії.
З кожним новим стабільним випуском
попередній стає застарілим та поміщається
в архів. За додатковою інформацією
перегляньте сторінку архіву Debian
.
Тека unstable містить знімок поточної розроблюваної системи. Користувачів запрошують використовувати та перевіряти ці пакунки, але попереджають про стан їх готовності. Переваги використання нестабільної версії в тому, що ви завжди знаходитесь на вістрі індустрії програмного забезпечення GNU/Linux, але якщо щось зламається: you get to keep both parts :-)
В теці unstable також знаходяться підтеки main, contrib і non-free; пакунки в них розподіляються за тими ж критеріями, що й в stable.
Всередині кожного основного дерева тек [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-архітектура.
Джерельний код є для будь-чого з системи Debian. Більш того, ліцензійні положення більшості програм у системі вимагають, щоб разом з програмою розповсюджувався джерельний код, або ж пропонують це робити.
Джерельні коди знаходяться в теці pool (див. Що за тека — pool?, розділ 5.10) разом з усіма архітектурно-специфічними теками для двійкових пакунків. Щоб отримати джерельний код без ознайомлення з структурою FTP-архіву, спробуйте команду на кшталт apt-get source назва_пакунка.
Деякі пакунки поширюються винятково у джерельних кодах через їх ліцензійні обмеження. В першу чергу це стосується pine, перегляньте Куди подівся pine?, розділ 4.10 щоб отримати більше інформації.
Джерельні коди можуть і не бути доступними для пакунків, що розташовані в теках contrib та non-free, що формально не є частиною системи Debian.
Пакунки зберігаються у величезному сховищі (pool), структурованому за назвами джерельних пакунків. Щоб зробити це діло керованим, сховище поділяється по секціям (main, contrib та non-free) та по перших літерах назв джерельних пакунків. Ці теки містять декілька файлів: двійкові пакунки для кожної архітектури та джерельні пакунки, з яких формуються двійкові.
Ви можете дізнатись місцезнаходження кожного пакунка виконавши команду apt-cache showsrc назва_пакунка та подивившись на рядок „Directory:“. Наприклад, пакунки apache знаходяться в pool/main/a/apache/.
Крім цього, оскільки пакунків lib* дуже багато, вони розглядаються особливим чином: наприклад, пакунки libpaper знаходяться в теці pool/main/libp/libpaper/.
[3]
Після того, як супроводжувач завантажує пакунок на сервер сховища, він деякий час знаходиться в теці „incoming“, доки не буде перевірено, що він є справжнім і додано його до архіву.
Як правило, ніхто не повинен встановлювати
пакунки звідти, проте, на випадок деяких
рідкісних, надзвичайних ситуацій тека incoming
доступна за адресою http://incoming.debian.org/
.
Ви можете вручну викачувати пакунки і,
перевіривши PGP-підписи та md5-суми в файлах
.changes i.dsc, встановлювати їх.
Якщо ви хочете збудувати деякі власні
пакунки 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 року