Как ты себе представляешь проверку _изменения_ soname в sisyphus_check?

Я представляю, что кто-то из подписчиков баги знает, на какой пакет перевесить при необходимости.

Такая проверка сильно бы улучшила обновление с бранча на бранч.

В качестве побочного эффекта при обновлении будут вылазить ситуации типа:
"file /usr/share/libname/something из пакета libname5 конфликтует с одноименным файлом из libname10", но они легко исправляются и не портят систему.

такую проверку можно сделать в repocop,
добавить патчгенератор-переименовыватель,
а отшивание пакетов заменить repocop NMU 
на эти пакеты.

Думаю, раз есть интерес, то как только разберусь 
с java (там у меня eclipse подвис) попробую 
реализовать в repocop.

(In reply to comment #4)
> такую проверку можно сделать в repocop,
> добавить патчгенератор-переименовыватель,
> а отшивание пакетов заменить repocop NMU 
> на эти пакеты.

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

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

Почему?
Допустим, X выложил icu с подпакетом libicu c so.5 c с другим сонеймом.
repocop:
патч репокопа переименует подпакет libicu в libicu5.
на момент обновления p7->p8 в Сизифе все будет ок, 
обычные пользователи насладятся благами безглючного обновления,
но те (несколько десятков?) пользователей, которые "сидят на сизифе"
могут испытать неудобства при обновлении, но там все сплошь бойцы.
sisyphus_check:
остановит libicu, но в силу design flow (проверки-то не отключаемые)
создаст большие проблемы майнтайнерам во всяких крайних случаях вроде random soname.
Неудачный зажим гаек в sisyphus_check нагружает майнтайнеров дурной работой
и создает недовольство в коллективе, что политически не правильно.
Например, я стал майнтайнером из-за того, как из-за подобного недовольства из team с матами ушел Alex Ott, и бросил Emacs.
А он был бы ему идеальным майнтайнером :(

(In reply to comment #6)
> (В ответ на комментарий №5)
> > Насколько я понимаю, важно именно не допустить неправильных обновлений в
> > будущем, а не переименовывать то, что есть уже сейчас (за редкими исключениями,
> > о которых мы уже давно знаем).  Так что эта проверка должна работать иименно в
> > сборочнице, а не снаружи.
> 
> Почему?
> Допустим, X выложил icu с подпакетом libicu c so.5 c с другим сонеймом.
> repocop:
> патч репокопа переименует подпакет libicu в libicu5.
> на момент обновления p7->p8 в Сизифе все будет ок, 
> обычные пользователи насладятся благами безглючного обновления,
> но те (несколько десятков?) пользователей, которые "сидят на сизифе"
> могут испытать неудобства при обновлении, но там все сплошь бойцы.

Ну да, и остальные проверки на репозиторий тоже перенести в repocop.
Например, зачем нам проверка на анметы, ведь мйнтейнерам так тяжело, поэтому на момент обновления p7->p8 все будет хорошо, а на сизифе с анметами просто никого не останется.  Нет, спасибо, это пройденный этап.

> sisyphus_check:

Ну при чем тут sisyphus_check?  Это такая же примерно проверка, как и проверка на анметы.

> остановит libicu, но в силу design flow (проверки-то не отключаемые)

Проверки в сборочнице настраиваемые.

> создаст большие проблемы майнтайнерам во всяких крайних случаях вроде random
> soname.

У библиотек со случайным soname нет клиентов.  Я не вижу смысла налагать ограничения на библиотеки, у которых не более одного клиента.

(В ответ на комментарий №7)
> Я не вижу смысла налагать ограничения на библиотеки,
> у которых не более одного клиента.
Не более одного клиента из других src.rpm .
Внутри одного src.rpm у меня в подпакетах зачастую дофига клиентов на одну библиотеку.

(В ответ на комментарий №7)
> Ну при чем тут sisyphus_check?
http://lists.altlinux.org/pipermail/devel/2012-November/195849.html
"Shared Libs Policy это действующие правила, для которых еще не написано проверок в sisyphus_check" ;-)

(В ответ на комментарий №6)
> > Так что эта проверка должна работать иименно в
> > сборочнице, а не снаружи.
> Почему?
Потому что, когда уже выложено, исправить сложнее, т.к. добавляется необходимость исправления уже испорченного.

(В ответ на комментарий №10)
> Потому что, когда уже выложено, исправить сложнее
Я не совсем понял, видимо. Лишь бы не попадало в репозитории до исправления.

(В ответ на комментарий №4)
> Думаю, раз есть интерес, то как только разберусь 
> с java (там у меня eclipse подвис) попробую 
> реализовать в repocop.
Слыхать что-нибудь?

Профит http://www.altlinux.org/Shared_Libs_Policy_and_updates

(В ответ на комментарий №12)
> (В ответ на комментарий №4)
> > Думаю, раз есть интерес, то как только разберусь 
> > с java (там у меня eclipse подвис) попробую 
> > реализовать в repocop.
> Слыхать что-нибудь?

Прошу прощения, у меня еще руки до репокопа не дошли.

(В ответ на комментарий №14)
> (В ответ на комментарий №12)
> > (В ответ на комментарий №4)
> > > Думаю, раз есть интерес, то как только разберусь 
> > > с java (там у меня eclipse подвис) попробую 
> > > реализовать в repocop.
> > Слыхать что-нибудь?
> 
> Прошу прощения, у меня еще руки до репокопа не дошли.

Хорошо бы они дошли скорее.

Репокопа уже мало. Нужно на этапе сборки отсекать серпом по таким пакетам.

Или более простой и менее хороший вариант: отшивать, если в репозитории среди провайдов уже имеется один из SONAME-ов, но в пакете с _другим_ именем.

Еще вариант простой проверки:
Если в пакете имеется библиотека с SONAME, то имя пакета должно оканчиваться на этот самый SONAME.

Проверку проводить для каждой из библиотек, содержащихся в пакете.

(В ответ на комментарий №18)
> имя пакета должно оканчиваться на этот самый SONAME.
Точнее, на версионное окончание этого SONAME.

Для начала можно проверять не конец имени пакета а любое положение в имени.

(В ответ на комментарий №20)
> Для начала можно проверять не конец имени пакета а любое положение в имени.
Тогда можно будет не менять пакеты типа libkf5kiocore .

Из-за костыля http://git.altlinux.org/gears/a/apt.git?p=apt.git;a=commit;h=e2184306b28908f208869b791d1bb0550c659674 dist-upgrade периодически сносит кучи пакетов.

(Ответ для Sergey V Turchin на комментарий #22)
> Из-за костыля сносит
Это оказалось ложным, погорячился.