Bug 35529 - кардинально сломано обновление с p8 до sisyphus
: кардинально сломано обновление с p8 до sisyphus
Status: REOPENED
: Sisyphus
(All bugs in Sisyphus/rpm)
: unstable
: all Linux
: P3 major
Assigned To:
:
:
:
: 35737
: 34231
  Show dependency tree
 
Reported: 2018-10-19 12:13 by
Modified: 2019-04-09 08:09 (History)


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


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2018-10-19 12:13:59
Новый конфиг /etc/apt/preferences не приезжает ни с каким пакетом, обновляться
пакеты с одинаковыми версиями естественно не хотят.

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

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

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

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

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

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

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

Следующие пакеты будут ЗАМЕНЕНЫ БОЛЕЕ СТАРЫМИ ВЕРСИЯМИ:
  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 From 2018-10-19 14:32:59 -------
(In reply to comment #5)
> Заработало оно правда тоже весьма странно:
> 
> Следующие пакеты будут ЗАМЕНЕНЫ БОЛЕЕ СТАРЫМИ ВЕРСИЯМИ:

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

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

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

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

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

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

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

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

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

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

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

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

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

Не знаю.

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

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

# cat /etc/apt/preferences
Package: *
Pin: release l=Sisyphus
Pin-Priority: 1001
------- Comment #16 From 2018-12-12 14:54:09 -------
(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 From 2018-12-18 09:16:46 -------
(In reply to comment #16)

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

Может сама идея делать rebuild при копировании неудачная, а удобство сборки в
разные бранчи, таким образом полученное, не стоит последствий? Или уж не знаю,
может как-то автоматом время сборки в более новых бранчах повышать при таком
процессе, хоть тем же rebuild. Но тут вопрос, справится ли борочница.
------- Comment #18 From 2018-12-18 09:27:43 -------
Это не поможет. Нужно учитывать тэг дистрибутива в сравнении версий, если я
правильно помню - этот вопрос поднимался в 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 From 2018-12-18 09:34:09 -------
(In reply to comment #18)
[...]
> Наверное, это можно было бы сделать, есть бы в RPMTAG_DISTTAG писался тэг, по
> имени которого можно проводить какое-то сравнение. Но там сейчас какая-то
> странная информация, не несущая никакой пользы для исправления этой ошибки:
[...]

Отчего же?

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

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

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

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

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

Поэтому правильнее было бы сразу ставить тэг следующего бранча в sisyphus.
Но что делать с сертифицированными ветками всё равно не очень понятно.
------- Comment #25 From 2018-12-18 10:42:33 -------
(В ответ на комментарий №21)
> И да, у нас есть ещё ветки c и (возможно) t.
> $ rpmvercmp p8 c8
Если сейчас неправильное поведение, значит нужно исправить наименование.
------- Comment #26 From 2018-12-20 10:23:53 -------
Created an attachment (id=7911) [details]
Расцветка синтаксиса Midnight Commander
------- Comment #27 From 2018-12-20 10:26:09 -------
Ой, вроде, новую создавал. Что-то пошло не так, прошу прощения.
------- Comment #28 From 2018-12-20 15:41:19 -------
(From update of attachment 7911 [details])
Это в bug 35799
------- Comment #29 From 2018-12-20 15:43:18 -------
(From update of attachment 7911 [details])
.
------- Comment #30 From 2018-12-21 19:27:52 -------
(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 From 2018-12-21 19:41:45 -------
Ну да, во первых непонятно как будут сравниваться самосборные пакеты.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Когда ожидать починки rpm в p8 ?
------- Comment #37 From 2019-02-15 08:07:34 -------
*** Bug 36109 has been marked as a duplicate of this bug. ***
------- Comment #38 From 2019-02-26 16:54:54 -------
На данный момент обновление с p8 до Sisyphus работает, удаляется совсем чуть
чуть и по причинам, не связанным с rpm.
------- Comment #39 From 2019-02-26 16:55:38 -------
Ура!
Спасибо!
------- Comment #40 From 2019-03-01 12:27:13 -------
прошу прощения, был не прав - лучше не стало.
------- Comment #41 From 2019-03-01 12:47:30 -------
(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 From 2019-03-01 13:31:56 -------
Да, стандартная схема обновления - обновиться полностью до бранча (включая
rpm), потом обновить до Sisyphus.

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

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

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

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

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

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

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

Не знаю. Там сначала какие-то файловые конфликты упомянуты, а их apt не видит.
------- Comment #47 From 2019-03-01 13:53:11 -------
(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 From 2019-03-01 13:55:50 -------
Из какого задания ? Давай я попробую.

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

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

Возможно, недоработка в обработке Obsoletes. Может касаться и rpm, и apt.
Интересный test case.