SONAME libbrotlidec.so.1 убежал из пакета libbrotlidec0 в пакет libbrotlidec, а не в libbrotlidec1.
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
