Debian Repository HOWTO
Автор: Aaron Isotton, aaron@isotton.com
Анотація
Цей документ пояснює, що таке сховище Debian і яким чином ви можете його налаштувати.
Вступ
Сховище Debian — це набір пакунків Debian, розміщених в спеціальному дереві тек, яке також містить деякі додаткові файли з індексами та контрольними сумами пакунків. Коли користувач додає сховище до свого файлу /etc/apt/sources.list, він отримує можливість дуже просто переглядати та встановлювати всі доступні в сховищі пакунки, точно так само як він це робить з пакунками, котрі входять до Debian.
Сховище може бути як онлайновим, так і офлайновим, автономним (наприклад, компакт-диск), хоча перший випадок є більш прийнятним і вживаним.
В цьому документі пояснюються принципи роботи сховища Debian, розповідається про те, як його створювати та правильно додавати до sources.list.
Найновіші версії цього документу можна знайти за адресою http://www.isotton.com/debian/docs/repository-howto/.
Авторські права та ліцензія
Власником авторських прав на цей документ, Debian Repository HOWTO, є Aaron Isotton, (c) 2002-2003. Дозволяється копіювати, розповсюджувати та/або змінювати цей документ на засадах GNU Free Documentation License, версії 1.1 або будь-якої наступної версії, опублікованої Фондом вільного програмного забезпечення (Free Software Foundation); без тексту передньої обкладинки і без тексту задньої обкладинки.
Зворотній зв'язок
Зворотній зв'язок до цього документу є дуже бажаним. Надсилайте ваші вдосконалення, коментарі та критику за адресою aaron@isotton.com.
Терміни, які використовуються в даному документі
збірки : Три збірки Debian: стабільна (stable), тестова (testing) та нестабільна (unstable).
індексні файли : Файли Packages.gz та Sources.gz.
Як працюють сховища
Сховище складається з як мінімум однієї теки, що містить деякі DEB-пакунки та два спеціальні файли: Packages.gz для двійкових та Sources.gz джерельних пакунків.
Якщо ваше сховище правильно додане до sources.list (детальніше про це нижче), команда apt-get завантажить індекси Packages.gz (для двійкових пакунків; коли вказане ключове слово deb) та Sources.gz (для джерельних пакунків; коли вказане ключове слово deb-src).
Файл Packages.gz містить назву, версію, розмір, короткий і довгий описи, та залежності кожного з пакунків плюс деяку нецікаву для нас додаткову інформацію. Вся вона показується (та використовується) програмами керування пакунками Debian, такими як dselect чи aptitude.
Файл Sources.gz містить назву, версію та залежності необхідні для побудови кожного з пакунків (плюс деяка нецікава для нас інформація також); ця інформація використовується apt-get source та подібними інструментами.
В необов'язковому файлі Release міститься деяка інформація про ваше сховище; вона використовується для „приколювання“ (Pinning), цікавого прийому, на якому я не хочу зупинятися в цьому документі. Ви можете прочитати більше про „приколювання“ в APT HOWTO.
Отже, як тільки ви налаштували ваше сховище, ви можете переглядати та встановлювати всі ваші пакунки нарівні з іншими пакунками Debian; якщо ви оновлюєте пакунок, він оновиться коли користувач виконає apt-get update && apt-get upgrade; і кожен користувач буде в змозі легко переглянути короткий опис та іншу важливу інформацію про ваші пакунки.
І більш того. При правильному налаштуванні сховища можуть пропонувати різні пакунки для різних збірок та архітектур; apt автоматично завантажуватиме саме те, що підходить для машини користувача, якому навіть не потрібно нічого знати про різні архітектури. Також ви можете групувати ваші пакунки, подібно до того, як пакунки Debian поділені між розділами main, non-free або contrib. Отже ви полюбите сховища пакунків, особливо якщо ваше програмне забезпечення є міжплатформенним.
Як налаштувати сховище
Існують сховища двох типів: більш складні, для використання яких користувачу доведеться вказати лише базовий шлях до сховища та бажані збірку і розділ (apt автоматично завантажить пакунки для необхідної архітектури, якщо вони є доступними); і простіші, для використання яких користувачу доведеться вказати точний шлях (і apt не чаклуватиме, щоб з'ясувати, які будуть придатними). Перші є дещо складнішими в налаштуванні, але простіші у використанні і повинні завжди використовуватись для складних та/або міжплатформенних сховищ; сховища другого типу налаштовувати простіше, але їх використання обмежується малими або одноархітектурними сховищами.
Хоча це і не зовсім коректно, але я називатиму сховища першого типу автоматичними сховищами (Automatic Repositories), а другого — тривіальними сховищами (Trivial Repositories).
Автоматичні сховища
Структура тек автоматичного сховища зі стандартними для Debian архітектурами та розділами виглядає приблизно так:
Приклад 1. Типове сховище Debian
(початок вашого сховища)
|
+-dists
|
|-stable
| |-main
| | |-binary-alpha
| | |-binary-arm
| | |-binary-...
| | +-source
| |-contrib
| | |-binary-alpha
| | |-binary-arm
| | |-binary-...
| | +-source
| +-non-free
| |-binary-alpha
| |-binary-arm
| |-binary-...
| +-source
|
|-testing
| |-main
| | |-binary-alpha
| | |-binary-arm
| | |-binary-...
| | +-source
| |-contrib
| | |-binary-alpha
| | |-binary-arm
| | |-binary-...
| | +-source
| +-non-free
| |-binary-alpha
| |-binary-arm
| |-binary-...
| +-source
|
+-unstable
|-main
| |-binary-alpha
| |-binary-arm
| |-binary-...
| +-source
|-contrib
| |-binary-alpha
| |-binary-arm
| |-binary-...
| +-source
+-non-free
|-binary-alpha
|-binary-arm
|-binary-...
+-source
Вільні пакунки йдуть в розділ main; невільні — в non-free, а вільні, які залежать від невільних — в contrib. На сьогоднішній день Debian підтримує 11 архітектур; я опустив більшість з них задля стислості.
В кожній теці binary-* знаходиться файл Packages.gz та необов'язковий файл Release; кожна тека source містить Sources.gz та необов'язковий файл Release. Зверніть увагу, що пакунки не повинні знаходитись у тій же теці, що й індексні файли, оскільки в індексних файлах вказуються шляхи для кожного пакунка окремо; фактично, вони можуть знаходитись в сховищі будь-де. Це дозволяє створювати пули(pools).
Ви вільні створювати багато збірок і розділів та називати їх, як вам довподоби; назви тих, що я використовував в прикладі співпадають з тими, що використовуються в Debian. Ви можете, наприклад, створити збірки current і beta (замість stable, testing і unstable), та розділи foo, bar, baz і qux (замість main, contrib та non-free).
Хоча ви вільні називати розділи як вам заманеться, загалом гарної ідеєю є використання стандартних назв Debian, звичних для користувачів Debian.
Тривіальні сховища
Тривіальні сховища складаються з однієї кореневої теки та стількох підтек, скільки ви хочете. Оскільки користувачам доведеться вказувати шлях до початку сховища та відносний шлях між початком та текою з індексними файлами, ви вільні робити все, що вам заманеться (навіть поміщати все до кореневої теки сховища; тоді відносним шляхом буде просто “/”).
Приклад 2. Тривіальне сховище з двома підтеками
(початок вашого сховища)
|
|-binary
+-source
Створення індексних файлів
Команда dpkg-scanpackages генерує файл Packages, а dpkg-scansources — відповідно, файл Sources.
Обидві вони виводять результат на stdout; отже, щоб згенерувати стиснені файли, ви можете використати ланцюжок команд, подібний до такого: dpkg-scanpackages параметри | gzip -9c > Packages.gz
.
Ці утиліти працюють схожим чином; вони обидві приймають два параметра (насправді їх може бути більше, але я не хочу в це детально занурюватись; ви можете почитати man-сторінки, якщо хочете дізнатись більше); перший параметр — це тека в якій знаходяться пакунки, а другий — файл override. Для простих сховищ файли override нам не потрібні, але, оскільки цей параметр є обов'язковим, ми просто вказуємо /dev/null.
dpkg-scanpackages сканує .deb-пакунки; dpkg-scansources сканує .dsc-файли. Тому, потрібно поміщати файли .orig.gz, .diff.gz та .dsc разом. Файли .changes не потрібні.
Тому, якщо у вас тривіальне сховище, схоже на те, що ми розглядали вище (Приклад 2, “Тривіальне сховище з двома підтеками”), ви можете створити два індексні файли наступним чином:
$ cd my-repository
$ dpkg-scanpackages binary /dev/null | gzip -9c > binary/Packages.gz
$ dpkg-scansources source /dev/null | gzip -9c > source/Sources.gz
Якщо у вас складне сховище (Приклад 1, “Типове сховище Debian”), то вам потрібно буде написати деякі сценарії, щоб автоматизувати цей процес.
Ви могли б також використати параметр pathprefix обох утиліт, щоб дещо спростити їх синтаксис; залишмо це, як вправу для читача (це задокументовано в man-сторінках).
Створення файлів Release
Якщо ви хочете надати користувачам вашого сховища можливість використовувати „приколювання“ (Pinning) пакунків, вам потрібно включити файл Release до кожної теки з індексними файлами. (Ви можете дізнатись більше про приколювання пакунків, прочитавши APT HOWTO).
Файли Release є простими і короткими файлами наступної форми:
Archive: збірка
Component: розділ
Origin: ВашаКомпанія
Label: сховище Debian ВашоїКомпанії
Architecture: архітектура
Archive : Назва збірки Debian, до якої належать (або плануються) пакунки з цієї теки, наприклад, stable, testing або unstable.
Component : Розділ, до якого належать пакунки з цієї теки, наприклад, main, non-free, or contrib.
Origin : Ім'я того, хто створив ці пакунки.
Label : Якась мітка, що містить адекватну інформацію про пакунки або ваше сховище. Пофантазуйте.
Architecture : Архітектура пакунків з цієї теки, як, наприклад, i386, sparc чи source.
Важливо правильно задати значення полів Archive та Architecture, оскільки саме вони використовуються для приколювання пакунків. Інші поля менш важливі.
Створення пулів
У випадку автоматичних сховищ, розподіл пакунків по різноманітних теках дуже швидко перетвориться на некероване жахіття. Це також марнотратство дискового простору та пропускної здатності, оскільки багато пакунків є однаковими для різних архітектур (наприклад, документація).
В таких випадках можливим вирішенням проблеми є пул (pool). Пул — це додаткова підтека кореневої теки сховища, в якій знаходяться всі пакунки (двійкові для усіх архітектур, збірок та розділів, а також всі джерельні). Витончено комбінуючи дії файлів override (які не розглядаються в даному документі) та сценаріїв, ви можете уникнути багатьох проблем. Чудовим прикладом сховища з використанням пулу є власне сховище Debian.
Пули можуть стати в нагоді лише для великих сховищ; я ніколи не займався їх створенням і не думаю, що така потреба виникне в найближчому майбутньому, ось чому я не пояснюю тут яким чином вони створюються. Якщо ви вважаєте, що такий розділ необхідно додати, не соромтесь, напишіть його та зв'яжіться зі мною.
Інструменти
Різні інструменти можуть автоматизувати та полегшити створення архівів Debian; я склав список найвідоміших з них.
apt-ftparchive використовується для переміщення набору пакунків до сховища належної структури, яку мають офіційні сховища Debian. Ця команда є частиною пакунку apt-utils.
apt-move використовується для переміщення набору пакунків до сховища належної структури, яку маються офіційні сховища Debian.
Використання сховищ
Використовувати сховища дуже просто, але це залежить від того, сховище якого типу ви створили: двійкове чи джерельне, автоматичне чи тривіальне.
Кожне сховище займає один рядок в файлі sources.list; для двійкових сховищ використовуйте команду deb, а для джерельних — команду deb-src.
Кожен рядок повинен виглядати так:
deb|deb-src uri збірка [розділ1] [розділ2] [...]
uri — це URI (уніфікований ідентифікатор ресурсу) кореня сховища, наприклад, ftp://ftp.yoursite.com/debian, http://yoursite.com/debian, або, для локальних файлів, file::///home/joe/my-debian-repository. Завершальна коса риска є необов'язковою.
Для автоматичних сховищ ви повинні вказати одну збірку та один або більше розділів; назву збірки не можна завершувати косою рискою.
Приклад 3. Два автоматичні сховища з мого sources.list
deb ftp://sunsite.cnlab-switch.ch/mirror/debian/ unstable main contrib non-free
deb-src ftp://sunsite.cnlab-switch.ch/mirror/debian/ unstable main contrib non-free
Ці два рядка вказують на автоматичні сховища, двійкове та джерельне, корінь ftp://sunsite.cnlab-switch.ch/mirror/debian/, збірка unstable та розділи main, contrib і non-free.
Якщо сховище не автоматичне, то distribution вказує відносний шлях до індексних файлів і повинно завершуватись косою рискою, жодних розділів вказувати не потрібно.
Приклад 4. Два тривіальні сховища з мого sources.list
deb file:///home/aisotton/rep-exact binary/
deb-src file:///home/aisotton/rep-exact source/
Перший з цих двох рядків вказує на двійкове сховище в теці /home/aisotton/rep-exact/binary на моїй локальній машині; другий вказує на джерельне сховище в теці /home/aisotton/rep-exact/source.
Дивись також
- Документацію apt-ftparchive
- Документацію apt-get та apt.
- Документацію apt-move.
- http://www.apt-get.org/, щоб знайти більше прикладів реальних світових сховищ.
- APT HOWTO.
- Документацію dpkg-scanpackages.
- Документацію dpkg-scansources.
- Man-сторінку sources.list(5)