Bug 35529 - сломано обновление с p10 до sisyphus
Summary: сломано обновление с p10 до sisyphus
Status: REOPENED
Alias: None
Product: Sisyphus
Classification: Development
Component: rpm (show other bugs)
Version: unstable
Hardware: all Linux
: P3 blocker
Assignee: Vladimir D. Seleznev
QA Contact: qa-sisyphus
URL:
Keywords:
: 36711 (view as bug list)
Depends on: 35737 36872
Blocks: 34231
  Show dependency tree
 
Reported: 2018-10-19 12:13 MSK by Anton Farygin
Modified: 2023-07-13 14:09 MSK (History)
27 users (show)

See Also:


Attachments
Расцветка синтаксиса Midnight Commander (921 bytes, text/plain)
2018-12-20 10:23 MSK, Вадим Илларионов
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Anton Farygin 2018-10-19 12:13:59 MSK
Новый конфиг /etc/apt/preferences не приезжает ни с каким пакетом, обновляться пакеты с одинаковыми версиями естественно не хотят.

apt-conf-sisyphus установлен.
Comment 1 Anton Farygin 2018-10-19 12:21:50 MSK
Более того - мои попытки придумать /etc/apt/preferences ни к чему не привели - обновления по прежнему не работают. Ну или нужен какой-то пример.

Что писать в Pin: release l= ???
Comment 2 Anton Farygin 2018-10-19 13:43:04 MSK
Кому не блокер, а мне так срочно прямо сейчас нужно обновиться.
Comment 3 Anton Farygin 2018-10-19 13:50:28 MSK
$ cat /etc/apt/preferences
Package: *
Pin: release l=Sisyphus
Pin-Priority: 700

так не работает.

Да собственно никак не работает, что я уже только в /etc/apt/preferences не писал.

Кто-то мне говорил что у него это работает и он этим пользуется. Не мог бы этот кто-то описать рецепт для обновления workstation K с p8 до Sisyphus ?

Спасибо заранее.
Comment 4 Anton Farygin 2018-10-19 14:05:36 MSK
поднятие Pin-priority до значения больше 1000 помогает запустить процесс обновления.

нужно конфиг по умолчанию.
Comment 5 Anton Farygin 2018-10-19 14:09:16 MSK
Заработало оно правда тоже весьма странно:

Следующие пакеты будут ЗАМЕНЕНЫ БОЛЕЕ СТАРЫМИ ВЕРСИЯМИ:
  gtk-theme-breeze kde5-mini kde5-runtime kde5-small libcolorcorrect5 libkdecorations25 libkdecorations2private5 libkf5screen libkwin4_effect_builtins1
  libkwin5 libkwineffects11 libkwinglutils11 libkwinxrenderutils11 libkworkspace55 libplasma-geolocation-interface5 libpowerdevilconfigcommonprivate5
  libpowerdevilcore2 libpowerdevilui5 libsystemsettingsview3 libtaskmanager6 libweather_ion7 pciids plasma5-breeze plasma5-drkonqi plasma5-integration
  plasma5-kactivitymanagerd plasma5-kde-cli-tools plasma5-kdecoration-common plasma5-ksysguard plasma5-kwayland-integration plasma5-kwin plasma5-kwin-common
  plasma5-libkscreen-common plasma5-nm plasma5-nm-connect-fortisslvpn plasma5-nm-connect-iodine plasma5-nm-connect-l2tp plasma5-nm-connect-mobile
  plasma5-nm-connect-openconnect plasma5-nm-connect-openswan plasma5-nm-connect-openvpn plasma5-nm-connect-pptp plasma5-nm-connect-ssh
  plasma5-nm-connect-sstp plasma5-nm-connect-strongswan plasma5-nm-connect-vpnc plasma5-nm-maxi plasma5-pa plasma5-polkit-kde-agent plasma5-powerdevil
  plasma5-powerdevil-common plasma5-sddm-kcm plasma5-systemsettings plasma5-systemsettings-common plasma5-workspace plasma5-workspace-common
Comment 6 Dmitry V. Levin 2018-10-19 14:32:59 MSK
(In reply to comment #5)
> Заработало оно правда тоже весьма странно:
> 
> Следующие пакеты будут ЗАМЕНЕНЫ БОЛЕЕ СТАРЫМИ ВЕРСИЯМИ:

Да, это сообщение на первый взгляд выглядит странно.
Но посколько пакеты в Сизиф были собраны раньше, чем в бранч, с точки зрения apt они действительно старее.

Пожалуйста, предлагайте более удачные формулировки и/или идеи.
Comment 7 Anton Farygin 2018-10-19 14:38:23 MSK
Я понимаю почему это происходит.

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

Если дату сборки убрать из алгоритма вычисления возраста пакетов, то dist-upgrade заработает и с более низким pin-priority и не возникнет случайной ситуации, когда действительно будет понижение версии, а не сборка точно такой же версии в другом окружении.

Вообще, Дима, что я тебе советую - у тебя же своя голова на плечах есть. 
Сделай как-нибуть что бы было хорошо, пожалуйста.
Comment 8 Sergey V Turchin 2018-10-19 14:48:56 MSK
(В ответ на комментарий №7)
> Если дату сборки убрать из алгоритма вычисления возраста пакетов
Не-не! Убирать не надо. Я постоянно пользуюсь.
Надо инфу про бранч сделать более приоритетной.
Comment 9 Anton Farygin 2018-10-19 14:51:53 MSK
Нет, ты не понял. Убрать надо только из алгоритма сравнения при pin-priority < 1000 (если такое возможно)

Впрочем, я уже сказал. пусть ldv голову ломает, он себя умнее всех окружающсчитает.
Comment 10 Vladimir D. Seleznev 2018-11-15 22:55:14 MSK
Я хочу отметить, что сообщение с тем, что пакеты будут DOWNGRADED будет отображаться для большого количества пакетов только при обновления с последнего бранча платформ на Сизиф. При обновлении с бранча на следующий бранч количество таких пакетов будет незначительно, если вообще таковые будут.

О такое поведении можно задокументировать в вики, оповестить в списке рассылки и описать в особенностях в QA на wiki.
Comment 11 Anton Farygin 2018-11-16 07:41:55 MSK
Можно, и нужно, но врятли это поможет - большое количество людей просто не пойдут искать информацию, почему у них массово доунгрейдятся пакеты при обновлении дистрибутива.

И почему это не будет происходить при любом обновлении на новый бранч, вышедший на новом Sisyphus?

Чем он хуже Sisyphus ?
Comment 12 Sergey V Turchin 2018-11-16 10:01:33 MSK
Еще попробуйте поиграться c dist-upgrade c p8 до sisyphus, а потом обратно, а потом опять.
Comment 13 Vladimir D. Seleznev 2018-11-19 13:58:22 MSK
(In reply to comment #11)
> Можно, и нужно, но врятли это поможет - большое количество людей просто не
> пойдут искать информацию, почему у них массово доунгрейдятся пакеты при
> обновлении дистрибутива.

Я не готов давать свою оценку, но все эти рассуждения из области спекуляции.

> И почему это не будет происходить при любом обновлении на новый бранч, вышедший
> на новом Sisyphus?

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

> Чем он хуже Sisyphus ?

Не знаю.

Тем временем: #216554 — apt-conf-branch для p8, #215590 — apt-conf-sisyphus.
Comment 14 Anton Farygin 2018-11-19 14:00:20 MSK
(В ответ на комментарий №13)
> (In reply to comment #11)
> 
> > И почему это не будет происходить при любом обновлении на новый бранч, вышедший
> > на новом Sisyphus?
> 
> Потому что предыдущий бранч будет поддерживаться только в течении относительно
> небольшого времени, и вероятно поддержка будет касаться только исправления
> критических проблем и закрытия уязвимостей. Следовательно, новые релизы будут
> собираться и бекпортироваться значительно реже.

Да, но их уже набэкпортировано и собрано достаточно, что бы при обновлении с p8 на тот Sisyphus, который станет p9 - вылезло такое сообщение.
Comment 15 Anton Farygin 2018-12-08 11:05:53 MSK
Вот с таким конфигом обновляется. Когда ждать правильный preferences в пакете ?

# cat /etc/apt/preferences
Package: *
Pin: release l=Sisyphus
Pin-Priority: 1001
Comment 16 Vladimir D. Seleznev 2018-12-12 14:54:09 MSK
(In reply to comment #15)
> Вот с таким конфигом обновляется. Когда ждать правильный preferences в пакете ?
> 
> # cat /etc/apt/preferences
> Package: *
> Pin: release l=Sisyphus
> Pin-Priority: 1001

По видимому, идея использовать механизм apt_preferences неудачная. Помимо смущающего сообщения про DOWNGRADE ещё проявляется куча проблем, такие как, например, "обновление" пакета, собранного локально, пакетов из репозитория, проблема из #35737 и др.. Прорабатываем новый механизм сравнения версий rpm-пакетов.
Comment 17 Sergey Y. Afonin 2018-12-18 09:16:46 MSK
(In reply to comment #16)

> По видимому, идея использовать механизм apt_preferences неудачная.

Может сама идея делать rebuild при копировании неудачная, а удобство сборки в разные бранчи, таким образом полученное, не стоит последствий? Или уж не знаю, может как-то автоматом время сборки в более новых бранчах повышать при таком процессе, хоть тем же rebuild. Но тут вопрос, справится ли борочница.
Comment 18 Anton Farygin 2018-12-18 09:27:43 MSK
Это не поможет. Нужно учитывать тэг дистрибутива в сравнении версий, если я правильно помню - этот вопрос поднимался в devel в другом контексте - использование этого тэга при сборке пакетов в спеке.

Наверное, это можно было бы сделать, есть бы в RPMTAG_DISTTAG писался тэг, по имени которого можно проводить какое-то сравнение. Но там сейчас какая-то странная информация, не несущая никакой пользы для исправления этой ошибки:

$ rpm -qp --qf '%{RPMTAG_DISTTAG}\n'  p8/branch/x86_64/RPMS.classic/libmysqlclient20-5.7.24-alt1.x86_64.rpm 
p8.216685.100

$ rpm -qp --qf '%{RPMTAG_DISTTAG}\n'  /mnt/ftp/pub/distributions/ALTLinux/Sisyphus/x86_64/RPMS.classic/libmysqlclient20-5.7.24-alt2.x86_64.rpm 
sisyphus.216505.700

А вот если б в этот тэг писать версию бранча (7,8 или 9 (для текущего Sisyphus)), которую не забывать увеличивать для каждой новой ветви - то её можно было бы использовать в сравнении версии.
Comment 19 Ivan A. Melnikov 2018-12-18 09:34:09 MSK
(In reply to comment #18)
[...]
> Наверное, это можно было бы сделать, есть бы в RPMTAG_DISTTAG писался тэг, по
> имени которого можно проводить какое-то сравнение. Но там сейчас какая-то
> странная информация, не несущая никакой пользы для исправления этой ошибки:
[...]

Отчего же?

$ rpmevrcmp p8.216685.100 sisyphus.216505.700
-3
Comment 20 Anton Farygin 2018-12-18 09:35:12 MSK
Оттого, что придётся проводить пересборку всех пакетов в момент выпуска нового бранча.
Comment 21 Anton Farygin 2018-12-18 09:38:00 MSK
И да, у нас есть ещё ветки c и (возможно) t.
$ rpmvercmp p8 c8
1
Comment 22 Ivan A. Melnikov 2018-12-18 09:52:32 MSK
(In reply to comment #20)
> Оттого, что придётся проводить пересборку всех пакетов в момент выпуска нового
> бранча.

Почему Вы так считаете?

Напомню, что это сравнение будет нужно только при равенстве %EVR -- новая версия пакета всегда дожна быть новее. То есть, disttag приходит на замену суффикса в релизе -- такой %ubt на стероидах. Так что того, что disttag в p8 < disttag в p9  < disttag в sisyphus достаточно.

Переход между разными ветками с одной цифрой -- это другой вопрос. Он вообще когда-нибудь поддерживался?
Comment 23 Anton Farygin 2018-12-18 10:15:05 MSK
Пересборку ? да не для обновления конечно. 
У нас и сейчас в новой схеме нет возможности каким-то образом идентифицировать, для какого бранча был собран тот или иной пакет, а с DISTTAG это станет ещё тяжелее.

Уж если это ubt на стероидах, то тогда точно надо пересобирать, хотя бы для того, что бы гарантировать неизменность пакета после пересборки.
Comment 24 Anton Farygin 2018-12-18 10:20:18 MSK
Но после пересборки произойдёт изменение тэга DISTTAG и де-факто - его уменьшение.
Т.е. - те, у кого пакет был установлен с DISTTAG в sisyphus не смогут обновиться.

Поэтому правильнее было бы сразу ставить тэг следующего бранча в sisyphus.
Но что делать с сертифицированными ветками всё равно не очень понятно.
Comment 25 Sergey V Turchin 2018-12-18 10:42:33 MSK
(В ответ на комментарий №21)
> И да, у нас есть ещё ветки c и (возможно) t.
> $ rpmvercmp p8 c8
Если сейчас неправильное поведение, значит нужно исправить наименование.
Comment 26 Вадим Илларионов 2018-12-20 10:23:53 MSK
Created attachment 7911 [details]
Расцветка синтаксиса Midnight Commander
Comment 27 Вадим Илларионов 2018-12-20 10:26:09 MSK
Ой, вроде, новую создавал. Что-то пошло не так, прошу прощения.
Comment 28 Sergey Y. Afonin 2018-12-20 15:41:19 MSK
Comment on attachment 7911 [details]
Расцветка синтаксиса Midnight Commander

Это в bug 35799
Comment 29 Sergey V Turchin 2018-12-20 15:43:18 MSK
Comment on attachment 7911 [details]
Расцветка синтаксиса Midnight Commander

.
Comment 30 Vladimir D. Seleznev 2018-12-21 19:27:52 MSK
(In reply to comment #18)
> Это не поможет. Нужно учитывать тэг дистрибутива в сравнении версий, если я
> правильно помню - этот вопрос поднимался в devel в другом контексте -
> использование этого тэга при сборке пакетов в спеке.
> 
> Наверное, это можно было бы сделать, есть бы в RPMTAG_DISTTAG писался тэг, по
> имени которого можно проводить какое-то сравнение. Но там сейчас какая-то
> странная информация, не несущая никакой пользы для исправления этой ошибки:
> 
> $ rpm -qp --qf '%{RPMTAG_DISTTAG}\n' 
> p8/branch/x86_64/RPMS.classic/libmysqlclient20-5.7.24-alt1.x86_64.rpm 
> p8.216685.100
> 
> $ rpm -qp --qf '%{RPMTAG_DISTTAG}\n' 
> /mnt/ftp/pub/distributions/ALTLinux/Sisyphus/x86_64/RPMS.classic/libmysqlclient20-5.7.24-alt2.x86_64.rpm 
> sisyphus.216505.700
> 
> А вот если б в этот тэг писать версию бранча (7,8 или 9 (для текущего
> Sisyphus)), которую не забывать увеличивать для каждой новой ветви - то её
> можно было бы использовать в сравнении версии.

Как раз-таки disttag планируется использовать для сравнении версии пакетов. В нём таки записан целевой бранч. Планируется в конфиг rpm ввести новую опцию конфигурации (формат пока не специфицирован), в которой записывалось отношение бранчей.

(In reply to comment #20)
> Оттого, что придётся проводить пересборку всех пакетов в момент выпуска нового
> бранча.

Может быть это не такая уж и плохая мысль. Получим пакеты, собранные в новом окружении, а те, что не пересоберутся — останутся такими же, как в исходном бранче. Но на самом деле это не обязательно: конфиг rpm может быть разным в зависимости от бранча.

(In reply to comment #21)
> И да, у нас есть ещё ветки c и (возможно) t.
> $ rpmvercmp p8 c8
> 1

Планирует явно прописывать отношения между бранчами, а не лексиографическое сравнение. rpmvercmp для этого не подходит. Более того, предлагается описать отношения для все известных бранчей, но определять отношения только для бранчей одной линейки, т.е. p8 > p7, с8 > c7, но отношения межу p8 и c8 неопределено. Если для описания отношений использовать макрос (назовём его в примере relate_branch_version), то можно использовать символ ":" в качестве разделителя между линейками отношений, упорядоченных по возрастанию, например:

relate_branch_version: p6 p7 p8 : c6 c7 c7.1 c8 c8.1 : t6 t7

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

1. Большая эпоха побеждает, иначе
2. Большая версия побеждает, иначе
3. Больший релиз побеждает, иначе
4. Если целевые бранчи пакетов сравнимы, то побеждает больший по порядку, в противном случае (т.е., случае, когда или бранчи совпадают, или они не сравнимы)
5. Больший buildtime побеждает

Отмечу также, что самосборные пакеты, в которых disttag пустой, также будут устанавливаться и выигрывать при совпадении EVR сравниваться по пункту 5.
Comment 31 Anton Farygin 2018-12-21 19:41:45 MSK
Ну да, во первых непонятно как будут сравниваться самосборные пакеты.

Во вторых, представим ситуацию, когда у нас странным образом в бранч p8 попал пакет, релиз которого взят из Sisyphus, но в бранч p9 этот пакет отправлен не был. Тогда обновления с p8 на p9 не будет (но его и сейчас нет, это правда).

Ну а по сути то, что ты предлагаешь - это аналог pin-priority на уровне librpm.

Сразу будет вопрос - в каких rpm'ах это придётся реализовать, как это повлияет на обновления в тех самых стабильных ветках, в которых тебе придётся поменять rpm и его логику сравнения. 
И как это повлияет на межпакетные зависимости.
Comment 32 Vladimir D. Seleznev 2018-12-21 19:56:00 MSK
(In reply to comment #31)
> Ну да, во первых непонятно как будут сравниваться самосборные пакеты.

Я явно написал, как будут сравниваться самосборные пакеты.

> Во вторых, представим ситуацию, когда у нас странным образом в бранч p8 попал
> пакет, релиз которого взят из Sisyphus, но в бранч p9 этот пакет отправлен не
> был. Тогда обновления с p8 на p9 не будет (но его и сейчас нет, это правда).

Странным образом он попасть не мог, только в процессе бранчевания. Или вы имеете в виду в результате команды task add copy? Обновление будет, если конфиг будет написан так.

> Ну а по сути то, что ты предлагаешь - это аналог pin-priority на уровне librpm.

Не совсем, но идеи похожи.

> Сразу будет вопрос - в каких rpm'ах это придётся реализовать, как это повлияет
> на обновления в тех самых стабильных ветках, в которых тебе придётся поменять
> rpm и его логику сравнения. 

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

> И как это повлияет на межпакетные зависимости.

На межподпакетные в итоге никак, а на межпакетные — таким образом, как это описано алгоритмом.
Comment 33 Anton Farygin 2018-12-21 20:04:36 MSK
Я из этого описание не понял.
Вообще, наверное было бы здорово дать возможность локально собирать пакеты с такими же межпакетными зависимостями и таким же DISTTAG, как и в репозитории.
Иначе происходит странное - пересборка hasher'ом пакета из p8 в среде p8 меняет его зависимости.
Comment 34 Vladimir D. Seleznev 2018-12-21 20:17:56 MSK
(In reply to comment #33)
> Я из этого описание не понял.
> Вообще, наверное было бы здорово дать возможность локально собирать пакеты с
> такими же межпакетными зависимостями и таким же DISTTAG, как и в репозитории.
> Иначе происходит странное - пересборка hasher'ом пакета из p8 в среде p8 меняет
> его зависимости.

Можно в сборочной среде выставить значение переменной окружения RPM_STRICT_INTERDEPS. Пока вручную. Потом не надо будет: от неё я планирую избавиться в пользу значения тега disttag.
Comment 35 Anton Farygin 2019-02-01 08:09:11 MSK
улучшений пока не заметно.
Ждём изменений в apt и rpm
Comment 36 Anton Farygin 2019-02-08 08:01:27 MSK
вчера с p8 до sisyphus не смог обновиться и с rpm из таска (который поддерживает новые виды зависимостей) и с preferences одновременно. - удалялась вся графическая подсистема.

Воспроизвелось на workstation K 8.3, установленной в максимальной конфигурации.

Попытки обновить apt+rpm тоже не приводили ни к чему хорошему.

Когда ожидать починки rpm в p8 ?
Comment 37 Anton Farygin 2019-02-15 08:07:34 MSK
*** Bug 36109 has been marked as a duplicate of this bug. ***
Comment 38 Anton Farygin 2019-02-26 16:54:54 MSK
На данный момент обновление с p8 до Sisyphus работает, удаляется совсем чуть чуть и по причинам, не связанным с rpm.
Comment 39 AEN 2019-02-26 16:55:38 MSK
Ура!
Спасибо!
Comment 40 Anton Farygin 2019-03-01 12:27:13 MSK
прошу прощения, был не прав - лучше не стало.
Comment 41 Ivan Zakharyaschev 2019-03-01 12:47:30 MSK
(In reply to comment #40)
> прошу прощения, был не прав - лучше не стало.

На всякий случай скажу вещь, в которой я теперь уверен: обновляться до Sisyphus может иметь смысл только после обновления rpm сначала.

По причине https://bugzilla.altlinux.org/show_bug.cgi?id=36180#c42 (потому что rpm-build не генерирует Provides старого формата):

Even if in the i586 or x86_64 repo apt can dynamically construct an old-style
disttag-less Provides, so that apt doesn't see an unmet dependency
php7-ldap->php7-libs, rpm won't do this (I suppose).

Old rpm would see this as an unmet dependency: the Provides has a disttag in
the version string, but the Requires doesn't.

(Only the generation of two Provides (one for compatibility) would make
possible the use of old rpm with a repo with new packages.)

(Для бранчей можно будет включить генерацию второго Provides, чтобы проще обновлять без предварительного обновления rpm можно было.)
Comment 42 Anton Farygin 2019-03-01 13:31:56 MSK
Да, стандартная схема обновления - обновиться полностью до бранча (включая rpm), потом обновить до Sisyphus.

Или ты о чём-то другом ?
Comment 43 Anton Farygin 2019-03-01 13:36:56 MSK
Обновил до p8
перенастроил apt на Sisyphus.
apt-get install apt - обновился apt+rpm и удалился apt-indicator.

apt-get dist-upgrade удаляет больше четверти пакетов.

Странно, вроде как если apt и rpm из Sisyphus, то всё должно начать работать нормально ? нет ?
Comment 44 Anton Farygin 2019-03-01 13:49:35 MSK
Мне кажется, что это проблема в https://bugzilla.altlinux.org/show_bug.cgi?id=36197
Comment 45 Ivan Zakharyaschev 2019-03-01 13:50:17 MSK
(In reply to comment #42)
> Да, стандартная схема обновления - обновиться полностью до бранча (включая
> rpm), потом обновить до Sisyphus.

Тут нужно сначала ещё новый rpm и/или apt поставить как шаг посередине.

> Или ты о чём-то другом ?

Я просто о том, что этот тест нельзя делать так же, как обновление внутри бранча. (А обновление внутри бранча надо тоже будет тестировать после включения генерации Provides нового вида.)

Т.е. сейчас нельзя совместить эти два теста, примерно прикинуть, какие будут проблемы при обновлении внутри бранча. (Точнее и так понятно, что большие, если представить себе, что Sisyphus -- это примерно состояние бранча.)
Comment 46 Ivan Zakharyaschev 2019-03-01 13:51:58 MSK
(In reply to comment #44)
> Мне кажется, что это проблема в
> https://bugzilla.altlinux.org/show_bug.cgi?id=36197

Не знаю. Там сначала какие-то файловые конфликты упомянуты, а их apt не видит.
Comment 47 Ivan Zakharyaschev 2019-03-01 13:53:11 MSK
(In reply to comment #43)
> Обновил до p8
> перенастроил apt на Sisyphus.
> apt-get install apt - обновился apt+rpm и удалился apt-indicator.

vseleznv@ подготовил новый apt, его нет в Sisyphus пока.

> apt-get dist-upgrade удаляет больше четверти пакетов.
> 
> Странно, вроде как если apt и rpm из Sisyphus, то всё должно начать работать
> нормально ? нет ?

Да (только apt из задания).
Comment 48 Anton Farygin 2019-03-01 13:55:50 MSK
Из какого задания ? Давай я попробую.

Там файловые конфликты потому, что apt не справился с переездом библиотеки из libGL в libGLX-mesa. ему надо было просчитать, что libGLX-mesa надо тоже обновлять.
Comment 49 Anton Farygin 2019-03-01 13:58:54 MSK
Поставил apt из задания 223177 - ничего не изменилось.
Проблема где-то в libGL, т.к. apt её хочет оставить (kept back), а это приводит явно к удалению всего, что от неё зависит.
Comment 50 Ivan Zakharyaschev 2019-03-01 14:10:33 MSK
(In reply to comment #48)
> Из какого задания ? Давай я попробую.
> 
> Там файловые конфликты потому, что apt не справился с переездом библиотеки из
> libGL в libGLX-mesa. ему надо было просчитать, что libGLX-mesa надо тоже
> обновлять.

Ясно, спасибо за понятное объяснение.

Возможно, недоработка в обработке Obsoletes. Может касаться и rpm, и apt. Интересный test case.
Comment 51 Anton Farygin 2019-05-01 09:01:05 MSK
*** Bug 36711 has been marked as a duplicate of this bug. ***
Comment 52 Ivan Zakharyaschev 2019-05-22 16:58:50 MSK
Хочется проверить с

apt для p8 задание 229746
apt для sisyphus задание 229746

Порядок обновления я, конечно, предполагаю такой:

сначала обновляем apt и rpm из p8,
потом dist-upgrade из p8,
потом обновляем apt и rpm из sisyphus,
потом dist-upgrade из sisyphus.

(Возможно, чтобы apt лучшим для нас образом просчитал обновление, нужно будет пересобрать некоторое множество пакетов в p8 с новым форматом строгих зависимостей. Такое предположение было -- из-за scoring в apt, но было и предположение, что это не важно.)
Comment 53 Anton Farygin 2019-05-22 17:13:15 MSK
Т.е.:
- устанавливаем рабочую станцию 8.2
- обновляем её до p8 + задание 229746
- sources.list меняем на Sisyphus + задание 229746
- устанаваливаем apt + rpm из Sisyphus + задание 229746
- обновляем всё остальное.
Comment 54 Anton Farygin 2019-05-22 17:14:34 MSK
Для Sisyphus то какое задание ?
Comment 55 Ivan Zakharyaschev 2019-05-22 18:43:57 MSK
(In reply to comment #52)
> Хочется проверить с
> 
> apt для p8 задание 229746
> apt для sisyphus задание 229746

я имел в виду 229767 для sisyphus (сейчас собирается)

> 
> Порядок обновления я, конечно, предполагаю такой:
> 
> сначала обновляем apt и rpm из p8,
> потом dist-upgrade из p8,
> потом обновляем apt и rpm из sisyphus,
> потом dist-upgrade из sisyphus.
> 
> (Возможно, чтобы apt лучшим для нас образом просчитал обновление, нужно будет
> пересобрать некоторое множество пакетов в p8 с новым форматом строгих
> зависимостей. Такое предположение было -- из-за scoring в apt, но было и
> предположение, что это не важно.)
Comment 56 Ivan Zakharyaschev 2019-05-22 18:50:33 MSK
(In reply to comment #53)
> Т.е.:

Да, такой вполне понятный порядок.

> - устанавливаем рабочую станцию 8.2

Если делать всё очень пошагово, то здесь сначала можно

- sources.list меняем на p8 + задание 229746
- устанаваливаем apt + rpm из p8 + задание 229746

> - обновляем её до p8 + задание 229746
> - sources.list меняем на Sisyphus + задание 229767
> - устанаваливаем apt + rpm из Sisyphus + задание 229767
> - обновляем всё остальное.

Последние два шага можно (по моим предположениям) объединить -- не обновлять отдельно apt + rpm из Sisyphus. Тогда мы, кстати, проскочим проблему (пока ещё не решённую) с заменой симлинка благодаря pre-скриптам, если они написаны правильно.

Оба варианта эксперимента, конечно, показательны.
Comment 57 Anton Farygin 2019-05-22 20:36:14 MSK
Важно проверить сценарий обновление дистрибутива до p8 + задание с apt/rpm, минуя точечное обновление до apt+rpm из задания.
Comment 58 Anton Farygin 2019-05-22 20:45:14 MSK
Ждём сборки задания для Sisyphus. Пока что оно упало с ошибкой. Как соберётся - напиши пожалуйста.
Comment 59 Ivan Zakharyaschev 2019-05-23 02:17:49 MSK
(In reply to comment #58)
> Ждём сборки задания для Sisyphus. Пока что оно упало с ошибкой. Как соберётся -
> напиши пожалуйста.

Я напишу. Надеюсь, скоро.

Но для проверки обновления это, кажется, сейчас даже не принципиально.

Можно просто сначала обновить до p8, потом до Sisyphus. (Просто в результиующей системе apt и rpm будут не очень хорошо работать при последующем использовании.)

Потому что в процессе обновления apt и rpm из Sisyphus не используется.

Алгоритм работы для p8 реализован такой же, как и для Sisyphus, поэтому необходимости использовать именно rpm и apt из Sisyphus не должно быть.
Comment 60 Ivan Zakharyaschev 2019-05-23 04:28:44 MSK
(In reply to comment #43)
> Обновил до p8
> перенастроил apt на Sisyphus.
> apt-get install apt - обновился apt+rpm и удалился apt-indicator.
> 
> apt-get dist-upgrade удаляет больше четверти пакетов.

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

Я, когда этот bug report появился, пробовал и сейчас ещё раз -- на примере системы ALT Education ничего такого особенного apt-get dist-upgrade не предлагает снести.

Так что надежды на тестирование теми, у кого получается вопроизвести пример, когда были проблемы.
Comment 61 Sergey Y. Afonin 2019-05-23 11:44:28 MSK
(In reply to comment #60)

> Я, когда этот bug report появился, пробовал и сейчас ещё раз -- на примере
> системы ALT Education ничего такого особенного apt-get dist-upgrade не
> предлагает снести.

На самом деле беда другая: просто не обновляет то, что надо обновить, так как пакеты из Sisyphus копируются посредством rebuild и получают более новую дату, чем в Sisyphus, при том же значении EVR. В итоге после dist-upgrade в системе остаётся множество пакетов, собранных с библиотеками из p8. Ну а вынос большого количества пакетов - это частный случай проявления.
Comment 62 Ivan Zakharyaschev 2019-05-23 13:23:41 MSK
(In reply to comment #61)
> (In reply to comment #60)
> 
> > Я, когда этот bug report появился, пробовал и сейчас ещё раз -- на примере
> > системы ALT Education ничего такого особенного apt-get dist-upgrade не
> > предлагает снести.
> 
> На самом деле беда другая: просто не обновляет то, что надо обновить, так как
> пакеты из Sisyphus копируются посредством rebuild и получают более новую дату,
> чем в Sisyphus, при том же значении EVR. В итоге после dist-upgrade в системе
> остаётся множество пакетов, собранных с библиотеками из p8. Ну а вынос большого
> количества пакетов - это частный случай проявления.

Эта беда, насколько я понял из своих проверок вчера, решается.

Например, в моей системе на основе p8 после установки apt из задания для p8 после переключения на Sisyphus предлагается обновить пакет update-kernel (пример описанного Вами случая). В моей системе других таких пересобранных без смены релиза пакетов, похоже, попросту не было.
Comment 63 mikhailnov 2019-05-23 15:00:50 MSK
(В ответ на комментарий №61)
> (In reply to comment #60)
> 
> > Я, когда этот bug report появился, пробовал и сейчас ещё раз -- на примере
> > системы ALT Education ничего такого особенного apt-get dist-upgrade не
> > предлагает снести.
> 
> На самом деле беда другая: просто не обновляет то, что надо обновить, так как
> пакеты из Sisyphus копируются посредством rebuild и получают более новую дату,
> чем в Sisyphus, при том же значении EVR. В итоге после dist-upgrade в системе
> остаётся множество пакетов, собранных с библиотеками из p8. Ну а вынос большого
> количества пакетов - это частный случай проявления.

А почему в Альте %EVR, а не %EVRD? Можно сделать D (distribution), если он отсутствует, то считать за ноль, грубо говоря, а приоритетным считать пакет, у которого есть D. 's' как раз больше p, поэтому без доп. хаков sisyphus будет выше pN.
Comment 64 Ivan Zakharyaschev 2019-05-23 16:27:55 MSK
(In reply to comment #63)
> (В ответ на комментарий №61)
> > (In reply to comment #60)
> > 
> > > Я, когда этот bug report появился, пробовал и сейчас ещё раз -- на примере
> > > системы ALT Education ничего такого особенного apt-get dist-upgrade не
> > > предлагает снести.
> > 
> > На самом деле беда другая: просто не обновляет то, что надо обновить, так как
> > пакеты из Sisyphus копируются посредством rebuild и получают более новую дату,
> > чем в Sisyphus, при том же значении EVR. В итоге после dist-upgrade в системе
> > остаётся множество пакетов, собранных с библиотеками из p8. Ну а вынос большого
> > количества пакетов - это частный случай проявления.
> 
> А почему в Альте %EVR, а не %EVRD? Можно сделать D (distribution), если он
> отсутствует, то считать за ноль, грубо говоря, а приоритетным считать пакет, у
> которого есть D. 's' как раз больше p, поэтому без доп. хаков sisyphus будет
> выше pN.

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

Предлагаемые для тестирования задания -- завершающий этап в этом деле.
Comment 65 Ivan Zakharyaschev 2019-05-23 16:35:21 MSK
(In reply to comment #63)
> (В ответ на комментарий №61)
> > (In reply to comment #60)
> > 
> > > Я, когда этот bug report появился, пробовал и сейчас ещё раз -- на примере
> > > системы ALT Education ничего такого особенного apt-get dist-upgrade не
> > > предлагает снести.
> > 
> > На самом деле беда другая: просто не обновляет то, что надо обновить, так как
> > пакеты из Sisyphus копируются посредством rebuild и получают более новую дату,
> > чем в Sisyphus, при том же значении EVR. В итоге после dist-upgrade в системе
> > остаётся множество пакетов, собранных с библиотеками из p8. Ну а вынос большого
> > количества пакетов - это частный случай проявления.
> 
> А почему в Альте %EVR, а не %EVRD? Можно сделать D (distribution), если он
> отсутствует, то считать за ноль, грубо говоря, а приоритетным считать пакет, у
> которого есть D. 's' как раз больше p, поэтому без доп. хаков sisyphus будет
> выше pN.

Без лишних хаков просто сравнивать эти строки нельзя. Изначально разделители в строке %EVR такие: E:V-R; сравнивать надо покомпонентно.

Теперь в APT необходимая для определения направления обновления информация будет  представлена строками формата E:V-R:D@T (D -- disttag, T -- buildtime).

Обучить новым разделителям надо.

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

Так что без хаков такое поведение не получишь.

Можно релизы специальным образом формировать с похожим эффектом (но не %EVR, а просто Release) -- таков был подход %ubt.
Comment 66 mikhailnov 2019-05-23 17:01:31 MSK
(В ответ на комментарий №65) 
> Немного странно в Вашем предложении ссылаться на макросы (к ним не обращаются
> при определения направления обновления; хотя набор важных для этого значений
> изначально был таков), но мы такую вещь по сути и реализуем, если я Вас
> правильно понял.
Я имел в виду RPMTAG_DISTEPOCH, в Альте такого нет
Comment 67 Ivan Zakharyaschev 2019-05-23 17:08:24 MSK
(In reply to comment #66)
> (В ответ на комментарий №65) 
> > Немного странно в Вашем предложении ссылаться на макросы (к ним не обращаются
> > при определения направления обновления; хотя набор важных для этого значений
> > изначально был таков), но мы такую вещь по сути и реализуем, если я Вас
> > правильно понял.
> Я имел в виду RPMTAG_DISTEPOCH, в Альте такого нет

Мы стали использовать RPMTAG_DISTTAG
Comment 68 Anton Farygin 2019-05-24 16:16:28 MSK
С rpm+apt из задания 229746 обновление с p8 до Sisyphus проходит почти гладко (удаляется 22 пакета и там надо смотреть причину удаления по каждому из них).

update-kernel поломатый - всегда хочет обновлять ядра.

Теперь ждём apt+rpm для Sisyphus.
Comment 69 Ivan Zakharyaschev 2019-05-24 20:14:52 MSK
(In reply to comment #68)
> С rpm+apt из задания 229746 обновление с p8 до Sisyphus проходит почти гладко
> (удаляется 22 пакета и там надо смотреть причину удаления по каждому из них).
> 
> update-kernel поломатый - всегда хочет обновлять ядра.

Планируется доделать rpm и это должно уйти.

Вот у меня задание 229527 не со всеми фичами в apt (disttag-и не сравнивает), промежуточное для тестирования нового подхода. Заодно я туда поместил сейчас rpm.

Предположение касательно проблемы с update-kernel такое:

Если установить только apt из 229527 в Sisyphus, то проблема  update-kernel воспроизведётся в Sisyphus.

Если установить ещё и rpm 229527, то проблема уйдёт, потому что rpm -q будет вопринимать строки вида kernel-image-std-def-4.9.177-alt0.M80P.1@1558091468

> Теперь ждём apt+rpm для Sisyphus.
Comment 70 Ivan Zakharyaschev 2019-05-27 19:29:51 MSK
(In reply to comment #58)
> Ждём сборки задания для Sisyphus. Пока что оно упало с ошибкой. Как соберётся -
> напиши пожалуйста.

Собралось 229767
Comment 71 Ivan Zakharyaschev 2019-05-28 11:00:43 MSK
Для Sisyphus нашёл проблему, сделал другое задание:

230598
Comment 72 Anton Farygin 2019-05-31 11:22:26 MSK
С apt+rpm из задания 229746 p8 до Sisyphus обновляется более-менее корректно (удаляется только kdeenlive из нужного).


Но я проверял только один сценарий обновления.
Comment 73 AEN 2019-05-31 12:38:13 MSK
(В ответ на комментарий №72)
> С apt+rpm из задания 229746 p8 до Sisyphus обновляется более-менее корректно
> (удаляется только kdeenlive из нужного).
> 
> 
> Но я проверял только один сценарий обновления.

Будем надеяться. :)
Comment 74 ildar 2019-06-03 13:55:05 MSK
(In reply to comment #71)
> Для Sisyphus нашёл проблему, сделал другое задание:
> 
> 230598

на этом апте проапгрейдился с p8 до Sisyphus. Успешно.
Но не могу завести hasher, не видит пакета setup. Может кто-нибудь проверить, пожалуйста? Или дайте умный совет, как продиагностировать.
Comment 75 Ivan Zakharyaschev 2019-06-03 14:02:49 MSK
(In reply to comment #74)
> (In reply to comment #71)
> > Для Sisyphus нашёл проблему, сделал другое задание:
> > 
> > 230598
> 
> на этом апте проапгрейдился с p8 до Sisyphus. Успешно.
> Но не могу завести hasher, не видит пакета setup. Может кто-нибудь проверить,
> пожалуйста? Или дайте умный совет, как продиагностировать.

Спасибо за тестирование!

Скажите, что в sources.list для hasher и какой командой запускаете?
Comment 76 ildar 2019-06-03 14:09:48 MSK
(In reply to comment #75)
> Скажите, что в sources.list для hasher и какой командой запускаете?

$ hsh $TMP/hasher ~/Projects/RPM/SRPMS/*rpm
> rpm [alt] http://ftp.altlinux.org/pub/distributions/ALTLinux Sisyphus/x86_64 classic
> rpm [alt] http://ftp.altlinux.org/pub/distributions/ALTLinux Sisyphus/noarch classic

Пробовал ./apt-cache show setup : тишина.
Я так понимаю, что у Вас hasher работает?
Comment 77 Ivan Zakharyaschev 2019-06-03 14:20:42 MSK
(In reply to comment #76)
> (In reply to comment #75)
> > Скажите, что в sources.list для hasher и какой командой запускаете?
> 
> $ hsh $TMP/hasher ~/Projects/RPM/SRPMS/*rpm
> > rpm [alt] http://ftp.altlinux.org/pub/distributions/ALTLinux Sisyphus/x86_64 classic
> > rpm [alt] http://ftp.altlinux.org/pub/distributions/ALTLinux Sisyphus/noarch classic
> 
> Пробовал ./apt-cache show setup : тишина.
> Я так понимаю, что у Вас hasher работает?

Может, не в точности на этой сборке, но на похожей вроде работало.

Попробуйте $TMP/hasher/aptbox/apt-get update
Comment 78 Ivan Zakharyaschev 2019-06-03 14:40:21 MSK
(In reply to comment #76)
> (In reply to comment #75)
> > Скажите, что в sources.list для hasher и какой командой запускаете?
> 
> $ hsh $TMP/hasher ~/Projects/RPM/SRPMS/*rpm
> > rpm [alt] http://ftp.altlinux.org/pub/distributions/ALTLinux Sisyphus/x86_64 classic
> > rpm [alt] http://ftp.altlinux.org/pub/distributions/ALTLinux Sisyphus/noarch classic
> 
> Пробовал ./apt-cache show setup : тишина.
> Я так понимаю, что у Вас hasher работает?

Перепроверил. Работает с apt и rpm из этого задания.

Правда, у меня sources.list не по http, а file. (Но в этом задании как раз не было ещё изменений в http. Проверю на всякий случай.)
Comment 79 Ivan Zakharyaschev 2019-06-03 14:57:21 MSK
(In reply to comment #78)
> (In reply to comment #76)
> > (In reply to comment #75)
> > > Скажите, что в sources.list для hasher и какой командой запускаете?
> > 
> > $ hsh $TMP/hasher ~/Projects/RPM/SRPMS/*rpm
> > > rpm [alt] http://ftp.altlinux.org/pub/distributions/ALTLinux Sisyphus/x86_64 classic
> > > rpm [alt] http://ftp.altlinux.org/pub/distributions/ALTLinux Sisyphus/noarch classic
> > 
> > Пробовал ./apt-cache show setup : тишина.
> > Я так понимаю, что у Вас hasher работает?
> 
> Перепроверил. Работает с apt и rpm из этого задания.
> 
> Правда, у меня sources.list не по http, а file. (Но в этом задании как раз не
> было ещё изменений в http. Проверю на всякий случай.)

Это у меня так и не вопроизвелось.

Проверьте rpm -q rpm --lastchange, пожалуйста.

И попробуйте $TMP/hasher/aptbox/apt-get update

Какая ещё диагностика может быть полезна?..

$TMP/hasher/aptbox/apt-cache show setup молчит в каком смысле?

Завершается ли (с каким кодом?) или висит? Если висит, то что, например, покажет strace -f -y
$TMP/hasher/aptbox/apt-cache show setup
Comment 80 ildar 2019-06-04 10:04:58 MSK
(In reply to comment #74)
> > 230598
> Но не могу завести hasher, не видит пакета setup. Может кто-нибудь проверить,
> пожалуйста? Или дайте умный совет, как продиагностировать.

Прошу прощения, это локальная проблема: частично обновлённый сизиф. Обновление gpg решило проблему.
Comment 81 Ivan Zakharyaschev 2019-06-05 21:52:36 MSK
Для Sisyphus задание-кандидат на то, чтобы стать окончательным (без учёта проблемы замены симлинков на директории) -- 231427

Можно потестировать обновление, поставив apt из него.
Comment 82 Anton Farygin 2019-06-05 21:55:54 MSK
Вань, я правильно понял что с ним не нужно обновлять p8 до задания с apt/rpm ?
Comment 83 Ivan Zakharyaschev 2019-06-05 22:06:56 MSK
(In reply to comment #82)
> Вань, я правильно понял что с ним не нужно обновлять p8 до задания с apt/rpm ?

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

Правда, проблема с заменой симлинка на директорию вылезет, если использовать rpm-4.13 из Sisyphus.
Comment 84 Anton Farygin 2019-06-05 22:12:13 MSK
А это значит, что обновление у меня не пройдёт.
Предлагаю пропустить этот apt в Sisyphus и исправлять проблему с симлинками.
Comment 85 Ivan Zakharyaschev 2019-06-05 22:16:14 MSK
(In reply to comment #84)
> А это значит, что обновление у меня не пройдёт.
> Предлагаю пропустить этот apt в Sisyphus и исправлять проблему с симлинками.

Я сейчас скоро ещё для p8 сделаю сборку, можно будет тот и этот заодно протестировать.
Comment 86 Anton Farygin 2019-06-05 22:17:43 MSK
Да, давай попробуем rpm из p8 обновиться до Sisyphus.
Comment 87 Ivan Zakharyaschev 2019-06-07 22:01:57 MSK
(In reply to comment #81)
> Для Sisyphus задание-кандидат на то, чтобы стать окончательным (без учёта
> проблемы замены симлинков на директории) -- 231427
> 
> Можно потестировать обновление, поставив apt из него.

Для p8 -- 229746.

Можно потестировать обновление, поставив apt из него.
Comment 88 Ivan Zakharyaschev 2019-06-13 15:01:23 MSK
(In reply to comment #84)
> А это значит, что обновление у меня не пройдёт.
> Предлагаю пропустить этот apt в Sisyphus и исправлять проблему с симлинками.

В Sisyphus сейчас закоммитится.

Для p9 сразу же после этого будет задание (в EPERM) 231608. Можно потестировать обновление с p8 до p9 после установки apt из него.

Для p8 всё так же задание 229746. Можно потестировать обновление с p8 до p9 после установки apt из него. (Оно и симлинк сможет заменить на директорию.)
Comment 89 Ivan Zakharyaschev 2019-06-27 14:26:54 MSK
(In reply to comment #83)

> Правда, проблема с заменой симлинка на директорию вылезет, если использовать
> rpm-4.13 из Sisyphus.

Для обновления gdb в связи с заменой симлинка https://bugzilla.altlinux.org/show_bug.cgi?id=35492 добавлен прескрипт в задании 233277. Это поможет при rpm-4.0.4 (из p8).

Теперь можно попробовать такой сценарий обновления:

* допустим, в системе на p8 установлен gdb в начале обновления (и lua).
* в p8 сделать dist-upgrade
* переключиться на Sisyphus или p9, добавить задание 233277, сделать dist-upgrade
Comment 90 Vitaly Lipatov 2020-01-20 21:19:09 MSK
Возможно, что всё уже решилось?
Comment 91 Anton Farygin 2020-01-21 06:42:18 MSK
теперь сломано обновление с p9 до sisyphus
Comment 92 Vitaly Lipatov 2020-10-21 14:21:10 MSK
(Ответ для Anton Farygin на комментарий #91)
> теперь сломано обновление с p9 до sisyphus

Не подтверждаю... Как раз сейчас обновляю до Сизифа, потом откатываю до p9, потом опять до Сизифа...
Comment 93 Anton Farygin 2020-10-21 14:23:21 MSK
Это зависит от установленных пакетов. Иногда везёт иногда нет.
Ну и если %_priority_distbranch прописывать до обновления, то тоже всё в целом неплохо.
Comment 94 Sergey Y. Afonin 2020-10-21 17:59:22 MSK
(In reply to Anton Farygin from comment #91)

> теперь сломано обновление с p9 до sisyphus

Может это другим багом? В p8 и rpm другой, которым обновление до p9 делается. Вчера и сегодня несколько хостов с p8 до p9 обновил беспроблемно как раз. Без X правда все. Зато один с Апачем и MariaDB.
Comment 95 Anton Farygin 2020-10-21 19:20:12 MSK
Нет, ошибка та же самая и по тем же причинам, просто теперь она в p9 -> sisyphus.
ну и не так кардинально как раньше.

p8 до p9 обновляется при этом хорошо.
Comment 96 Anton Farygin 2023-07-13 14:09:25 MSK
Теперь сломано обновление с p10 до Sisyphus, если установить, например, рабочую станцию 10.1 и попробовать обновить.