Более того - мои попытки придумать /etc/apt/preferences ни к чему не привели - обновления по прежнему не работают. Ну или нужен какой-то пример.

Что писать в Pin: release l= ???

Кому не блокер, а мне так срочно прямо сейчас нужно обновиться.

$ cat /etc/apt/preferences
Package: *
Pin: release l=Sisyphus
Pin-Priority: 700

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

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

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

Спасибо заранее.

поднятие Pin-priority до значения больше 1000 помогает запустить процесс обновления.

нужно конфиг по умолчанию.

Заработало оно правда тоже весьма странно:

Следующие пакеты будут ЗАМЕНЕНЫ БОЛЕЕ СТАРЫМИ ВЕРСИЯМИ:
  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

(In reply to comment #5)
> Заработало оно правда тоже весьма странно:
> 
> Следующие пакеты будут ЗАМЕНЕНЫ БОЛЕЕ СТАРЫМИ ВЕРСИЯМИ:

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

Пожалуйста, предлагайте более удачные формулировки и/или идеи.

Я понимаю почему это происходит.

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

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

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

(В ответ на комментарий №7)
> Если дату сборки убрать из алгоритма вычисления возраста пакетов
Не-не! Убирать не надо. Я постоянно пользуюсь.
Надо инфу про бранч сделать более приоритетной.

Нет, ты не понял. Убрать надо только из алгоритма сравнения при pin-priority < 1000 (если такое возможно)

Впрочем, я уже сказал. пусть ldv голову ломает, он себя умнее всех окружающсчитает.

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

О такое поведении можно задокументировать в вики, оповестить в списке рассылки и описать в особенностях в QA на wiki.

Можно, и нужно, но врятли это поможет - большое количество людей просто не пойдут искать информацию, почему у них массово доунгрейдятся пакеты при обновлении дистрибутива.

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

Чем он хуже Sisyphus ?

Еще попробуйте поиграться c dist-upgrade c p8 до sisyphus, а потом обратно, а потом опять.

(In reply to comment #11)
> Можно, и нужно, но врятли это поможет - большое количество людей просто не
> пойдут искать информацию, почему у них массово доунгрейдятся пакеты при
> обновлении дистрибутива.

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

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

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

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

Не знаю.

Тем временем: #216554 — apt-conf-branch для p8, #215590 — apt-conf-sisyphus.

(В ответ на комментарий №13)
> (In reply to comment #11)
> 
> > И почему это не будет происходить при любом обновлении на новый бранч, вышедший
> > на новом Sisyphus?
> 
> Потому что предыдущий бранч будет поддерживаться только в течении относительно
> небольшого времени, и вероятно поддержка будет касаться только исправления
> критических проблем и закрытия уязвимостей. Следовательно, новые релизы будут
> собираться и бекпортироваться значительно реже.

Да, но их уже набэкпортировано и собрано достаточно, что бы при обновлении с p8 на тот Sisyphus, который станет p9 - вылезло такое сообщение.

Вот с таким конфигом обновляется. Когда ждать правильный preferences в пакете ?

# cat /etc/apt/preferences
Package: *
Pin: release l=Sisyphus
Pin-Priority: 1001

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

По видимому, идея использовать механизм apt_preferences неудачная. Помимо смущающего сообщения про DOWNGRADE ещё проявляется куча проблем, такие как, например, "обновление" пакета, собранного локально, пакетов из репозитория, проблема из #35737 и др.. Прорабатываем новый механизм сравнения версий rpm-пакетов.

(In reply to comment #16)

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

Может сама идея делать rebuild при копировании неудачная, а удобство сборки в разные бранчи, таким образом полученное, не стоит последствий? Или уж не знаю, может как-то автоматом время сборки в более новых бранчах повышать при таком процессе, хоть тем же rebuild. Но тут вопрос, справится ли борочница.

Это не поможет. Нужно учитывать тэг дистрибутива в сравнении версий, если я правильно помню - этот вопрос поднимался в 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)), которую не забывать увеличивать для каждой новой ветви - то её можно было бы использовать в сравнении версии.

(In reply to comment #18)
[...]
> Наверное, это можно было бы сделать, есть бы в RPMTAG_DISTTAG писался тэг, по
> имени которого можно проводить какое-то сравнение. Но там сейчас какая-то
> странная информация, не несущая никакой пользы для исправления этой ошибки:
[...]

Отчего же?

$ rpmevrcmp p8.216685.100 sisyphus.216505.700
-3

Оттого, что придётся проводить пересборку всех пакетов в момент выпуска нового бранча.

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

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

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

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

Переход между разными ветками с одной цифрой -- это другой вопрос. Он вообще когда-нибудь поддерживался?

Пересборку ? да не для обновления конечно. 
У нас и сейчас в новой схеме нет возможности каким-то образом идентифицировать, для какого бранча был собран тот или иной пакет, а с DISTTAG это станет ещё тяжелее.

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

Но после пересборки произойдёт изменение тэга DISTTAG и де-факто - его уменьшение.
Т.е. - те, у кого пакет был установлен с DISTTAG в sisyphus не смогут обновиться.

Поэтому правильнее было бы сразу ставить тэг следующего бранча в sisyphus.
Но что делать с сертифицированными ветками всё равно не очень понятно.

(В ответ на комментарий №21)
> И да, у нас есть ещё ветки c и (возможно) t.
> $ rpmvercmp p8 c8
Если сейчас неправильное поведение, значит нужно исправить наименование.

Created attachment 7911 [details]
Расцветка синтаксиса Midnight Commander

Ой, вроде, новую создавал. Что-то пошло не так, прошу прощения.

Comment on attachment 7911 [details]
Расцветка синтаксиса Midnight Commander

Это в bug 35799

Comment on attachment 7911 [details]
Расцветка синтаксиса Midnight Commander

.

(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.

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

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

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

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

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

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

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

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

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

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

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

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

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

На межподпакетные в итоге никак, а на межпакетные — таким образом, как это описано алгоритмом.

Я из этого описание не понял.
Вообще, наверное было бы здорово дать возможность локально собирать пакеты с такими же межпакетными зависимостями и таким же DISTTAG, как и в репозитории.
Иначе происходит странное - пересборка hasher'ом пакета из p8 в среде p8 меняет его зависимости.

(In reply to comment #33)
> Я из этого описание не понял.
> Вообще, наверное было бы здорово дать возможность локально собирать пакеты с
> такими же межпакетными зависимостями и таким же DISTTAG, как и в репозитории.
> Иначе происходит странное - пересборка hasher'ом пакета из p8 в среде p8 меняет
> его зависимости.

Можно в сборочной среде выставить значение переменной окружения RPM_STRICT_INTERDEPS. Пока вручную. Потом не надо будет: от неё я планирую избавиться в пользу значения тега disttag.

улучшений пока не заметно.
Ждём изменений в apt и rpm

вчера с p8 до sisyphus не смог обновиться и с rpm из таска (который поддерживает новые виды зависимостей) и с preferences одновременно. - удалялась вся графическая подсистема.

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

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

Когда ожидать починки rpm в p8 ?

*** Bug 36109 has been marked as a duplicate of this bug. ***

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

Ура!
Спасибо!

прошу прощения, был не прав - лучше не стало.

(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 можно было.)

Да, стандартная схема обновления - обновиться полностью до бранча (включая rpm), потом обновить до Sisyphus.

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

Обновил до p8
перенастроил apt на Sisyphus.
apt-get install apt - обновился apt+rpm и удалился apt-indicator.

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

Странно, вроде как если apt и rpm из Sisyphus, то всё должно начать работать нормально ? нет ?

Мне кажется, что это проблема в https://bugzilla.altlinux.org/show_bug.cgi?id=36197

(In reply to comment #42)
> Да, стандартная схема обновления - обновиться полностью до бранча (включая
> rpm), потом обновить до Sisyphus.

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

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

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

Т.е. сейчас нельзя совместить эти два теста, примерно прикинуть, какие будут проблемы при обновлении внутри бранча. (Точнее и так понятно, что большие, если представить себе, что Sisyphus -- это примерно состояние бранча.)

(In reply to comment #44)
> Мне кажется, что это проблема в
> https://bugzilla.altlinux.org/show_bug.cgi?id=36197

Не знаю. Там сначала какие-то файловые конфликты упомянуты, а их apt не видит.

(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 из задания).

Из какого задания ? Давай я попробую.

Там файловые конфликты потому, что apt не справился с переездом библиотеки из libGL в libGLX-mesa. ему надо было просчитать, что libGLX-mesa надо тоже обновлять.

Поставил apt из задания 223177 - ничего не изменилось.
Проблема где-то в libGL, т.к. apt её хочет оставить (kept back), а это приводит явно к удалению всего, что от неё зависит.

(In reply to comment #48)
> Из какого задания ? Давай я попробую.
> 
> Там файловые конфликты потому, что apt не справился с переездом библиотеки из
> libGL в libGLX-mesa. ему надо было просчитать, что libGLX-mesa надо тоже
> обновлять.

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

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

*** Bug 36711 has been marked as a duplicate of this bug. ***

Хочется проверить с

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

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

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

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

Т.е.:
- устанавливаем рабочую станцию 8.2
- обновляем её до p8 + задание 229746
- sources.list меняем на Sisyphus + задание 229746
- устанаваливаем apt + rpm из Sisyphus + задание 229746
- обновляем всё остальное.

Для Sisyphus то какое задание ?

(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, но было и
> предположение, что это не важно.)

(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-скриптам, если они написаны правильно.

Оба варианта эксперимента, конечно, показательны.

Важно проверить сценарий обновление дистрибутива до p8 + задание с apt/rpm, минуя точечное обновление до apt+rpm из задания.

Ждём сборки задания для Sisyphus. Пока что оно упало с ошибкой. Как соберётся - напиши пожалуйста.

(In reply to comment #58)
> Ждём сборки задания для Sisyphus. Пока что оно упало с ошибкой. Как соберётся -
> напиши пожалуйста.

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

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

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

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

Алгоритм работы для p8 реализован такой же, как и для Sisyphus, поэтому необходимости использовать именно rpm и apt из Sisyphus не должно быть.

(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 не предлагает снести.

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

(In reply to comment #60)

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

На самом деле беда другая: просто не обновляет то, что надо обновить, так как пакеты из Sisyphus копируются посредством rebuild и получают более новую дату, чем в Sisyphus, при том же значении EVR. В итоге после dist-upgrade в системе остаётся множество пакетов, собранных с библиотеками из p8. Ну а вынос большого количества пакетов - это частный случай проявления.

(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 (пример описанного Вами случая). В моей системе других таких пересобранных без смены релиза пакетов, похоже, попросту не было.

(В ответ на комментарий №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.

(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.

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

Предлагаемые для тестирования задания -- завершающий этап в этом деле.

(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.

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

(In reply to comment #66)
> (В ответ на комментарий №65) 
> > Немного странно в Вашем предложении ссылаться на макросы (к ним не обращаются
> > при определения направления обновления; хотя набор важных для этого значений
> > изначально был таков), но мы такую вещь по сути и реализуем, если я Вас
> > правильно понял.
> Я имел в виду RPMTAG_DISTEPOCH, в Альте такого нет

Мы стали использовать RPMTAG_DISTTAG

С rpm+apt из задания 229746 обновление с p8 до Sisyphus проходит почти гладко (удаляется 22 пакета и там надо смотреть причину удаления по каждому из них).

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

Теперь ждём apt+rpm для Sisyphus.

(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.

(In reply to comment #58)
> Ждём сборки задания для Sisyphus. Пока что оно упало с ошибкой. Как соберётся -
> напиши пожалуйста.

Собралось 229767

Для Sisyphus нашёл проблему, сделал другое задание:

230598

С apt+rpm из задания 229746 p8 до Sisyphus обновляется более-менее корректно (удаляется только kdeenlive из нужного).


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

(В ответ на комментарий №72)
> С apt+rpm из задания 229746 p8 до Sisyphus обновляется более-менее корректно
> (удаляется только kdeenlive из нужного).
> 
> 
> Но я проверял только один сценарий обновления.

Будем надеяться. :)

(In reply to comment #71)
> Для Sisyphus нашёл проблему, сделал другое задание:
> 
> 230598

на этом апте проапгрейдился с p8 до Sisyphus. Успешно.
Но не могу завести hasher, не видит пакета setup. Может кто-нибудь проверить, пожалуйста? Или дайте умный совет, как продиагностировать.

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

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

Скажите, что в sources.list для hasher и какой командой запускаете?

(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 работает?

(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

(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. Проверю на всякий случай.)

(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

(In reply to comment #74)
> > 230598
> Но не могу завести hasher, не видит пакета setup. Может кто-нибудь проверить,
> пожалуйста? Или дайте умный совет, как продиагностировать.

Прошу прощения, это локальная проблема: частично обновлённый сизиф. Обновление gpg решило проблему.

Для Sisyphus задание-кандидат на то, чтобы стать окончательным (без учёта проблемы замены симлинков на директории) -- 231427

Можно потестировать обновление, поставив apt из него.

Вань, я правильно понял что с ним не нужно обновлять p8 до задания с apt/rpm ?

(In reply to comment #82)
> Вань, я правильно понял что с ним не нужно обновлять p8 до задания с apt/rpm ?

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

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

А это значит, что обновление у меня не пройдёт.
Предлагаю пропустить этот apt в Sisyphus и исправлять проблему с симлинками.

(In reply to comment #84)
> А это значит, что обновление у меня не пройдёт.
> Предлагаю пропустить этот apt в Sisyphus и исправлять проблему с симлинками.

Я сейчас скоро ещё для p8 сделаю сборку, можно будет тот и этот заодно протестировать.

Да, давай попробуем rpm из p8 обновиться до Sisyphus.

(In reply to comment #81)
> Для Sisyphus задание-кандидат на то, чтобы стать окончательным (без учёта
> проблемы замены симлинков на директории) -- 231427
> 
> Можно потестировать обновление, поставив apt из него.

Для p8 -- 229746.

Можно потестировать обновление, поставив apt из него.

(In reply to comment #84)
> А это значит, что обновление у меня не пройдёт.
> Предлагаю пропустить этот apt в Sisyphus и исправлять проблему с симлинками.

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

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

Для p8 всё так же задание 229746. Можно потестировать обновление с p8 до p9 после установки apt из него. (Оно и симлинк сможет заменить на директорию.)

(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

Возможно, что всё уже решилось?

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

(Ответ для Anton Farygin на комментарий #91)
> теперь сломано обновление с p9 до sisyphus

Не подтверждаю... Как раз сейчас обновляю до Сизифа, потом откатываю до p9, потом опять до Сизифа...

Это зависит от установленных пакетов. Иногда везёт иногда нет.
Ну и если %_priority_distbranch прописывать до обновления, то тоже всё в целом неплохо.

(In reply to Anton Farygin from comment #91)

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

Может это другим багом? В p8 и rpm другой, которым обновление до p9 делается. Вчера и сегодня несколько хостов с p8 до p9 обновил беспроблемно как раз. Без X правда все. Зато один с Апачем и MariaDB.

Нет, ошибка та же самая и по тем же причинам, просто теперь она в p9 -> sisyphus.
ну и не так кардинально как раньше.

p8 до p9 обновляется при этом хорошо.

Теперь сломано обновление с p10 до Sisyphus, если установить, например, рабочую станцию 10.1 и попробовать обновить.

(Ответ для Anton Farygin на комментарий #96)
> Теперь сломано обновление с p10 до Sisyphus, если установить, например,
> рабочую станцию 10.1 и попробовать обновить.

Обновление с p10 на Сизиф после бранчевания p11 не поддерживается. Нужно сначала обновиться до p11, а потом до Сизифа. Обновление с p10 до p11 и затем до Сизифа проходит успешно. Считаю проблему решённой.

Теперь надо не забыть переоткрыть как сломается с p11 до sisyphus.