Философия yum/apt-get

apt-get можно хитро понастраивать.

Идея простая - тебе нужно взять с домашней машины /var/lib/dpkg/status, настроить apt-get чтобы он скачивал не устанавливая. Затем на машине с толстым каналом делаешь apt-get update && apt-get dist-upgrade && apt-get install some-package, берешь скачанные файлы и листы, переносишь их на машину с узким каналом (в каталог /var/cache/apt/archives и листы в каталог /var/lib/apt/lists) и повторяешь apt-get update (apt-get check если листы тоже перенес) && apt-get dist-upgrade && apt-get install some-package.

Как вариант можно выкачанные файлы складировать локально, скачать Override файл (не помню, правда, где я его видел, можно /dev/null вместо него подсунуть), затем с помощью dpkg-scanpackages my-pool Override > Packages создать Pacakges файл, ну и добавить таким образом полученный локальный репозиторий в sources.list. Далее - apt-get update && apt-get dist-upgrade && apt-get install some-package

То есть проблема решаема :) Хотя получилось несколько сумбурно - слишком обширная тема (может статью написать?).

Вот, например, apt для Windows: http://www.linux.org.ru/jump-message.jsp?msgid=854595 (вдруг пригодится :) ). Прилагаются настройки для работы в вышеупомянутом режиме и инструкции. В случае если машина с толстым каналом - не Windows, действия в общем-то аналогичные.

Это в случае Debian-а. Для других дистрибутивов с apt возможны вариации.

> и повторяешь apt-get update

Этого уже не надо.

> затем с помощью dpkg-scanpackages my-pool Override > Packages создать Pacakges файл

Более подробно что, почему и зачем описано тут: http://www.debian.org/doc/manuals/repository-howto/repository-howto.html или тут: http://www.debian.org/doc/manuals/apt-howto/ch-basico.en.html#s-dpkg-scanpack... в разделе "How to use APT locally".

apt может создавать скриптик ( запускаемый кстати ) для того чтобы выкачать все что нужно на другой машине но для этого ему нужно подсунуть новые индексные файлы - красота

Надо, если листы не переносишь.

> Надо, если листы не переносишь.

А если листы качаешь на месте, то нафиг вообще этот огород городить вручную? Есть apt-zip.

А как я зависимости получу на машине с толстым каналом?

apt-zip - левое поделие, APT рулит :)

> А как я зависимости получу на машине с толстым каналом?

А зачем тебе там зависимости? Раз на целевой машине уже есть свежие списки, то имеется возможность разрешить все зависимости и сгенерить УЛРы пакетов. apt-zip генерит sh-скрипт, который wget'ом заливает пакеты. Оч. удобно, если на целевой машине есть хоть какой-то канал.

> apt-zip - левое поделие, APT рулит :)

Так apt-zip - это пара bash-скриптов, которые тем же apt-get'ом и пользуются :)

Для полностью offline машины я сам писал скриптики.

Я так делал:

>yum скачать его на работе вместе со всеми зависимостями, а потом

запустить createrepo для каталога с пакетами, потом записать на болванку, дома исправить URL в /etc/yum.repos.d/fedora-updates.repo на file:/media/cdrom/... , вставить "болванку", и дальше yum-ь себе, сколько нужно.

Не, просто часто бывает что заранее не знаешь что нужно. Либо за время пока ты дойдешь до машины с толстым каналом обновится репозиторий и твои скрипты устареют.

В таком случае, НАДО переносить и списки тоже. И apt-get update на целевой машине потом делать _не_ надо, иначе он скачает новые, в которых могут быть уже прописаны новые версии пакетов, которые ещё надо скачать.

А если источники разные? :)

Что значит, источники разные? sources.list?

Мои скрипты забирали с оффлайновой машины status и sources.list, на онлайновой машине качали с этими сведениями update, install и dist-upgrade, переносили обратно на оффлайновую lists и archives. Всё. Никаких разных источников. sources.list на онлайновой машине не имеет значения, т.к. скрипты подсовывают apt'у конфиг, указывающий на sources.list с оффлайновой.

А если у тебя sources.list разные, то можно (и очень вероятно) огрести проблемы с различными версиями пакетов в разных репозитариях. Ну, и опять же, упомянутая тобой проблема - пока ты ходишь от одной машины до другой, списки могут поменяться. Это, кстати, гораздо вероятнее исчезновения пакета с сайта - например, за время рабочего дня+дорога репозитарии, как правило, уже успевают обновиться.

>А если у тебя sources.list разные, то можно (и очень вероятно) огрести проблемы с различными версиями пакетов в разных репозитариях.

Можно, но по другому никак. С одной машины видно одно зеркало, с другой - другое.

>Это, кстати, гораздо вероятнее исчезновения пакета с сайта - например, за время рабочего дня+дорога репозитарии, как правило, уже успевают обновиться.

Да, такое тоже бывает. Но apt-get update я сделать могу. Вероятность того, что изменения массивные (и файлы принесенные в /var/cache/apt/archives устареют) невелика. Т.е пару файлов + apt-get update на тонком канале я могу позволить.

> С одной машины видно одно зеркало, с другой - другое

На оффлайновой машине можно прописать в sources.list всё что угодно. На полностью оффлайновой машине вообще никаких зеркал не видно, кроме локальных на HDD/CD :) Главное, чтобы всем записям в sources.list соответствовали списки в /var/lib/apt/lists и необходимые пакеты уже лежали в /var/cache/apt/archives. Тогда всё будет Ok, только apt-get update делать не надо :)

> Но apt-get update я сделать могу

Как я написал выше - не всегда. Я жил на оффлайновой машине со стандартными репозитариями ftp.us.debian.org в sources.list. apt-get update на таком, естественно, обломится, т.к. инета на машине нет в принципе, а если списки и пакеты таскать руками - всё отлично обновлялось.

> Вероятность того, что изменения массивные (и файлы принесенные в /var/cache/apt/archives устареют) невелика.

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