Примітки

1

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

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

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

2

dists/stable/main, dists/stable/contrib, dists/stable/non-free, і dists/unstable/main/, та інші

3

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

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

4

Зверніть увагу, що є порти, котрі роблять неможливою роботу цього інструменту спільно з іншими системами керування пакунками на подобі керівника пакунками Red Hat, відомого також як rpm.

5

Що призведе до встановлення значно більшої кількості пакунків, аніж необхідно для роботи.

6

Щоб запобігти цьому, використовуйте адресу debian-list-subject-REQUEST@lists.debian.org.