Apt-cacher как корпоративный сервер обновлений для Ubuntu/Kubuntu/*buntu

Замена apt-mirror`у

apt-cacher — утилита для Debian-подобных дистрибутивов использующих apt в качестве установщика пакетов. Она кеширует файлы, которые скачивает пользователь с офф. зеркала обновлений и при следующем запросе выдает их из своего кэша.

В чем плюсы apt-cacher`a перед apt-mirror`ом?

Во-первых, в экономии трафика. Зачем качать один и тот же пакет несколько раз, если его уже скачал ваш коллега? Таким образом экономия трафика растет пропорционально количеству народу в конторе использующих *buntu.
Во-вторых, в экономии места на ЖД сервера, на котором установлен apt-cacher. Ведь зачем хранить 22 Гб пакетов на ЖД, если из них используются максимум 10Гб?
В-третьих, в скорости получения обновлений. Сколько раз вы обновляете свое зеркало обновлений? 1 раз в день? Apt-cacher позволяет получать обновления по мере их появления на офф. зеркале. Когда пользователь делает запрос на обновление(apt-get update) apt-caсher лезет на офф. зеркало проверить, нет ли обновлений того что у него лежит в кеше.
Безусловно у apt-cacher есть и минусы.
Первый минус — apt-cacher распределяет закешированные файлы по своей структуре, отличной от структуры debian-репозиториев. Но эту проблему можно решить, если вам важно сохранить структуры репозитория, это описано ниже.
Второй минус — необходимо наличие Веб-сервера Apache. Тут, к сожалению так просто проблему не решить, но я не думаю, что это существенная проблема :)

Установка и настройка apt-cacher`a

Сама установка довольно банальна для debian-пакетов
sudo apt-get install apt-cacher

Создадим папку для хранения кэша(т.е. самих пакетов) и назначим ей права
sudo mkdir /var/cache/apt-cacher
sudo chown www-data:www-data /var/cache/apt-cacher/*

Вы можете создать папку в любом месте
под юзером и группой www-data будет запускаться наш apt-cacher, так же под ним надо будет запускать Apache.

С настройкой немного сложнее, разбирать настройку самого apt-cacher`a, будем на примере.
Откроем для редактирования файл /etc/apt-cacher/apt-cacher.conf:
sudo nano /etc/apt-cacher/apt-cacher.conf

Рассмотрим пример конф. файла:
cache_dir=/var/cache/apt-cacher #директория которую мы создали и в котрой будет храниться кэш.
admin_email=root@localhost # мыло админа :)
daemon_port=9999 #порт на котором будет висеть наш apt-cacher
group=www-data #группа под которой будет запускаться наш apt-cacher
user=www-data #юзер под которой будет запускаться наш apt-cacher

allowed_hosts=* #хосты доступ с которых разрешен на наш сервер(по-умолчанию разрешено всем)
denied_hosts= #соответственно запрещен.

generate_reports=1 # раз в сутки будут генерироваться отчеты об использовании apt-cacher`a(1-генерить, 0 - нет)

clean_cache=1 #Очистка кэша раз в сутки,
offline_mode=0 #Если 0, то с apt-cacher будет тянуть обновления с офф. сервера, если 1, то раздавать только то что у него в кэше
logdir=/var/log/apt-cacher #папка в которой будут храниться логи доступа к apt-cacher`у
expire_hours=0 # apt-cacher может работать в двух режимах. В первом режиме сервер будет сравнивать expire_hours со временем последнего обновления пакета, и если оно становится меньше, то искать на офф. зеркале обновление для этого пакета, Во-втором режиме сервер будет сравнивать напрямую с офф.сервером, но в этом случае бОльшая вероятность рассинхронизации данных кэша и индексных файлов. Я всегда использую второй вариант, т.к. Для меня важнее получить вовремя обновление. 0 — Второй режим, все что больше 0 — то часы первого режима.
http_proxy= #адрес вашего прокси-сервера(если он у вас есть)
use_proxy=1 #Использовать(1) или нет(0) прокси.
http_proxy_auth= #Авторизация на прокси(формат: user:password)
use_proxy_auth= # Использовать ли авторизацию? (1-да, 0-нет)
limit=0 #Ограничитель скорости. 0 — нет ограничений. 250K — 250кбит/с, 2m — 2мбит/с
debug=0 #Уровень отладки. 0 — маленький лог файл, 1 — большой.
path_map = ubuntu archive.ubuntu.com/ubuntu ; canonical archive.canonical.com/ubuntu ; medibuntu packages.medibuntu.org/ ; #Самый интересный параметр. Настройка зеркал обновления, т.е. Откуда будут тянуться обновления.

Думаю с настройкой самого apt-cacher`a все(ну или почти все) ясно.
Теперь приступим к настройке Apache. Процесс настройки самого Apache я описывать не буду, в Сети много хороших руководств. Для работы всего этого должен быть установлен Perl и включен ExecCGI. Пример моего конфига(файл: /etc/apt-cacher/apache.conf
Alias /apt-cacher /usr/share/apt-cacher/apt-cacher.pl


Options ExecCGI
AddHandler cgi-script .pl
AllowOverride None
order allow,deny
allow from all



Вот. Настройка конф. файлов закончена. Теперь, думаю, самое время приступить к настройке рабочих станций, но для начала опишу как все-таки конвертнуть то, что было в кэше apt-mirror`а в apt-cacher.

Apt-mirror > apt-cacher

У apt-cacher`a есть perl скрипт для конвертации пакетов в формат apt-cacher`a, имя ему apt-cacher-import.pl, и лежит он в /usr/share/apt-cacher. Пользоваться им следующим образом:
/usr/share/apt-cacher/apt-cacher-import.pl -r -c /etc/apt-cacher/apt-cacher.conf /var/my_repos

-r — рекурсивный обход каталога
-c — не обязательный параметр, в котором указывается путь к конф. файлу.
/var/my_repos — директория к репозиторию формата apt-mirror(обычный дебиановский формат репозитория).

В результате этой команды, в папку /var/cache/apt-cacher будут скопированы и переведены в нужный формат все пакеты, которые будут найдены в /var/my_repos
Если вам необходимо оставить дебиановский репозиторий, при этом чтобы репозиторий apt-cacher`a не занимал дополнительного места, к команде добавьте -s, тогда скрипт просто сделает сим-линки на пакеты. НО! Если вы после этого удалите дебиановский репозиторий, то пакеты для apt-cacher`a так же будут не доступны(это же обычные сим-линки)
Если же вы использовали apt-proxy, то у apt-cacher`a тоже имеется скрипт для перевода его репозитория в свой. Скрипт лежит: /usr/share/apt-cacher/apt-cacher/apt-proxy-to-apt-cacher.pl.

Запуск демона и настройка клиентских машин.

Запустить сервер как обычно просто:
sudo /etc/init.d/apt-cacher start

Если вы не допустили синтаксических и иных ошибок в конфигурациях apache и apt-cacher`a, то сервер радостно запуститься, о чем сообщит вам не менее радостным сообщением [OK], если же произошла ошибка, то сервер сделает грустную гримасу и сообщит [FAIL]. Тогда вам придется все перечитать заново и возможно немного по`google`ить.
Чтобы проверить запуск можно зайти на localserver:9999 (где localserver — сервер на котором запущен apt-cacher).

Настройка клиентов

Собственно нужно всего лишь добавить 1 строку(и закоментировать остальные) в файл /etc/apt/sources.list:
deb localserver:9999/ubuntu intrepid multiverse restricted main universe

Тут все как и в обыном репозитории, указываете что вам нужно обновлять, какой дистрибутив и т.п. Localserver — это сервер на котором запущен apt-cacher.

Если вы включили статистику, то её можно посмотреть localserver:9999/reports

Ну вот вроде бы и все :)

T&T: apt-get смотрит в кэш.

Возникла у меня необходимость переставить дома систему, да только вот получилось так, что в итоге я лишился всех обновлений безопасности и обновлений используемых программ.

Понятно, что после установки свежей Ubunt’ы мне было незатейливо предложено скачать обновлений весом около трехсот мегабайт. На этом самом месте я мрачно поглядел на свой мобильный телефон, через который я обычно и выхожу дома в интернет. Скачать столько из дома по GPRS - нереально, а тащить домашний компьютер на работу, чтобы зацепить к локальному кэширующему репозиторию и обновиться - долго.

Не беда подумал я, ведь у меня на рабочей машине всегда свежие обновления лежат, завтра на работе залезу в /var/cache/apt/archives закину оттуда на флэшку все пакеты и притащу домой.

Так и сделал. Залил deb-пакеты на флэшку, пришел домой и слил в локальный архив.

Даю команду apt-get upgrade , а apt ломится в интернет, не хочет видеть пакеты в кэше.

Ну, думаю, тоже гляну в интернет, может чего нарою.

В результате я обогатился знаниями по созданию локального зеркала, по созданию CD/DVD со своими любимыми пакетами (вроде мини-репозитория) и много всего интересного.

Все это замечательно, знания облагораживают, но если бы мне нужен был такой длинный путь я бы уже развернул свой локальный кэширующий репозиторий, но это не тот быстрый и нужный мне выход из положения.

Линукс на то и Линукс, что в нем одну задачу можно решить многими путями.

Пришлось читать man по apt-get, что конечно же надо было сделать в первую очередь.
В результате я дал одну лишь команду:

apt-get –no-download –ignore-missing upgrade

И был счастлив. apt-get полез в кэш и поставил все нужные пакеты, а которые не нашел в кэше - те не поставил.

источник

Как сделать зеркало репозитария Ubuntu

Подготовим директорий, куда будем складывать файлы:

Код:

$ mkdir ubuntu

Установим пакет для скачивания файлов и создания локального зеркала Ubuntu:

Код:

$ sudo apt-get install debmirror

Создадим скрипт mirror.sh для запуска стого пакета и скачивания дистрибутивов и наборов пакетов, в которых нуждаемся:

Код:

#!/bin/bash -x

/usr/bin/debmirror –nosource -m –passive –host=ru.archive.ubuntu.com \
 –root=ubuntu –method=http –progress \
 –dist=hardy,hardy-security,hardy-updates,hardy-backports \
 –ignore-release-gpg –section=main,restricted,multiverse,universe \
 –arch=i386,amd64 ubuntu8_04/

Пояснения к опциям для любопытных:
–nosource - игнорировать исходники, только bin
-m - проверить контрольные суммы md5
–passive - закачка в пассивном режиме (этого требуют некоторые прокси)
–host=ru.archive.ubuntu.com - откуда качаем
–root=ubuntu - каталог на сервере, будем качать все, что в него вложено
–method=ftp - метод закачки, варианты: ftp|hftp|http|rsync (если Вы качаете через M$ ISA, то, боюсь, что Вам подойдет только http.
rsync подойдет для последующих обновлений репозитория, только тогда опцию root надо будет записать так: –root=:ubuntu
–dist=hardy,hardy-security,hardy-updates,hardy-backports - наборы пакетов по их назначению (как они лежат на сервере в каталоге ubuntu)
–ignore-release-gpg - не обращать внимания на gpg-ключи (если мы доверяем серверу)
–section=main,restricted,multiverse,universe - секции наборов пакетов
–arch=i386,amd64 - архитектура нашего компа (можно ограничиться чем-то одним)
ubuntu_8.04/ - каталог, куда мы все это сложим (мне почему-то пришлось прописать полный путь!)
ПРИМЕЧАНИЕ. для работы через прокси (подобного Squid) может понадобиться опция:
–proxy=http://user:pass@url:port/
Делаем этот скрипт исполнимым:

Код:

$ chmod +x mirror.sh

Запускаем его:

Код:

$ sudo ./mirror

И спокойно идем ложиться спать… В зимнюю спячку.
На третьи сутки у меня скрипт отработал.
Все это время он грузил мой анлим на 120%
(без шуток - проверено iptraf!) и после себя оставил 23 гига в каталоге ~/ubuntu
в котором будут каталоги .temp dists pool и project
Первый и последний - это каталоги, служебные для debmirror, а в dists и pool будут размещены индексы пакетов и сами пакеты - соответственно.
(для любопытных сообщу по секрету, что .temp - это временный dists, а project - хранит файл с именем моего компа и временем последней закачки).

источник

PR: wait... I: wait... L: wait... LD: wait... I: wait... wait... CY: wait... I: wait... L: wait... YCat: wait... I: wait... Top: wait... C: wait... SD: wait...

Устройство репозитория Ubuntu

Алексей Федорчук, Владимир Попов
При участии творческого гения посетителей форума POSIX.ru

16 января 2007 г

Я обыгрывать люблю всех подряд.
Королевой королю шах и мат.
И живу я хорошо - лучше всех.
Не случайно он пришел, мой успех.
Владимир Асмолов

Дистрибутив Debian GNU/Linux (именно таково его официальное название) давно и по праву славится своей системой управления пакетами. Успех которой слагается из трех компонентов:

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

Потомки Debian, такие, как MEPIS, Xandros, Linspire, вместе с форматом пакетов унаследовали от прародителя и все остальные составляющие удачливого пакетного менеджмента. B, конечно же, все они характерны и для самого популярного деривата Debian - семейства дистрибутивов Ubuntu, каковое и будет предметом дальнейшего рассмотрения.

В настоящей заметке будет рассмотрено устройство репозиториев Ubuntu. Рассмотрение это преследует две цели. Первой является чисто удовлетворение собственного любопытства - дабы поглядеть, как оно устроено "внутре". Но есть и цель практическая: каким образом можно получать информацию о пакетах с машины, не имеющей подключения к Сети - согласитесь, в нашей умеренно интернетизированной СНГовии задача достаточно актуальная.

Сразу следует оговориться, что без физического доступа к Сети вообще использование средств пакетного менеджмента Debian может носить предельно ограниченный характер, распространяясь только на реопзитории с "твердых" носителей, типа дистрибутивных компактов. Нет, речь идет все-таки о случае, когда какой-никакой доступ к Сети все-таки имеется, только не с той машины и, возможно, не с той платформы, на которой Ubuntu используется (например, со служебной машины под управлением Windows).

Сначала - пара слов о репозиториях Ubuntu вообще. Официальные репозитории Ubuntu - общие для всех дистрибутивов семейства, и располагаются они по адресу: http://archive.ubuntu.com/ubuntu/. Это - "головное" хранилище пакетов, имеющее многочисленные региональные зеркала, принадлежность которых к стране указывается стандартным двухсимвольным префиксом, например:

• http://no.archive.ubuntu.com/ubuntu/ - норвежское зеркало,
• http://ru.archive.ubuntu.com/ubuntu/ - российское зеркало,

и так далее. Кроме официального репозитория, имеются также репозитории, так сказать, полуофициальные. Для пользователей Kubuntu, например, важнейшим из них будет http://kubuntu.org/packages/. Последние версии KDE, KOffice, Amarok в нем появляются существенно раньше, чем в официальном репозитории. Кроме того, только в нем можно найти тестовые версии указанных пакетов. В частности, в настоящее время это единственный репозиторий, из которого можно получить в бинарном виде тестовую версию KDE 4.

Чтобы получить представление о внутреннем устройстве репозитория Ubuntu, посетим одно из его зекрал, например, http://ru.archive.ubuntu.com/ubuntu/. Внутре него видим файл ls-lR.gz (представляющих собой полный список всего файлового дерева репозитория, с атрибутами принадлежности, доступа, и так далее), а также следующие каталоги:

dists/
indices/
pool/
project/

Назначение каталога project/ показалось мне не вполне понятным, каталог indices/ содержит нечто вроде списков файлов, в каталоге dists/ описываются всякого рода сведения о пакетах, а сами они имеют место быть в каталоге pool/. Собственно, два последних каталога нас и будут интересовать.

Начнем с описания пакетов, то есть содержимого каталога dists/. Надо сказать, что классификация пакетов в Ubuntu выглядит еще более запутанной, чем в Debian'е, где она тоже не являет собой эталон прозрачности.

В первом приближении пакеты классифицируются по именам релизов - на текущий момент актуальны релизы Dapper (6.06, точнее, ее bugfix-редакция 6.06.1), которому обещана пятилетняя поддержка, Edgy (6.10) - последний по времени стабильный релиз, и Feisty (будущий 7.04) - то, что станет релизом весной 2007 года (если полугодовой цикл разработки не будет нарушен). Но описания всех предыдущих релизов Ubuntu также имеются в каталоге dists/, образуя самостоятельные подкаталоги. В качестве исторической справки напомню, что это были Breezy (5.10) и Hoary (5.04). Лишь следов самой первой версии, Warty (4.10) не удается найти в репозитории.

Далее, в каждом релизе, помимо основного массива пакетов, выделяются еще и так называемые категории - каждой из них соответствует подкаталог того же уровня, что и подкаталог релиза, а именуются они так (на примере релиза edgy):

edgy-backports/
edgy-proposed/
edgy-security/
edgy-updates/

Категория backport включает пакеты, не входящие в основной комплект дистрибутива, не столь оттестированные, как последние, но которые могут содержать всякие новые версии с полезными фичами.

Категория security, как можно догадаться из названия, содержит обновления, направленные на повышение безопасности.

Категория proposed содержит тестируемые обновления пакетов, которые со временем, надо полагать, переходят в категорию updates. Впрочем, я могу и ошибаться - однако для целей нашего рассмотрения все категории, за исключением backports, не очень существенны.

Внутри каждого релизного и категорийного подкаталога, в свою очередь,имеются наборы подкаталогов, соответствующих группам пакетов - т.н. компонентам дистрибутива:

main/
restricted/
universe/
multiverse/

А уже внутри них - каталоги для описания бинарных пакетов, собранных под каждую из поддерживаемых архитектур:

binary-amd64/
binary-i386/
binary-powerpc/
binary-sparc/

каталог писания пакетов исходников

source/

каталог с переводами описаний

i18n

Каждый каталог содержит три файла: Release - файл с общей информацией о ветке репозитория, Packages.gz и Packages.bz2, которые на самом деле представляют собой один и тот же файл Packages, сжатый утилитами gzip и bzip2, соответственно. Файл Release, как явствует из его названия, представляет собой общее описание компонента данного релиза, и выглядит примерно так:

Archive: edgy
Version: 6.10
Component: main
Origin: Ubuntu
Label: Ubuntu
Architecture: amd64

Содержание же файл Packages - полный список пакетов данного компонента и архитектуры. Для каждого пакета из этого списка приводятся:

• Package: название пакета (например, adduser);
• Priority: приоритет (required, important, optional и так далее);
• Section: принадлежность к целевой группе (base, admin, gnome, kde и т.д.);
• Installed-Size: объем, занимаемый пакетом и его составляющими в установленном виде (Кбайт);
• Maintainer: сборщик дистрибутивного пакета (например, Ubuntu Core Developers) и его e-mail;
• Original-Maintainer: разработчик авторского пакета и его e-mail;
• Architecture: целевая платформа (например, i386, amd64 или ppc);
• Version: номер версии оригинального пакета и сборки пакета дистрибутивного (примерно так - 2.4.6-1.1ubuntu1);
• Replaces: пакеты, заменяемые данным (если таковые имелись ранее);
• Depends: жесткие, то есть обязательные, зависимости, с указанием минимальной версии, например: debianutils (>= 1.6);
R
• ecommends: рекомендуемые, то есть мягкие, зависимости;
• Suggests: предлагаемые (еще более "мягкие") зависимости;
• Conflicts: пакеты, конфликтующие с данным;
• Filename: полный путь к deb-файлу пакета, отсчитываемый от каталога pool (см. далее);
• Size: размер файла deb-пакета (в байтах);
• MD5sum: контрольная md5-сумма;
• SHA1: идентификатор подлинности;
• SHA256: он же, 256-битный;
• Description: краткое описание пакета;
• Bugs: адрес для высылки сообщений об ошибках в программе;
• Origin: происхождение (Ubuntu);
• Task: категория, в составе которой пакет устанавливается (например, minimal, standard, ubuntu-desktop, kubuntu-desktop, и так далее).

То есть здесь мы видим нечто вроде аккумулятивной суммы файлов control для всех пакетов репозитория, с единственным добавлением строки Filename, описывающей путь к данному пакету именно в данном репозитории.

Картина получается достаточно запутанная. Но в ней важны два момента. Первый - не смотря на иерархический вид подкаталогов внутри dists/, классификация эта на самом деле не иерархическая, а проведена по трем независимым признакам - категории, компоненту и архитектуре. И второй момент - это в сущности классификация не пакетов, а только их описаний, то есть метаинформации о пакетах. И пользователю с ней общаться практически не приходится - она используется утилитами семейства apt или программой aptitude для извлечения (установки, вывода информации и так далее) о требуемых в данной ситуации пакетах - нужного компонента и нужной архитектуры.

Классификация же собственно пакетов, с которой только и сталкивается пользователь (да и то не совсем вплотную), гораздо проще, в чем можно убедиться при рассмотрении подкаталога pool/ (то есть "пула" пакетов). Здесь мы видим всего четыре подкаталога, соответствующие указанным выше компонетам дистрибутива:

main/
restricted/
universe/
multiverse/

Компоненты группируются следующим образом:

• main - полностью свободные пакеты, официально поддерживаемые разработчиками Ubuntu;
• restricted - пакеты, также официально поддерживаемые дистрибутивом, но не вполне свободные;
• universe - полностью свободные программы, официально дистрибутивом не поддерживаемые и развивающиеся силами независимых разработчиков;
• multiverse - пакеты, аналогично universe официально не поддерживаемые и не вполне свободно распространяемые.

Понимание свободно распространяемых программ с точки зрения лицензии Ubuntu примерно соответствует принципам свободного программного обеспечения Debian, которое, в свою очередь, весьма сходно с пониманием свободного софта FSF. Пакеты из компонентов restricted и multiverse имеют разного рода ограничения на распространение в некоторых странах или могут содержать закрытые части. Примерами являются фирменные драйверы для видеокарт Nvidia (restricted) или мультимедиа-кодеки, использующие патентованные в отдельных странах алгоритмы.

Каждый из компонентных каталогов разбит на "алфавитные" подкаталоги - от a до z. Исключение - библиотечные пакеты, сгруппированные в подкаталоги вида liba - libz. Внутри "алфавитных" подкаталогов имеются подкаталоги пакетные, а в них уже лежат отдельные deb-пакеты, представляющие собой конкретные сборки под определенные архитектуры.

Итак, состав предлагаемых репозиторием определённому дистрибутиву пакетов можно получить из файла url/dists/release_name/component/type/Packages, где url - url репозитория (в нашем случае - http://ru.archive.ubuntu.com/ubuntu/) release_name - имя релиза (в данном случае edgy), component - наименование компонента (main | restricted | universe | multiverse), type - тип пакета (binary | source), отражающий для бинарников ещё и архитектуру (binary-amd64, binary-powerpc).

Сколько компонентов и их типов предполагается использовать - столько потребуется и файлов Packages. Файлы эти, как было показано выше, легко читаемы, размер их сравнительно невелик. Так, для Ubuntu Edgy он составляет по 1,2 Мбайт (*.gz) или по 900 Кбайт (*.bz2) на каждый тип компонента main. Packages-файлы компонентов restricted и multiverse вообще не чувствительны (примерно по 5 и 100 килобайт). Наибольший "вес" дают типы компонента universe (3-4 Мбайт, в зависимости от компрессора), но и это не смертельно даже при модемном соединении.

Так вот, скачав где-либо нужные файлы Packages, перенеся их на целевую машину и поместив в каталог /var/lib/apt/lists, можно в даже при отсутствии Сети на ней, получить полную информацию о пакетах, предлагаемых репозиторием. Причем они будут доступны для любых программ управления deb-пакетами - утилит системы apt, aptitude, synaptic (Ubuntu и Xubuntu) или adept (Kubuntu).

Если скачать ещё и url/dists/your_distr/Release* - apt-утилиты перестанут "ругаться" по поводу "непроверенности" предлагаемых пакетов.

Названия файлов формируются просто, как "правда": url_dists_yourdistr_component_type_Packages То есть, например: au.archive.ubuntu.com_ubuntu_dists_dapper_main_binary-i386_Packages.

Так, в отсутствие Сети, можно познакомиться с тем, чтобы мы могли получить от того или иного репозитория, если бы Сеть была.

Все сказанное выше относилось к официальным репозиториям Ubuntu. Устройство репозиториев полу-официальных и неофициальных совсем может несколько отличаться в деталях. Причем "единство стиля" не всегда выдерживается даже внутри одного и того же репозитория. Например, в репозитории http://kubuntu.org/packages/ можно видеть дерево каталогов, где причудливо перемешаны подкаталоги отдельных пакетов различных версий (например, amarok), пакетных комплексов типа kde и koffice, их же для определенного релиза (например, hoary-kde341/ и так далее, hoary-koffice14/). Впрочем, это относится к ранним стадиям формирования репозитория. Ныне его структура устоялась, и каталоги последних версий marok, kde и koffice включат, как правило, подкаталог dists и отдельные подкаталоги для сборок под определенный релиз. Например, в состав каталога kde355 входят пулы сборок для Dapper и Edgy:

pool-dapper/
pool-edgy/

и так далее. Как сконструировать из них имена Packages-файлов - предоставляется читателю в качестве самостоятельного упражнения.

Все предыдущее изложение исходило из молчаливого допущения отсутствия подключения к Сети на целевой машине. Однако по настоящему эффективное использование средств пакетного менеджмента Debian (и, соответственно, Ubuntu) достигается в онлайновом режиме. Настройка онлайнового доступа к репозиториям будет предметом следующей заметки.