02

← 01 | Reference | 03 →

Розділ 2. Основи Дебіен

В цьому розділі міститься базова інформація про систему Дебіен для нерозробників. За додатковою інформацією звертайтесь до:

Підручника з політики Дебіен
Довідника розробника Дебіен
Посібника нового поширювача Дебіен

що перераховані у ?параграфі 15.1.

Якщо ви шукаєте детальне ЯКЦЕ, перейдіть безпосередньо до розділу 6 чи інших доречних глав.

Цей розділ в основному базується на ЧАПах Дебіен, серйозно реорганізованих для того, щоб розпочати роботу звичайного системного адміністратора Дебіен.

Архіви Дебіен

Структура каталогів

Програмне забезпечення, що було запаковане для Дебіен, доступне в одному з каталогів на будь-якому з дзеркал Дебіен через ftp чи http. На кожному з них у каталозі debian можна знайти наступні підкаталоги:

dists/ : Цей каталог містить збірки і використовується для забезпечення канонічного методу доступу до поточних пакунків у збірках Дебіен. Тут досі розміщуються деякі старі пакунки та файли Contents-*.gz та Packages.gz.

pool/ : Насправді всі пакунки Дебіен розміщуються тут.

tools/ : Інструменти DOS для створення завантажувальних дисків, розподілу дискового простору, стискання/розтискання файлів та завантаження Лінукс.

doc/ : Основна документація Дебіен, як наприклад ЧАПи, інструкції до системи відслідковування помилок та ін.

indices/ : Файл Maintainers та відкинуті файли.

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

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

project/orphaned/ : Пакунки, покинуті їхніми супроводжувачами та виключені зі збірок.

Збірки Дебіен

Типово в каталозі dists є три збірки Дебіен. Вони називаються stable (стабільна), testing (тестова) та unstable (нестабільна). Іноді ще появляється frozen (заморожена) збірка. Кожна з них є симлінком на справжній каталог з кодовою назвою в каталозі dists.

Стабільна збірка

Пакунки, що відносяться до стабільної збірки Дебіен - Sarge (версія 3.1), записані у каталог stable (симлінк на каталог sarge/).

stable/main/ : Цей каталогі містить версії пакунків, що належать до найсвіжішого стабільного офіційного випуску Дебіен. Всі пакунки є вільними; це означає, що всі вони відповідають Директивам Дебіен щодо Вільного Програмного Забезпечення (ДДВПЗ; Debian Free Software Guidelines, DFSG) (документ доступний у каталозі /usr/share/doc/debian/social-contract.txt після встановлення пакунку debian-doc).

stable/non-free/ : Цей каталог містить пакунки, що не відповідають ДДВПЗ. До прикладу, деякі пакунки поширюються під ліцензіями, що забороняють їх комерційне розповсюдження. Інші можуть розповсюджуватись лише як умовно-безкоштовне ПЗ (shareware).

stable/contrib/ : Кожен пакунок у цьому каталозі сам по собі відповідає ДДВПЗ, але якимось чином залежить від пакунків, що не відповідають їм.

Тепер, на додачу до вищеперелічених, фізично пакунки розташовані в каталозі pool (див. параграф 2.1.10).

Поточний статус помилок стабільного випуску звітується на сторінці тенет http://ftp-master.debian.org/testing/stable_probs.html.

Тестова збірка

Пакети, що відносяться до тестової збірки Дебіен – Etch, розташовуються у каталозі testing (симлінк на каталог etch/) після того, як пройдуть ряд тестів у unstable. Тепер, на додачу до вищенаведених, вони фізично розташовані у каталозі pool. Як і в каталозі stable/, в testing/ також є підкаталоги main, contrib та non-free.

Ці пакунки повинні бути синхронізовані на всіх архітектурах і всюди повинні встановлюватись; вони також не повинні містити критичних помилок. Таким чином ми сподіваємось, що testing завжди близький до того, щоб бути кандидатом до випуску. Додаткові деталі про механізм тестування можна знайти на http://www.debian.org/devel/testing.

Найсвіжіші новини про стан тестової збірки можна знайти ось тут:

Нестабільна збірка

Пакунки з нестабільної збірки, котра завжди має назву Sid, записуються у каталог iunstable (симлінк на sid). Фізично вони також розташовані у каталозі pool. Як і попередники, каталог unstable також містить підкаталоги main, contrib i non-free.

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

Поточний стан помилок нестабільної збірки описується на сторінці http://ftp-master.debian.org/testing/unstable_probs.html.

Заморожена збірка

Після того, як тестова збірка майже готова до виходу, вона заморожується, що означає, що в неї більше не включаються нові пакунки, а лише виправлення до існуючих. Окрім того, у каталозі dists створюється новий підкаталог testing, котрому присвоюється нове кодове ім'я. Заморожена збірка ще кілька місяців тестується з переривчастими оновленнями та глибокими замороженнями, котрі називаються “тестовими циклами”.

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

Кодові назви збірок Дебіен

Фізичні імена каталогів в каталозі dists, такі як sarge/ та etch/ є лише кодовими назвами. Коли збірка Дебіен знаходиться в стані розробки, вона не має номеру версії, а лише кодову назву. Призначення цих назв у спрощенні віддзеркалення збірок Дебіен (якщо справжній каталог, наприклад unstable/ раптом змінить своє ім'я на stable/, виникне необхідність у повторному завантаженні величезної кількості інформації).

На даний момент stable/ є символьним лінком на sarge/, а testing/ - на etch/. Це означає, що Sarge є поточною стабільною збіркою, а Etch – поточною тестовою збіркою.

unstable/ є постійним символьним лінком на sid/, оскільки Sid є постійною кодовою назвою тестової збірки.

Кодові назви, що використовувались у минулому

До цього часу використовувались такі кодові назви випусків Дебіен: "Buzz" для випуску 1.1, "Rex" для випуску 1.2, "Bo" для випусків 1.3.x, "Hamm" для випуску 2.0, "Slink" для випуску 2.1, "Potato" для випуску 2.2, "Woody" для випуску 3.0, і "Sarge" для випуску 3.1.

Походження кодових назв

Досі це все були персонажі мультика Toy Story (Історія іграшок) компанії Піксар (Pixar).

Buzz (Buzz Lightyear) був космонавтом,
Rex був тиранозавром,
Bo (Bo Peep) – дівчинка, що піклувалась про кораблик,
Hamm – свинка-скарбничка,
Slink (Slinky Dog) був іграшковим собачкою,
Potato був, звісно, Паном Головним Картоплиною,
Woody був ковбоєм,
Sarge був головнокомандуючим Зеленої Пластикової Армії,
Etch (Etch-a-Sketch) була шкільною дошкою,
Sid був сусідським хлопчаком, що постійно нищив іграшки.

Каталог pool

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

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

Ви можете дізнатись про розташування кожного пакунку виконавши команду на кшталт apt-cache showsrc назва_пакунку та глянувши на рядок "Каталог" ("Directory"). Наприклад, пакунки apache зберігаються в pool/main/a/apache/. Оскільки є дуже багато пакунків, назви котрих розпочинаються з lib, то для них створюються каталоги з чотирьох літер: наприклад, libpaper знаходиться в каталозі pool/main/libp/libpaper/.

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

Як правило, вам не потрібно хвилюватись про все це, так як новий apt, та, можливо, старіший dpkg-ftp обробляють їх (шляхи) коректно. Якщо вам потрібна додаткова інформація, зверністься до сторінки http://lists.debian.org/debian-devel-announce/2000/debian-devel-announce-200010/msg00007.html.

Історичні примітки про Sid

Коли Sid’а, котрого ми знаємо зараз, ще не було, організація архівних сайтів Дебіен мала один суттєвий недолік: підрозумівалось, що якщо в поточну нестабільну версію додавалась підтримка нової архітектури, вона буде додана у наступний стабільний випуск. Для багатьох архітектур цього не відбувалось, що призводило до переміщення відповідних каталогів у момент випуску, а це у свою чергу призводило до перевантаження каналів зв'язку із-за необхідності повторно завантажувати великі об'єми інформації.

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

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

Пакунки виванатажені у incoming/

Первинно вивантажені пакунки зберігаються в http://incoming.debian.org/ перш ніж вони пройдуть перевірку, чи справді їх вивантажили розробники Дебіен (і переміщуються у каталог DELAYED (англ. "відкладені") у випадку якщо їх вивантажив не офіційний поширювач). Одного дня вони переміщуються з incoming/ до unstable/.

У крайньому випадку ви маєте можливість встановити пакунки з каталогу incoming/ до того як вони потраплять у unstable/.

Отримання старіших пакунків

В той час як більшість найсвіжіших збірок Дебіен зберігаються у каталозі debian на кожному дзеркальному сайті Дебіен, архіви попередніх збірок, як наприклад Слінк, зберігаються на http://archive.debian.org/, або в каталозі debian-archive на дзеркальних сайтах. Старі пакунки для testing i unstable можна знайти на http://snapshot.debian.net/.

Секції архітектур

Всередині кожного з основних дерев (dists/stable/main, dists/stable/contrib, dists/stable/non-free, dists/unstable/main, і т.д.) двійкові пакунки розміщуються у підкаталозі, назва котрого вказує на чіп, під яких вони були скомпільовані.

binary-all/ : для пакунків, котрі є архітектурно незалежними. Як правило, це сценарії на Перл, чи документація.

binary-platform/ : для пакунків, що виконуються на певній платформі.

Зверніть, будь ласка, увагу, що поточні двійкові пакунки для тестової та нестабільної збірок більше не розташовуються у цих каталогах, а в каталозі верхнього рівня pool. Індексні файли (Packages i Packages.gz), проте, були залишені для зворотньої сумісності.

Щоб дізнатись список підтримуваних архітектур, дивіться Примітки до випуску для кожної збірки. Їх можна знайти на сторінці http://www.debian.org/releases/stable/releasenotes для стабільної версії і на http://www.debian.org/releases/testing/releasenotes для нестабільної.

Джерельні коди

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

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

Деякі пакунки, наприклад pine, доступні лише у джерельних кодах завдяки ліцензійним обмеженням (недавно для спрощення установки pine був розроблений пакунок pine-tracker). Процедура ручного формування пакунку з джерельних кодів описана у параграфах 6.4.10 та ?13.10.

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

Система керування пакунками Дебіен

Огляд пакунків Дебіен

Як правило, пакунки містять всі необхідні файли для того, щоб реалізувати набір певних команд чи особливостей. Є два типи пакунків Дебіен:

Двійкові пакунки, котрі містять виконувані, конфігураційні файли, інформаційні сторінки та сторінки довідки, інформацію про авторські права та інші документи. Ці пакунки поширюються у особливому архівному форматі, визначеному в Дебіен (зверніться до параграфу 2.2.2 за детальнішою інформацією); як правило їх можна відрізнити по розширенню файлу .deb. Двійкові пакунки можна розпакувати за допомогою інструменту dpkg; детальні описані на його сторінці довідки.
Джерельні пакунки, що складаються з файлу .dsc, котрий описує пакунок (включаючи імена наступних файлів), файлу .orig.tar.gz, що містить оригінальний незмінений джерельний код у заархівованому та стиснутому форматі, та файлу .dizz.gz, що містить специфічні для Дебіен зміни оригінального джерельного коду. Інструмент dpkg-source запаковує та розпаковує джерельні архіви Дебіен; деталі розписані на його сторінці довідки.

Встановлення програмного забезпечення за допомогою системи пакунків використовує залежності, що описані поширювачем пакунку. Ці залежності документовані у файлі control, що приєднується до кожного пакунку. Наприклад, пакунок, що містить компілятор GNU C (gcc) залежить від пакунку binutils, що містить в собі лінкер та асемблер. Якщо користувач спробує встановити gcc без встановленого binutils, система керування пакунками видасть повідомлення про необхідність встановлення binutils та припинить встановлення gcc (проте користувач може переозначити таку поведінку; див. dpkg(8)). Додаткові деталі описуються у параграфі 2.2.8.

Пакувальні інструменти Дебіен також можна використовувати для:

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

Формат пакунків Дебіен

Пакунок, або ж архівний файл Дебіен містить виконувані файли, бібліотеки та документацію, пов'язані з конкретним набором програм чи множиною споріднених програм. Як правило, архівний файл Дебіен має назву, що закінчується на .deb [1]

Нутрощі двійкового пакунку описані на сторінці довідки deb(5). Оскільки внутрішній формат є предментом змін (між головними версіями Дебіен), користуйтесь dpkg-deb для маніпуляцій з .deb-файлами.

Як мінімум включно до дистрибутиву Sarge, всі архівні файли Дебіен можна обробляти стандартними командами Юнікс ar та tar, навіть якщо команди dpkg недоступні.

Домовленості щодо називання пакунків Дебіен

Імена пакунків Дебіен описуються наступною домовленістю:

щось_верс-пер_арх.deb

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

dpkg --info назва_файлу

Версія перегляду Дебіен задається розробником Дебіен, чи будь-ким, хто формує пакунок. Її зміна як правило вказує на те, що змінено якісь аспекти пакування.

Збереження локальної конфігурації

Файли, що призначені для зміни локальним адміністратором, зберігаються у каталозі /etc/. Політика Дебіен вказує, що всі зміни у локальних конфігураційних файлах повинні бути збережені при оновленні пакунків.

Якщо типова версія локального конфігураційного файлу знаходиться всередині пакунку, вона обов'язково позначається як "conffile" (конфігураційний файл). Система керування пакунками не поновлює конфігураційні файли, що були змінені адміністратором з часу встановлення без дозволу самого адміністратора. З іншого боку, якщо адміністратор не міняв конфігураційний файл, він буде замінений новішою версією з пакунку. Така поведінка оправдовує себе у переважній більшості випадків.

Щоб отримати список конфігураційних файлів, котрі належать даному пакунку, запустіть наступну команду:

 dpkg --status пакунок

Список міститься у рядку "Конфігураційні файли" ("Conffiles:").

За додатковою інформацією про конфігураційні файли зверніться до Посібника з політики Дебіен, розділ "Конфігураційні файли" (див. "Посилання", ?параграф 15.1).

Сценарії підтримки

Сценарії підтримки в Дебіен - це виконувані сценарії, що автоматично запускаються перед або після встановлення пакунку. Разом з файлом під назвою control фони є частиною керуючої секції архівного файлу Дебіен.

Це такі файли:

preinst : Цей сценарій виконується перед розпаковуванням пакунку з архівного файлу Дебіен. Як правило ці файли зупиняють роботу тих служб, що будуть оновлені під час встановлення пакунку.

postinst : Як правило, цей сценарій завершує необхідні конфігурації пакунку після його успішного розпакування з архівного файлу. Часто він також очікує на ввід користувача та/або попереджує його у випадку залишення типових значень про необхідність конфігурування встановленого пакунку. Окрім того, часто цей сценарій виконує команди, що необхідні для запуску чи перезапуску оновлених служб.

prerm : Цей сценарій як правило зупиняє будь-які асоційовані з пакунком демони. Він виконується перед видаленням файлів, асоційованих з пакунком.

postrm : Цей сценарій як правило змінює лінки чи інші файли, асоційовані з пакунком, та/або видаляє створені ним файли (див. також віртуальні пакунки, параграф 2.2.7).

На даний момент всі контролюючі файли можна знайти у каталозі /var/lib/dpkg/info. Всі файли, що стосуються пакунку foo, мають таку ж саму назву і розширення ".preinst", ".postinst" і т.п. Файл foo.list в цьому ж каталозі перераховує всі файли, що встановлені цим пакунком (зауважте, що розміщення цих файлів описується внутрішнім форматом dpkg і може бути змінено).

Пріоритети пакунків

Кожному пакунку в Дебіен поширювачами задається пріоритет, як допомога системі керування пакунками. Є наступні пріоритети:

необхідні (required) - пакунки, що необхідні для функціонування системи. Сюди входять всі інструменти, що необхідні для усунення дефектів системи. Ви не повинні видаляти ці пакунки, або ж ваша система може бути повністю пошкоджена і ви навіть не зможете запустити dpkg щоб відновити хоч щось. Система, що містить лише необхідні пакунки, непридатна для більшості застосувань, але вона здатна самостійно завантажитись та встановити додаткове програмне забезпечення.
важливі (important) - пакунки, що повинні бути у кожній Юнікс-системі. Сюди входять інші пакунки, без котрих система не зможе запуститись та нормально функціонувати. Тут немає Емакса, Х-сервера, ТеХа та інших великих програм. Наявні пакунки лише формують базову інфраструктуру.
типові (standart) пакунки - є стандартом для будь-якої Лінукс-системи, включаючи невелику, але достатньо потужну систему для роботи в текстовому режимі. Вони встановлюються типово, якщо користувач не вибере що-небудь іще. "Типові" пакунки не включають в себе багато великих додатків, але включають Емакс (це швидше є частиною інфраструктури, аніж додатком) та розумну частину ТеХ і ЛаТеХ.
необов'язкові (optional) пакунки включають все те що є сенс встановити у систем навіть якщо ви з цим недостатньо обізнані і якщо у вас немає якихось специфічних вимог. Сюди входять Х-сервер, повна збірка ТеХ та велика кількість додатків.
додаткові (extra) пакунки - конфліктують з іншими з вищим пріоритетом, непотрібні для користувачів, що незнайомі з ними, або ж мають доволі специфічні вимоги для того, щоб включити їх у "необов'язкові".

Будь ласка, зверніть увагу на різницю між "Пріоритет: необхідні", "Секція: основна" та "Важливий: так" (англ. "Priority: required", "Section: base" та "Essential: yes" відповідно) в описі пакунку. "Секція: основна" означає, що пакунок у новій системі буде встановлено в першу чергу. Більшість пакунків з "Секція: основна" мають пріоритет "необхідний", або як мінімум "важливий", і більшість з них мають помітку "Важливий: так". Вона означає, що цей пакет вимагає забезпечення додаткових опцій системи керування пакунками при видаленні з системи. До прикладу, libx, mawk та makedev мають "Піроритет: необхідний", "Секція: основна", але не мають помітки "Важливий: так".

Віртуальні пакунки

Віртуальний пакунок - це загальне ім'я, що підходить до будь-якого з групи пакунків, котрі забезпечують однакову базову функціональність. Наприклад, як tin так і trn є зчитувачами новин, і кожен з них може забезпечити потребу у одержанні новин. Тому кажуть, що вони обидва пропонують віртуальний пакунок "зчитувач новин" (англ. news-reader).

Подібно до них, кілька пакунків, такі як exim, exim4, postfix та sendmail пропонують функціональність поштового транспортного агента. Тому кажуть, що вони формують віртуальний пакунок mail-transport-agent (англ. "поштовий транспортний агент"). Якщо хоча б один з них встановлений, будь-яка програма, що потребує поштового транспортного агента для роботи, буде повідомлена про існування віртуального пакунку.

Дебіен також пропонує механізм, котрий дозволяє задати переважаючий пакунок у випадку встановлення кількох з схожою функціональністю. Цей механізм, та команда update-alternatives описані у параграфі 6.5.3.

Залежності пакунків

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

пакунок А залежить (depends) від пакунку В, якщо В безумовно повинен бути встановленим у системі щоб запустити програму А. В деяких випадках А залежить не просто від В, але від певної версії В. В такому випадку залежність як правило має нижню межу, в цьому випадку А залежить від будь-якої версії В, що новіша за деяку визначену версію.
пакунок А рекомендує (recommends) пакунок В, якщо поширювач пакунку А вважає, що переважній більшості користувачів не потрібен пакунок А без функціональності, що її забезпечує пакунок В.
пакунок А пропонує (suggests) пакунок В, якщо В містить файли що зв'язані (та, зазвичай, посилаються) з функціональністю А.
пакунок А конфліктує з пакунком В, якщо А не зможе функціонувати при встановленому у системі В. Значно рідше конфлікт виникає із-за того, що А містить файли, відмінні від аналогічних у пакунку В. Часто "конфліктує" поєднується з "замінює".
пакунок А замінює (replaces) пакунок В, коли файли, встановлені В видаляються та (в деяких випадках) перезаписуються файлами з А.
пакунок А забезпечує (provides) пакунок В, коли всі файли та функціональність В включені в А. Цей механізм дає можливість користувачам з обмеженим дисковим простором встановити лише ту частину пакунку А, котра їм справді необхідна.

Детальнішу інформацію про вживання кожного з цих термінів можна відшукати в Посібнику по пакуванню та Посібнику політики Дебіен.

Зверніть увагу, що dselect має значно розумніший контроль над пакунками, що позначені як рекомендовані та пропоновані, аніж apt-get, котрий просто витягує всі пакунки, позначені як залежні, та ігнорує рекомендовані та пропоновані пакунки. Сучасні версії обидвох цих програм використовують АРТ у якості основи.

Значення "попередньої залежності"

dpkg завжди встановлює та конфігурує пакунок, від котрого залежить поточний перед тим, як обробити залежний пакунок. Проте розпаковує він їх у довільному порядку, не зважаючи на залежностей (розпакування складається з витягнення файлів з архівів та розташування їх у відповідному місці). Проте, якщо пакунок попередньо залежить від іншого, тоді цей інший пакунок розпаковується і конфігурується перш ніж буде розпакований і сконфігурований попередньо залежний [2]. Використання цієї залежності зведено до мінімуму.

Стан пакунку

Стан пакунку може бути "невідомий", "встановлений", "видалений", "очищений" або "зафіксований". Ці позначки вказують, що користувач хотів зробити з пакунком (роблячи вибір у секції "Вибір" програми dselect чи викликаючи dpkg напряму).

Вони означають наступне:

невідомий - користувач ніколи не вказував, що він хоче з пакунку
встановлений - користувач хотів встановити або оновити пакунок
видалений - користувач хотів видалити пакунок, але не хотів чіпати при цьому існуючі конфігураційні файли
очищений - користувач хотів видалити пакунок разом з усіма конфігураційними файлами
зафіксований - користувач не хотів обробляти пакунок; тобто він хотів зафіксувати поточну версію і поточний статус, якими б воин не були.

Утримання пакунків від оновлення

Є два механізми для фіксації пакунків від оновлення - за допомогою dpkg, або, починаючи з Woody, через АРТ.

У випадку dpkg спершу експортуйте список станів пакунків:

 dpkg --get-selections \* > selections.txt

Далі відредагуйте файл selections.txt, змінивши рядки, що містять потрібні вам пакунки, наприклад libc6, з цього

libc6                       install

ось в таке:

libc6                       hold

Збережіть зміни та завантажте файли назад у базу dpkg:

dpkg --set-selections < selections.txt

Ну або, якщо вам відомо ім'я пакунку, просто виконайте

echo libc6 hold | dpkg --set-selections

Ця процедура зафіксує кожен файл вибраного пакунку.

Того ж ефекту можна досягти за допомогою dselect. Просто перейдіть до екрану вибору ([S]elect), відшукайте пакунок, котрий ви хочете зафіксувати, та натисніть клавішу "=" (або "Н"). Зміни будуть задіяні відразу, як тільки ви покинете екран вибору.

Система АРТ у збірці Woody має новий, альтернативний механізм фіксації пакунків під час процесу видобування архіву за допомогою Pin-priority. Деталі описані на сторінці довідки apt_preferences (5), на сторінці тенет http://www.debian.org/doc/manuals/apt-howto/ та в пакунку apt-howto.

Джерельні пакунки

Джерельні пакунки знаходяться в каталозі під назвою source і ви можете або завантажити їх вручну, або ж за допомогою

apt-get source пакунок

Зверніться до сторінки довідки apt-get (8) щоб дізнатись як налаштувати АРТ для цього.

Формування двійкового пакунку з джерельного

Для пакунку foo вам знадобляться файли foo*.dsc, foo.tar.gz i foo_.gz щоб скомпілювати джерельний код (увага: у рідних для Дебіен пакунків немає файлів .diff.gz).

Після того, як ви отримали джерельний пакунок, якщо у вас встановлено dpkg-dev, команда

$ dpkg-source -x foo_version-revision.dsc

видобуде пакунок у каталог foo_version. Далі виконайте наступні команди:

$ cd foo-version
$ su -c "apt-get update ; apt-get install fakeroot"
$ dpkg-buildpackage -rfakeroot -us -uc

А потім

# su -c "dpkg -i ../foo_version-revision_arch.deb"

щоб встановити новостворений пакунок. Див. також параграф 6.4.10.

Створення нових пакунків Дебіен

Детальна інформація про створення нових пакунків описана у Посібнику нового поширювача, що доступний у пакунку maint-guide, або ж за адресою http://www.debian.org/doc/manuals/maint-guide/.

Оновлення системи Дебіен

Однією з переваг Дебіен є простий, надійний та безпечний процес оновлення. Система керування пакунками попереджує адміністратора про важливі зміни та іноді просить його прийняти якесь рішення. Вам потрібно також прочитати Зауваження до випуску; вони розміщуються на всіх дисках та доступні в тенетах за адресами http://www.debian.org/releases/stable/releasenotes або http://www.debian.org/releases/testing/releasenotes.

Прaктичний позібник по оновленню пропонується у розділі 6; цей параграф всього лише описує основи, починаючи з інструментів для роботи з пакунками.

dpkg

Це головна програма для маніпулювання пакунками; детальний опис подається в dpkg(8). dpkg постачається з кількома простими допоміжними програмами:

dpkg-deb: Маніпулює .deb-файлами. dpkg-deb(1)
dpkg-ftp: Застаріла команда для роботи з пакунками. dpkg-ftp(1)
dpkg-mountable: Застаріла команда для роботи з пакунками. dpkg-mountable (1)
dpkg-split: Ділить великі пакунки на менші файли. dpkg-split (1)

dpkg-ftp i dpkg-mountable були включені у систему АРТ.

APT

APT (англ. Advanced Packaging Tool, Вдосконалена система пакування) - це розширений інтерфейс до сестеми керування пакунками Дебіен, що містить декілька програм, чиї імена типово розпочинаються з "apt-". apt-get, apt-cache i apt-cdrom - це інструменти командного рядка для завантаження пакунків. Вони також працюють як фонові програми до інших інструментів, таких як dselect i aptitude. Для додаткової інформації встановіть пакунок apt і прочитайте apt-get(8), apt-cache(8), apt-cdrom(8), apt.conf(5), sources.list(5), apt_preferences(5) (Woody), та /usr/share/doc/apt/guide.html/index.html.

Альтернативним джерелом інформації є ЯКЦЕ АРТ (http://www.debian.org/doc/manuals/apt-howto/). Воно може бути встановлене пакунком apt-howto в каталог /usr/share/doc/Debian/apt-howto/.

apt-get upgrade і apt-get dist-upgrade обробляють лише залежні пакунки і пропускають рекомендовані та пропоновані. Щоб уникнути цього, використовуйте dselect.

dselect

Ця програма - базований на системі меню користувацький інтерфейс до системи керування пакунками Дебіен. Він дуже зручний для першого встановлення та великих оновлень. Див. параграф 6.2.4.

Для детальнішої інформації встановість пакунок dselect-doc та прочитайте /usr/share/doc/install-doc/dselect-beginner.en.html або ж Документацію по dselect для початківців - http://www.debian.org/releases/woody/i386/dselect-beginner.

Оновлення запущеної системи

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

Завантажені та кешовані архівні файли .deb

Якщо ви завантажили пакунок вручну (що абсолютно не є необхідним, див. вище опис dpkg-ftp або APT), то після встановлення пакунку ви можете видалити файл .deb з вашої системи.

Якщо використовується APT, ці файли кешуються у каталозі /var/cache/apt/archives. Ви можете видалити їх після встановлення (apt-get clean) або ж скопіювати у відповідний каталог на іншій машині щоб зекономити час та трафік при серійних встановленнях.

Реєстрація оновлень

dpkg зберігає список пакунків, що були розпаковані, сконфігуровані, видалені або/чи зафіксовані, але (поки що) не зберігає журнал термінальної активності, що відбувається під час маніпуляцій з пакунками.

Найпростіший спосіб вирішення цієї проблеми - запускати сесії dpkg, dselect, apt-get і т.п. всередині програми script (1).

Процес завантаження Дебіен

Програма init

Як і всі Юнікси, ДЕбіен завантажується, запускаючи програму init. Конфігураційний файл init (/etc/inittab) визначає, що першим має виконатись сценарій /etc/init.d/rcS. Що відбудеться далі залежить від того, котрий з пакунків - sysv-rc чи file-rc - встановлено у системі. Надалі підрозумівається, що встановлено sysv-rc (file-rc має власні сценарії /etc/init.d/rcS та використовує файли замість симлінків в каталогах rc для того, щоб котролювати, які служби на яких рівнях запускати).

Файл /etc/init.d/rcS з пакунку sysv-rc запускає всі сценарії з каталогу /etc/rcS.d/ в порядку, котрий забезпечує ініціалізацію системи - перевірку та монтування файлових систем, завантаження модулів, запуск мережевих служб, налаштування годинника і т.п. Далі для сумісності він також запускає всі файли (за винятком тих, котрі починаються з сиволу ".") з каталогу /etc/rc.bot/. Останній каталог зарезервований для системних адміністраторів і його використання є небажаним. За додатковою інформацією звертайтесь до параграфу 9.1 та відповідного розділу (http://www.debian.org/doc/debian-policy/ch-opersys#s-sysvinit) Підручника політики Дебіен.

Дебіен не використовує BSD-подібний каталог rc.local.

Рівні виконання

Після завершення процесу завантаження, init запускає всі служби, котрі сконфігуровані для запуску на типовому рівні виконання, котрий задається записом id у файлі /etc/inittab. Дебіен поставляється з id=2.

Дебіен послуговується наступними рівнями виконання:

1 - однокористувацький режим
від 2 до 5 - різні багатокористувацькі режими
0 - зупинка системи
6 - перевантаження системи

Рівні виконання з 7 по 9 також можна використовувати, але їхні каталоги rc не обробляються при встановленні пакунків.

Перемикання між рівнями запуску відбувається за допомогою команди telinit.

Під час запуску рівня виконання виконуються всі сценарії з каталогу /etc/rcномер_рівня.d/. Перша літера в назві сценарію визначає спосіб його запуску: сценарії, що починаються з літери K запускаються з параметром "stop", а сценарії, що розпочинаються з літери S - з параметром "start". Сценарії обробляються в алфавітному порядку; ось чому зупиняючі сценарії обробляються перед запускаючими, а дві цифри після літер S або K задають порядок запуску сценаріїв.

Фактично всі сценарії в обговорюваному каталозі є лише символьними відсилачами на сценарії з каталогу /etc/init.d/. Вони можуть також приймати параметри "restart" та "force-reload", що дозволяють перезапускати служби після запуску системи або ж примушувати їх (служби) перечитувати свої конфігураційні файли.

Наприклад:

# /etc/init.d/exim4 force-reload

Настройка рівнів виконання

Настройка рівнів виконання - це задача для досвідчених системних адміністраторів. Нижчеподані поради є справедливими для більшості служб.

Щоб задіяти службу на рівні виконання, створіть символьний відсилач /etc/rcP.d/Sxyслужба на файл ../init.d/служба. Послідовність чисел ху вказує порядковість запуску служби. Щоб відключити службу, перейменуйте символьний відсилач так, щоб його назва починалась з літери К замість S, а порядковий номер був 100-xy.

Для вищеописаних задач прийнято використовувати редактор рівнів виконання, такий як sysv-rc-conf або ksysv.

Дозволяється також видаляти символічний відсилач на службу з певного рівня замість його перейменування. В такому випадку служба не відключається, а залишається у невизначеному, відносно системи ініціалізації sysv-rc, стані: вона і не запускається і не зупиняється на заданому рівні, а залишається такою ж, як на попередньому. Проте зауважте, що служба, залишена напризволяще, буде запущена, якщо її пакунок буде оновлено, не залежно від того, чи запускалась вона до оновлення, чи ні. Це відомий недолік поточної системи Дебіен. Зверніть також увагу, що ви повинні зберегти відсилачі, що розпочинаються на "К" в рівнях 0 та 6. Якщо ви видалите всі відсилачі для певної служби, то при оновленні пакунку вони будуть повернені до їх типового стану. Вносити будь-які зміни у відсилачі в /etc/rcS.d/ є недоцільно.

Підтримка розгалужень

Дебіен пропонує декілька шляхів реалізації будь-яких бажань системного адміністратора без шкоди для системи.

dpkg-divert, див. параграф 6.5.1
equivs, див. параграф 6.5.2
update-alternative, див. параграф 6.5.3
make-kpkg дозволяє співіснувати багатьом первинним завантажувачам. Див. make-kpkg(1) та параграф 7.1.1.

Будь-які файли в каталозі /usr/local/ належать системному адміністратору і Дебіен їх не чіпає. Більшість файлів у /etc/ є конфігураційними і Дебіен не перезаписує їх під час оновлень аж поки системний адміністратор не дасть на це дозвіл.

Інтернаціоналізація

Система Дебіен є міжнародною і забезпечує підтримку вводу і відображення символів на багатьох мовах як в консолі, так і в графічному середовищі. Багато документів, сторінок довідки та системних повідомлень були перекладені на все більшу кількість мов. Під час встановлення Дебіен пропонує користувачеві вибрати мову (та, іноді, локальний варіант мови).

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

Дебіен та ядро

Див. розділ 7 - Дебіен та ядро Лінукс.

Компіляція ядра з не-Дебіенівських джерельних кодів

Ви повинні розуміти політику Дебіен щодо файлів заголовків.

Бібліотеки С в Дебіен формуються з найсвіжіших стабільних випусків ядра.

Наприклад, випуск Дебіен 1.2 використовував версію заголовкових файлів 5.4.13. Така практика відрізняється від пакунків з джерельними кодами ядра Лінукс, що поширюються по архівних сайтах, де використовується найновіша версія заголовкових файлів. Файли заголовків ядра, що пошурюються з джерельними кодами, розміщуються в /usr/include/linux/include/.

Якщо вам потрібно скомпілювати програму з новішими заголовковими файлами ядра, аніж ті, що пропонуються у libc6-dev, ви повиння додати параметр -I/usr/src/linux/include/ до командного рядка компіляції. Таке робиться, наприклад, з пакуванням демона автоматичного монтування (amd). Коли в нових ядрах поміняли роботу з NFS, amd повинен був знати про це, що вимагало включення найновіших заголовкових файлів.

Інструменти для формування власних ядер

Користувачам, котрі хочуть (або повинні) будувати ядра власноруч, вартувало б завантажити пакунок kernel-package. Він містить сценарій для формування пакунку ядра та дає можливість створити пакунок Дебіен з образом ядра ввівши команду

# make-kpkg kernel_image

в каталозі вернхнього рівня джерельних кодів ядра. Довідка доступна після введення команди

# make-kpkg --help

та на сторінці довідки make-dpkg(8), а також у розділі 7 цього довідника.

Користувачі повинні окремо завантажити джерельні коди найсвіжішої (або ж потрібної їм) версії ядра з свого улюбленого сайту з пакунком kernel-source-версія. Завантажувальний сценарій initrd вимагає спеціальної латки під назвою initrd; деталі див. на http://bugs.debian.org/149236.

Детальні інструкції щодо використання пакунку kernel-package подаються у файлі /usr/share/doc/kernel-package/README.gz.

Альтернативні завантажувачі

Щоб задіяти альтернативні завантажуватчі, так як grub чи lilo, скопіюйте скомпільоване ядро Лінукс bzimage в інший каталог (наприклад, в /boot/grub або ж в розділ MS-DOS відповідно).

Власні завантажувальні дискети

У створенні власних завантажувальних дискет вам допоможе пакунок boot-floppies, котрий можна знайти в секції admin на серверах Дебіен для збірок Potato і старіших. Сценарії оболонки з цього пакунку роблять завантажувальні дискети у форматі syslinux. Це дискети, відформатовані під MS-DOS, чий головний завантажувальний розділ був змінений таким чином, що вони напряму вантажать Лінукс (або ж будь-яку іншу операційну систему, що визначена у файлі syslinux.cfg). Інші сценарії з цього пакунку створюють аварійні системні дискети та навіть можуть дублювати базові диски.

Додаткову інформацію ви знайдете у файлі /usr/doc/boot-floppies/README після встановлення пакунку boot-floppies.

Особливі вказівки для роботи з модулями

Пакунок modconf пропонує сценарій (/usr/bin/modconf), котрий можна використовувати для настройки конфігурації модулів. Він має меню-подібний інтерфейс, повідомляючи користувачеві подробиці про завантажувані пристрої у системі. Відповіді користувача використовуються для редагування файлу /etc/modules.conf (котрий містить список псевдонімів та інших аргументів, що мають використовуватись з різними модулями) через файли в /etc/modutils/ та /etc/modules (котрий перелічує модулі, що повинні завантажитись під час запуску системи).

Пакунок modconf подібно до (нових) файлів Configure.help, котрі тепер доступні при конструюванні власних ядер, постачається з набором допоміжних файлів (в /usr/share/modconf/), де подається детальна інформація про аргументи кожного з модулів. Приклади наведено у параграфі 7.2.

Деінсталяція старих пакунків ядра

Сценарій kernel-image-NNN.prerm перевіряє чи запущене в даний момент ядро є тим самим, котре ви намагаєтесь видалити. Тому ви можете спокійно видалити непотрібні образи пакунків ядра за допомогою команди

# dpkg --purge --force-remove-essential kernel-image-NNN

(звісно, NNN слід замінити номером версії та перегляду ядра).