Возможно, что подобное желание выглядит странно, но всё же, как быть с обновлением компьютера, у которого нет доступа к сети? Можно было бы раз в несколько месяцев создавать срез зеркала и делать его локальным, но уж очень оно громоздкое. В связи с этим у меня возник ряд вопросов, о которых ниже.
1. Обновление списка пакетов.
Достаточно ли для для обновления списка пакетов скопировать файлы из .../rosa2014.1/repository/x86_64/<имя_источника>/media_info/ в /usr/lib/urmpi/<имя_источника>?
Сгенерируются ли при этом заново файлы c именами names.<имя_источника> из /usr/lib/urmpi/ или они не изменяются при обновлении?
Update:
Для обновления списка пакетов, похоже, достаточно обновить соответствующие файлы /usr/lib/urmpi/<имя_источника>. Соответствующие файлы лежащие на зеркале в .../rosa2014.1/repository/x86_64/<имя_источника>/media_info/ и .../rosa2014.1/repository/x86_64//media/<имя_источника>/media_info/ ничем не отличаются, поэтому будем считать, что скачиваем их из .../rosa2014.1/repository/x86_64/media/<имя_источника>/media_info/. Для этого можно воспользоваться скриптом:
@echo off
SET MIRROR_x86_64=http://mirror.rosalab.ru/rosa/rosa2014.1/repository/x86_64/media
SET MIRROR_i586=http://mirror.rosalab.ru/rosa/rosa2014.1/repository/i586/media
for %%G in (changelog.xml.lzma files.xml.lzma info.xml.lzma synthesis.hdlist.cz MD5SUM) do (
for %%H in (contrib main non-free restricted) do (
wget -N -P "rosa_repo/x86_64/%%H/" %MIRROR_x86_64%/%%H/release/media_info/%%G
wget -N -P "rosa_repo/x86_64/%%H updates/" %MIRROR_x86_64%/%%H/updates/media_info/%%G
wget -N -P "rosa_repo/i586/%%H/" %MIRROR_i586%/%%H/release/media_info/%%G
wget -N -P "rosa_repo/i586/%%H updates/" %MIRROR_i586%/%%H/updates/media_info/%%G
)
)
pause
Скаченные для каждого источника, кроме testing, файлы (changelog.xml.lzma, files.xml.lzma, info.xml.lzma, synthesis.hdlist.cz, MD5SUM) приносим на обновляемую систему и раскладываем в соответствующие каталоги в /usr/lib/urmpi/<имя_источника>. Зачем нужны директории "/usr/lib/urmpi/<имя_источника> (distributive N)" я не знаю, их я не трогал.
2. Получение списка ссылок для скачивания пакетов, которые должны обновиться после обновления источника.
Список ссылок для последующего скачивания для всех установленных пакетов, которым требуется обновления я получил так (как подсказали ниже в теме, можно короче):
где всё что находится в grep -v исключает из списка пакеты (обратный слэш \ в grep перед | экранирует этот знак в конвейере), которые установлены, но в системе их как бы нет, потому, что без grep выдавало следующее:
# urpmq -d -m --sources `rpm -qa --qf "%{NAME}\n"`
Нет пакета с названием kernel-nrj-desktop-devel-4.1.15-1rosa-x86_64
Нет пакета с названием kernel-nrj-desktop-4.1.15-1rosa-x86_64
Нет пакета с названием lib64pulsecommon7.1
Нет пакета с названием lib64llvm3.7
Нет пакета с названием lib64pulsecore7.1
Нет пакета с названием lib64ntfs-3g85
Нет пакета с названием frameworkintegration-i18n
Нет пакета с названием qt5-platformtheme-kde5
Нет пакета с названием lib64exttextcat1.0_0
Нет пакета с названием lib64osmgpsmap1.0_0
Всё было бы хорошо, если бы от запуска к запуску этой команды, количество выдаваемых ссылок не менялось (подсчитывал их через | wc -l). Для моей системы, которую я сейчас держу в VirtualBox выдавало 4 варианта списка, содержащих 823, 830, 888 или 895 "пакетов для скачивания", по сути это 2 пары списков 823-888 и 830-895 и 823-отличаются на 65 пакетов, а 823-830 и 888-895 на 8(+1) пакетов. Ниже пример для меньшего отличия в числе пакетов: 8(+) дополнительных пакетов есть в списке из 830 ссылок и 1(-) пакет вместо них в списке из 823 пакетов.
Почему так происходит я не понял. Может ли кто пояснить, почему от запуска к запуску (без установки и обновлений) команды выше, список файлов изменяется?
Update:
Как подсказал trs, список пакетов для скачивания, после обновления базы пакетов, можно получить командой
, таким образом, файл pkg_list.txt будет содержать список ссылок на пакеты, которые нужно скачать для обновления системы. Теперь его можно забрать с собой и выполнить в месте где доступен интернет команду
, получив в подкаталоге rpm_updates набор .rpm файлов. Если за время прошедшее перед скачиванием пакетов в репозитории пакеты не успели обновить на более новые версии, то всё необходимое скачается в данный подкаталог. Осталось привести эти файлы с собой на флешке, скопировать (пока именно скопировать, а не переместить) в каталог /var/cache/urpmi/rpms обновляемой системы и выполнить команду
Urpmi предупредит, что ему необходимо скачать определённое количество Mb пакетов, но на это можно не обращать внимания, так как все пакеты уже помещены в /var/cache/urpmi/rpms, он возьмёт их оттуда и сотрёт их после установки (если не запускать urpmi с параметром --noclean).
Последний раз редактировалось grem 11 окт 2016, 22:05, всего редактировалось 8 раз.
grem писал(а): Можно было бы раз в несколько месяцев создавать срез зеркала и делать его локальным, но уж очень оно громоздкое.
Но его не надо каждый раз скачивать заново, так как многие пакеты обновляются очень редко, а некоторые вообще, только при смене платформы...
Весь набор репозиториев для одной архитектуры занимает всего около 100 Gb. (внешнего HDD на 300 - 500Gb хватит и и не только на это) И можно сделать локальный репозиторий, когда нужно его обновлять, а потом с него обновлять ПК, находящиеся вне сети.
Галахов Роман писал(а):Весь набор репозиториев для одной архитектуры занимает всего около 100 Gb.
Для одной машины многовато выкачивать всё, если бы целый парк был, то имело бы смысл.
Пока попробую выкачивать .cz и .lzma файлы и указать структурированный каталог с ними как локальный источник. Даже только это без testing занимает уже 468 мб для обеих архитектур.
Полученный выше список .rpm легко выкачать, хоть и получилось пакетов меньше, чем ссылок в списке (808 пакетов по 895 ссылкам, 738 мб). Позже сравню список скаченных пакетов с перечнем пакетов в ссылках.
Это тот же список, что выводит urpmi --auto-update, но в виде путей для скачивания.
Не понял, зачем исходный вариант urpmq.
notauser писал(а):diff-репозиторий. Которого нет. Обновить ОС через COM-порт пробовали (всего около 100 Gb) ?
Мне нужен набор из 30 patch (читай diff). Я могу их получить, потыкав мышкой в веб-панели github. Но это утомительно и чревато ошибками. Проще дать в консоли команды git clone и git format-patch. То, что при этом будет скачано 2ГБ - такой пустяк.
Спасибо, попробую в следующий раз эту команду, а то мои манипуляции привели к тому, что из списка исчез пакет ядра. Это было первое, что пришло в голову, т.к. с urpmi я мало знаком.
Но всё равно непонятно, почему от запуска к запуску той команды состав возвращаемых ссылок меняется. Они, конечно, иногда продублированы, но всё равно почему-то иногда пара дополнительных пакетов проскакивало. Возможно как раз из-за обработки grep в потоке.
Попробую к моменту следующей пачки обновлений распихать новые вручную, главное успеть скачать новые пакеты до обновления баз
Можно, конечно, попытаться выкачать все пакеты новее определённой даты и на их основе создать источник, но это уже другой подход и локальную базу пакетов не обновит на тот случай, когда понадобится более новый пакет со всеми его зависимостями: новая версия может иметь дополнительные пакеты в зависимостях. Полный список пакетов всех источников сам по себе достаточно увесистый.
Надеюсь, что файлы "/var/lib/urpmi/names.<имя_источника>" со списками пакетов генерятся при опросе .xml.lzma и .cz файлов в источниках.
P.S.
И ещё интересна одна вещь: при выборе "всех пакетов" в "Управлении пакетами" они все после установки становятся "установленными вручную" или определённые автоматически помечаются как зависимости?
Последний раз редактировалось grem 28 сен 2016, 02:14, всего редактировалось 1 раз.
?