Сценарий такой: сервер-9.0-beta2. Ставим минимальную установку. Обновляем до p9 все пакеты, включая ядро. Переключаемся в sources.list на Sisyphus. apt-get update apt-get dist-upgrade Результат (выносится systemd): [root@mailman ~]# apt-get dist-upgrade Чтение списков пакетов... Завершено Построение дерева зависимостей... Завершено Подсчет обновлений... Завершено Следующие пакеты будут ОБНОВЛЕНЫ: alterator altlinux-repos bash-completion ca-certificates cgroup colord cpp cpp8 curl dhcpcd expect firmware-intel-ucode libX11 libX11-locales libXi libatm libcgroup libcolord libcups libcurl libedit3 libevdev libgcc1 libgcrypt20 libharfbuzz libjasper liblua5.3 libnfsidmap libnghttp2 libnss-myhostname libpango libpango-gir libpciaccess libpng16 libprocps libpsl libpython3 libstdc++6 libsystemd libtiff5 libudev1 libxml2 man-db nfs-clients nfs-utils pam_systemd pciids perl-Compress-Raw-Bzip2 perl-Compress-Raw-Zlib perl-IO-Compress perl-Net-HTTP perl-XML-LibXML perl-XML-SAX perl-base procps python3 python3-base rpm-macros-alterator shadow-change shadow-check shadow-convert shadow-edit shadow-groups shadow-log shadow-submap shadow-suite shadow-utils udev-hwdb udev-rules x11presetdrv xdg-utils Следующие пакеты будут УДАЛЕНЫ: alterator-grub alterator-net-bond alterator-net-bridge alterator-net-eth alterator-net-functions bash-completion-systemd bootloader-utils branding-alt-server-bootloader branding-alt-server-indexhtml dmeventd dmsetup etcnet etcnet-defaults-server firmware-linux firmware-ql6312 fuse fuse-common ifplugd indexhtml-common interactivesystem kernel-image-std-def#1:4.19.66-alt1:p9+235872.100.2.1@1565688248 kernel-image-std-def#1:4.19.68-alt1:p9+236574.100.1.1@1566755125 kernel-modules-drm-ancient-std-def#1:4.19.66-alt1:p9+235872.100.2.1@1565688248 kernel-modules-drm-ancient-std-def#1:4.19.68-alt1:p9+236574.100.1.1@1566755125 kernel-modules-drm-nouveau-std-def#1:4.19.66-alt1:p9+235872.100.2.1@1565688248 kernel-modules-drm-nouveau-std-def#1:4.19.68-alt1:p9+236574.100.1.1@1566755125 kernel-modules-drm-radeon-std-def#1:4.19.66-alt1:p9+235872.100.2.1@1565688248 kernel-modules-drm-radeon-std-def#1:4.19.68-alt1:p9+236574.100.1.1@1566755125 kernel-modules-drm-std-def#1:4.19.66-alt1:p9+235872.100.2.1@1565688248 kernel-modules-drm-std-def#1:4.19.68-alt1:p9+236574.100.1.1@1566755125 kernel-modules-kvm-std-def#1:4.19.66-alt1:p9+235872.100.2.1@1565688248 kernel-modules-kvm-std-def#1:4.19.68-alt1:p9+236574.100.1.1@1566755125 kernel-modules-v4l-std-def#1:4.19.66-alt1:p9+235872.100.2.1@1565688248 kernel-modules-v4l-std-def#1:4.19.68-alt1:p9+236574.100.1.1@1566755125 kernel-modules-virtualbox-addition-std-def#5.2.30-alt1.267074.1:p9+235872.2700.2.1@1565689866 kernel-modules-virtualbox-addition-std-def#5.2.30-alt1.267076.1:p9+236574.3000.1.1@1566756405 kernel-modules-virtualbox-std-def#5.2.30-alt1.267074.1:p9+235872.3000.2.1@1565689976 kernel-modules-virtualbox-std-def#5.2.30-alt1.267076.1:p9+236574.3100.1.1@1566756474 libfuse lvm2 make-initrd make-initrd-devmapper make-initrd-luks make-initrd-lvm make-initrd-mdadm make-initrd-multipath make-initrd-plymouth make-initrd-ucode memtest86+ multipath-tools ntfs-3g open-vm-tools open-vm-tools-desktop openssh-server startup systemd systemd-analyze systemd-services systemd-sysvinit systemd-utils tuned udev udev-extras vconsole-setup-kludge xorg-drv-evdev xorg-drv-fbdev xorg-drv-qxl xorg-drv-vboxvideo xorg-drv-vesa xorg-drv-vmmouse xorg-drv-vmware xorg-server xorg-server-common Следующие пакеты будут СОХРАНЕНЫ: iptables libiptables 71 будет обновлено, 0 новых установлено, 73 пакетов будет удалено и 2 не будет обновлено. Необходимо получить 31,7MB архивов. После распаковки будет освобождено 664MB дискового пространства. Продолжить? [Y/n] # apt-get install apt rpm Чтение списков пакетов... Завершено Построение дерева зависимостей... Завершено Последняя версия apt уже установлена. Последняя версия rpm уже установлена. 0 будет обновлено, 0 новых установлено, 0 пакетов будет удалено и 86 не будет обновлено.
Тоже вполне очевидно: # apt-get install --reinstall rpm Чтение списков пакетов... Завершено Построение дерева зависимостей... Завершено Reinstallation of rpm 4.13.0.1-alt12:p9+236401.100.1.1@1566384917 is not possible, it cannot be downloaded. 0 будет обновлено, 0 новых установлено, 0 пакетов будет удалено и 86 не будет обновлено.
В файле /usr/lib/rpm/macros нужно руками значение макроса %_priority_distbranch поменять с p9 на sisyphus Или сделать аналогичную запись в /etc/rpm/macros.d/ (Планируется немного реорганизовать пакеты, которые владеют файлом с этой настройкой. Но суть от этого не поменяется.) On Thu, 27 Jun 2019, Dmitry V. Levin wrote: > > Date: Thu, 27 Jun 2019 15:27:18 +0300 > From: Dmitry V. Levin <ldv@altlinux.org> > To: Anton V. Boyarshinov <boyarsh@altlinux.org> > Cc: Gleb Fotengauer-Malinovskiy <glebfm@altlinux.org>, Vladimir D. Seleznev <vseleznv@altlinux.org>, Ivan Zakharyaschev <imz@altlinux.org> > Subject: Re: Фатальные проблемы при попытке обновления с p9 на Сизиф > On Thu, Jun 27, 2019 at 03:19:25PM +0300, Anton V. Boyarshinov wrote: > > Машина, поставленная из p9, подключён сизиф. > > Правильно ли подключён сизиф? > В файле /usr/lib/rpm/macros значение макроса > %_priority_distbranch поменялось с p9 на sisyphus? On Thu, 27 Jun 2019, Anton V. Boyarshinov wrote: > > Date: Thu, 27 Jun 2019 15:40:26 +0300 > From: Anton V. Boyarshinov <boyarsh@altlinux.org> > To: Dmitry V. Levin <ldv@altlinux.org> > Cc: Gleb Fotengauer-Malinovskiy <glebfm@altlinux.org>, Vladimir D. Seleznev <vseleznv@altlinux.org>, Ivan Zakharyaschev <imz@altlinux.org>, Андрей Черепанов <cas@altlinux.ru> > Subject: Re: Фатальные проблемы при попытке обновления с p9 на Сизиф > > Спасибо > > > On Thu, Jun 27, 2019 at 03:19:25PM +0300, Anton V. Boyarshinov wrote: > > > Машина, поставленная из p9, подключён сизиф. > > > > Правильно ли подключён сизиф? > > В файле /usr/lib/rpm/macros значение макроса > > %_priority_distbranch поменялось с p9 на sisyphus? > > Не поменялось. Видимо, это следует считать недоработкой утилиты apt-repo > >
Спасибо. утилита apt-repo мне не помогла бы - в ней не очень удобно сделана работа с локальными репозиториями и я переключал репозиторий без неё. Почему бы не переместить эту настройку из пакета rpm в /etc/rpm/macros.d/ в пакет apt-conf-sisyphus /apt-conf-p9 ? На этот пакет не влияет настройка priority_distbranch
на ментейнера.
*** Bug 37398 has been marked as a duplicate of this bug. ***
проблема ещё актуальна.
А нельзя просто сделать, чтобы в Сизифе всегда версии пакетов rpm (и на всякий случай apt) всегда были более высокие, чем в бренчах? Только для этих двух пакетов.
Это не поможет.
Предлагается/планируется: Настройку значения макроса _priority_distbranch перенести из /usr/lib/rpm/ в место для настроек (/etc/). Его может отредактировать руками администратор или другие утилиты, например, apt-repo (который надо будет этому научить). Файл с установкой этого значения вынести в отдельный пакет rpm-conf, чтобы для изменения значения по умолчанию в бранче не надо было пересобирать пакет rpm, а у пользователя -- можно будет просто установить другую версию пакета rpm-conf при желании. Для удобства перехода с бранча p9 на Sisyphus релиз у пакета rpm-conf будет сделан по старой схеме бэкпортирования. (Т.е. после смены sources.list на Sisyphus администратору будет достаточно сначала сделать просто apt-get install rpm-conf, чтобы дальше получать правильные обновления из Sisyphus. В случае перехода с Sisyphus на p9 надо будет сделать один даунгрейд: apt-get install rpm-conf=1.0-alt0.M90P.1) Собирать rpm в p9 со сменой релиза по этой схеме не придётся. (А пришлось бы ради удобства перехода с p9 на Sisyphus, если бы эта настройка лежала бы в пакете rpm.) (Напомню, что эта история с явно выставленным значением _priority_distbranch появилась ради бранчей, которые форкаются, от Sisyphus например, после введения disttag. Если после форка бранча произошла бы пересборка пакета без смены релиза в p9, он бы не обновился у пользователя, потому что старый disttag "sisyphus" старше в соответствии с правилом упорядочивания версий пакетов. _priority_distbranch перекрывает это правило. Поэтому для бранчей, кроме p9 и Sisyphus, это значение вообще не определено, потому что нет практической пользы, а было бы только усложнение перехода с тех бранчей на Sisyphus или p9.) Пакет rpm будет иметь зависимость на пакет rpm-conf. Можно ещё пакет apt-conf (там есть несколько вариантов) сделать зависимым от rpm-conf. (Небольшое неудобство, что в Sisyphus есть и пакет apt-conf-branch, но пакет rpm-conf будет один, поэтому осмысленную зависимость в apt-conf-branch написать не получится.)
Схема нормальная, когда будет реализована ?
такое ощущение, что только мне интересно обновляться с p9 до Sisyphus, а больше никому наш unstable репозиторий не нужен. Сегодня опять имел удовольствие столкнуться с этим процессом и это, мягко говоря, не очень приятно. Хотел бы поинтересоваться прогрессом, есть ли он и будет ли ?
(In reply to Anton Farygin from comment #11) > такое ощущение, что только мне интересно обновляться с p9 до Sisyphus, а > больше никому наш unstable репозиторий не нужен. > > Сегодня опять имел удовольствие столкнуться с этим процессом и это, мягко > говоря, не очень приятно. > > Хотел бы поинтересоваться прогрессом, есть ли он и будет ли ? +1 Сегодня обновлял один контейнер с p9 до Сизифа, пока не обновил apt+rpm, было плохо.
(In reply to Dmitry V. Levin from comment #12) > Сегодня обновлял один контейнер с p9 до Сизифа, пока не обновил apt+rpm, > было плохо. apt там, конечно, по сути одинаковый, просто по привычке обновляю их вместе.
У меня было странное, я не знаю как это объяснить. 1) попытка обновить систему без правки /usr/lib/rpm/macros - остаются сохранённые пакеты, порядка 200 пакетов удаляется (это, правда, был не сервер, но сути это не меняет). 2) изменяю %_priority_distbranch в /usr/lib/rpm/macros на sisyphus - попытка обновления точно с таким же (FAIL) результатом. 3) apt-cache clean, apt-repo rm all, apt-repo add p9, apt-get update, apt-repo rm all, apt-repo add sisyphus - после этой странной жуткой нереальной магии обновление заработало нормально. Почему это случилось у меня ответа нет, но я очень хотел бы его услышать от авторов недоделанной фичи disttag, которой мы все прекрасно пользуемся с непредсказуемым (в дальнейшем) результатом.
(In reply to Anton Farygin from comment #14) > 3) apt-cache clean, apt-repo rm all, apt-repo add p9, apt-get update, > apt-repo rm all, apt-repo add sisyphus - после этой странной жуткой > нереальной магии обновление заработало нормально. Надо как-то перейти с языка магии на какой-то более понятный язык. Но если apt-cache clean что-то исправляет, значит, в apt какой-то очередной глюк с cache invalidation.
а разве редактирование /usr/lib/rpm/macros на предмет _priority_distbranch может триггернуть очистку кеша apt ? Т.е. - _priority_distbranch где-то записывается в кеше ?
(In reply to Ivan Zakharyaschev from comment #9) > Предлагается/планируется: > > Настройку значения макроса _priority_distbranch перенести из /usr/lib/rpm/ в > место для настроек (/etc/). Его может отредактировать руками администратор > или другие утилиты, например, apt-repo (который надо будет этому научить). > > Файл с установкой этого значения вынести в отдельный пакет rpm-conf, чтобы > для изменения значения по умолчанию в бранче не надо было пересобирать пакет > rpm, а у пользователя -- можно будет просто установить другую версию пакета > rpm-conf при желании. > > Для удобства перехода с бранча p9 на Sisyphus релиз у пакета rpm-conf будет > сделан по старой схеме бэкпортирования. (Т.е. после смены sources.list на > Sisyphus администратору будет достаточно сначала сделать просто apt-get > install rpm-conf, чтобы дальше получать правильные обновления из Sisyphus. В > случае перехода с Sisyphus на p9 надо будет сделать один даунгрейд: apt-get > install rpm-conf=1.0-alt0.M90P.1) Собирать rpm в p9 со сменой релиза по этой > схеме не придётся. (А пришлось бы ради удобства перехода с p9 на Sisyphus, > если бы эта настройка лежала бы в пакете rpm.) > > (Напомню, что эта история с явно выставленным значением _priority_distbranch > появилась ради бранчей, которые форкаются, от Sisyphus например, после > введения disttag. Если после форка бранча произошла бы пересборка пакета без > смены релиза в p9, он бы не обновился у пользователя, потому что старый > disttag "sisyphus" старше в соответствии с правилом упорядочивания версий > пакетов. _priority_distbranch перекрывает это правило. Поэтому для бранчей, > кроме p9 и Sisyphus, это значение вообще не определено, потому что нет > практической пользы, а было бы только усложнение перехода с тех бранчей на > Sisyphus или p9.) > > Пакет rpm будет иметь зависимость на пакет rpm-conf. Можно ещё пакет > apt-conf (там есть несколько вариантов) сделать зависимым от rpm-conf. > (Небольшое неудобство, что в Sisyphus есть и пакет apt-conf-branch, но пакет > rpm-conf будет один, поэтому осмысленную зависимость в apt-conf-branch > написать не получится.) $ cat /usr/lib/rpm/macros.d/altlinux-release %_priority_distbranch sisyphus $ rpmquery -f /usr/lib/rpm/macros.d/altlinux-release altlinux-release-sisyphus-20201124-alt1.noarch
Я так понимаю что осталось придумать как это сделать в p9. Может быть, apt-repo есть смысл пропатчить, что бы он добавлял %_priority_distbranch ?
*** Bug 39845 has been marked as a duplicate of this bug. ***
(In reply to Dmitry V. Levin from comment #17) > $ cat /usr/lib/rpm/macros.d/altlinux-release > %_priority_distbranch sisyphus > $ rpmquery -f /usr/lib/rpm/macros.d/altlinux-release > altlinux-release-sisyphus-20201124-alt1.noarch Попробовал сегодня обновить тестовую систему с p9 (установлена с какого-то предварительного Simply 9.1, обновлена до актуального p9) до Сизифа так: 1. изминил в /etc/apt/sources.list.d источники на Сизиф; apt-get update; 2. установил altlinux-release-sisyphus; пришлось сказать apt'у "Yes, do as I say!", ну да ладно. 3. (наверное необязательно, но я делал) apt-get clean; apt-get update; 4. apt-get dist-upgrade 5. добавить autoremove и update-kernel по вкусу (я не делал пока). Вроде бы всё отработало как надо, ничего нужного не удалилось.
Как вариант можно собрать какой-то аналог altlinux-release-sisyphus в p9, в котором будет лежать только нужный параметр макроса.
(In reply to Anton Farygin from comment #21) > Как вариант можно собрать какой-то аналог altlinux-release-sisyphus в p9, в > котором будет лежать только нужный параметр макроса. Мне вообще-то нравится идея, что на системе, обновлённой до Сизифа, в /etc/os-release будет написано Sisyphus. Это как бы правда. Так что процедура с установкой altlinux-release-sisyphus выглядит не слишком ужасной, достаточно её документировать на wiki например.
