2aris: прошу исправить asap.

Я уже исправил неверное наименование пакетов. Какие претензии к ним по существу?
Что-то сломалось, не обновляется etc?

(В ответ на комментарий №2)
> Какие претензии к ним по существу?
https://www.altlinux.org/Shared_Libs_Policy_and_updates
Из-за подобных действий люди сразу или бомбой замедленного действия огребают проблемы.

Соблюдайте https://www.altlinux.org/Shared_Libs_Policy

(В ответ на комментарий №3)
> (В ответ на комментарий №2)
> > Какие претензии к ним по существу?
> https://www.altlinux.org/Shared_Libs_Policy_and_updates
> Из-за подобных действий люди сразу или бомбой замедленного действия огребают
> проблемы.

Поскольку сонейм не сменился, проблем в принципе не может быть.

> Соблюдайте https://www.altlinux.org/Shared_Libs_Policy

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

(В ответ на комментарий №2)
> Я уже исправил неверное наименование пакетов. Какие претензии к ним по
> существу?
https://lists.altlinux.org/pipermail/sisyphus/2018-March/366580.html
https://lists.altlinux.org/pipermail/sisyphus/2018-March/366586.html

P.S.
Архив к сожалению сломан. По ссылкам на Предыдущее/Следующее сообщение неправильно перемещается.

Юра, присоединяюсь к просьбе - совсем недавно получил проблемы обновления P8-Sisyphus из-за libva без версионирования.

переоткрываю.

Там, где есть возможность - надо собирать новую библиотеку в соответствии с shared libs policy

(В ответ на комментарий №7)
> переоткрываю.
> 
> Там, где есть возможность 

Там, где есть необходимость.  В данном случае такой необходимости нет.
Аргументированно докажите обратное.

(В ответ на комментарий №8)
> (В ответ на комментарий №7)
> > переоткрываю.
> > 
> > Там, где есть возможность 
> 
> Там, где есть необходимость.  В данном случае такой необходимости нет.
> Аргументированно докажите обратное.

Ссылки на проблемы здесь были. 
Возможно, стоит их подробнее описать в devel@ и там обсудить необходимость следования shared lib policy. Если тут не получается придти к согласию, то стоит обсудить в Тим.

(В ответ на комментарий №9)
> (В ответ на комментарий №8)
> > (В ответ на комментарий №7)
> > > переоткрываю.
> > > 
> > > Там, где есть возможность 
> > 
> > Там, где есть необходимость.  В данном случае такой необходимости нет.
> > Аргументированно докажите обратное.
> 
> Ссылки на проблемы здесь были. 

Ссылки на проблемы с другими пакетами не являются доказательством необходимости применения shared lib policy в данном конкретном случае. Повторюсь, у библиотеки не сменился сонейм, и эта бага ни о чем.

> Возможно, стоит их подробнее описать в devel@ и там обсудить необходимость
> следования shared lib policy. Если тут не получается придти к согласию, то
> стоит обсудить в Тим.

Да-да, решите "по возможности" или "по необходимости" следует применять эти правила,
точно определив критерии того и/или другого.

Вопрос не в том, что пакет с библиотекой переименовался, а в том, что он переименовался так, что дальше явно не будет следовать shared libs policy.

К сожалению, я раньше точно так же делал, пока не нарвался на ffmpeg.
если в системе есть хоть один пакет, который по каким-то причинам не обновляется (например, удалён из Sisyphus) и этот пакет зависит на обновляемую библиотеку, собранную как одно имя (без циферок), то apt вместо удаления этого странного пакета сносит всех клиентов новой библиотеки.

Почему-то он считает что у установленных пакетов приоритет выше. Со всеми вытекающими последствиями.

(В ответ на комментарий №11)
> Вопрос не в том, что пакет с библиотекой переименовался, а в том, что он
> переименовался так, что дальше явно не будет следовать shared libs policy.
> 
> К сожалению, я раньше точно так же делал, пока не нарвался на ffmpeg.
> если в системе есть хоть один пакет, который по каким-то причинам не
> обновляется (например, удалён из Sisyphus) и этот пакет зависит на обновляемую
> библиотеку, собранную как одно имя (без циферок), то apt вместо удаления этого
> странного пакета сносит всех клиентов новой библиотеки.
> 
> Почему-то он считает что у установленных пакетов приоритет выше. Со всеми
> вытекающими последствиями.
Это известная багофича апта. А как же её решит добавление цифры — только тем, что это будет новый пакет?

Да, тем что это будет новый пакет. Старый при этом останется в системе установлен.

Всё ещё забавнее когда есть некая библиотека (допустим lib1.so.1) и она собрана с другой библиотекой (lib2.so.2), а та собрана с третьей библиотекой (lib3.so.3)
если хоть одна из них не будет следовать shared libs policy (т.е. - паковаться каждый раз в новый пакет с другим именем), то это гарантированно заморозит обновление всей системы если есть какой-то установленный пакет, который хочет любую из этих библиотек старой версии.

Именно на это я нарвался с libva, в sisyphus пришлось собрать compat пакет, что бы он обновился, т.к. библиотеки, с которой была собрана предыдущая версия - уже не существует (удалена), а старый libva её хотел.
Пришлось его (старый libva) пересобрать в новом окружении без devel пакета, что бы с p8 до Sisyphus было корректное обновление.

А вот сам libva плохо пакуется в соответствии с shared libs policy, т.к. для его корректной работы требуются плагины а они пока что могут быть только одной версии.

Может быть, нам нужна бага на apt про такое его поведение.  Наверняка всё же приоритет установленных (и не могущих обновиться) пакетов можно и поменять.

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

(В ответ на комментарий №11)
> Почему-то он считает что у установленных пакетов приоритет выше. Со всеми
> вытекающими последствиями.
Боюсь, это последствия anti-aris.patch для apt! 8-O

(В ответ на комментарий №17)
> Боюсь, это последствия anti-aris.patch для apt! 8-O
Вроде оно
http://git.altlinux.org/gears/a/apt.git?p=apt.git;a=commitdiff;h=e2184306b28908f208869b791d1bb0550c659674