SONAME libexiv2.so.12 убежал из пакета libexiv2 в пакет libexiv2_12
Нетути никакого libexiv2_12.
Повторяется от версии к версии.
(Ответ для Yuri N. Sedunov на комментарий #1) > Нетути никакого libexiv2_12. Нужно перестать паковать разные библиотеки с одним и тем же именем -- libexiv2, тогда и прятать содеянное не придётся.
Я, конечно, напрямую не соприкасался с клиентами libexiv2, но тем не менее, не понимаю, в чём именно проявляется проблема, которую следует устранить. Смею подозревать, что этого не понимаю не только я. Сейчас в Sisyphus только один сонейм libexiv2. После задания 333714 в репозитории тоже будет только один сонейм libexiv2. До и после пакет, в котором находится libexiv2.so.2[78], будет иметь одно и то же имя. Что здесь не так и как это мешает закрытию bug 48097, bug 48415, bug 48416? Кто-нибудь, поясните, пожалуйста, подробнее.
(Ответ для Arseny Maslennikov на комментарий #4) > Сейчас в Sisyphus только один сонейм libexiv2. Поэтому вам кажется, что всё в порядке. > После задания 333714 в репозитории тоже будет только один сонейм libexiv2. Не уверен.
(Ответ для Arseny Maslennikov на комментарий #4) > не понимаю, в чём именно проявляется проблема, которую следует устранить. https://www.altlinux.org/Shared_Libs_Policy_and_updates https://www.altlinux.org/Shared_Libs_Policy
(Ответ для Sergey V Turchin на комментарий #5) > (Ответ для Arseny Maslennikov на комментарий #4) > > Сейчас в Sisyphus только один сонейм libexiv2. > Поэтому вам кажется, что всё в порядке. > > > После задания 333714 в репозитории тоже будет только один сонейм libexiv2. > Не уверен. Давайте конкретно.
(Ответ для AEN на комментарий #7) > > > После задания 333714 в репозитории тоже будет только один сонейм libexiv2. > > Не уверен. > Давайте конкретно. Ждите.
(Ответ для Sergey V Turchin на комментарий #8) > (Ответ для AEN на комментарий #7) > > > > После задания 333714 в репозитории тоже будет только один сонейм libexiv2. > > > Не уверен. > > Давайте конкретно. > Ждите. Сергей, бага должна быть конкретной. Не уверены -- проверьте.
(Ответ для AEN на комментарий #7) > > > После задания 333714 в репозитории тоже будет только один сонейм libexiv2. > > Не уверен. > Давайте конкретно. Оффтопик.
(Ответ для AEN на комментарий #9) > Не уверены -- проверьте. Проверил, удостоверился и создал этот баг. Перебегание SONAME-а в другой пакет без provides/obsoletes является багом без каких-то деталей ещё. Этот баг возникает из-за того, что пакет libexiv2 упакован не в соответствии c https://www.altlinux.org/Shared_Libs_Policy
Поставил блок на #46625 , что позволит избежать дополнительных проблем при обновлении p10 --> p11. https://www.altlinux.org/Shared_Libs_Policy_and_updates
(In reply to AEN from comment #7) > (Ответ для Sergey V Turchin на комментарий #5) > > (Ответ для Arseny Maslennikov на комментарий #4) > > > Сейчас в Sisyphus только один сонейм libexiv2. > > Поэтому вам кажется, что всё в порядке. > > > > > После задания 333714 в репозитории тоже будет только один сонейм libexiv2. > > Не уверен. > > Давайте конкретно. Насколько я понял аргументацию, добавленную в текст /Shared_Libs_Policy между датой, когда я последний раз его читал, и 2023-11-13, а также текст по второй ссылке, основной риск фактически сломать обновление появится в тот момент, когда при обновлении (внутри Sisyphus или между бренчами) зачем-то возникнет необходимость захолдить некоторый пакет-клиент libexiv2, а другой пакет-клиент обновить (на версию, собранную с новым сонеймом). В случае конкретно libexiv2 и её клиентов ситуация, где администратор явно хочет так сделать, представляется мне маловероятной, а пара десятков клиентов являются концевыми узлами графа зависимостей, от них не зависит ничего. Или это не так?
С другой же стороны, от противников перевода libexiv2 на Shared Libs Policy и вообще противников Shared Libs Policy мы вообще никаких аргументов в защиту своей точки зрения не услышали.
(Ответ для Arseny Maslennikov на комментарий #13) > риск фактически сломать обновление Не сломать, а невозможность произвести. Ну и кроме Сизифа и бранчей есть весь остальной мир с пакетами RPM. > появится в тот > момент, когда при обновлении (внутри Sisyphus или между бренчами) зачем-то > возникнет необходимость захолдить Нет. При обновлении с ветки на ветку, когда _без_ холда надо вручную обновить один пакет с некорректными зависомостями, т.к. автоматом apt его он не хочет, из-за этого блокируется всё обновление. Возможно, у вас нет опыта обновления с ветки на ветку.
Это будет кто-то решать? Или главное было хоть как-то обновить, а потом хоть трава не расти?
Я даже больше скажу. Это в p10 надо исправлять на данный момент.
Короче! Даю на размышление неделю. Если движений не будет, исправляю в p10 и буду каждый раз подтирать мантейнеру в каждом новом бранче.
Как вижу, мантейнер не против.
*** Bug 49392 has been marked as a duplicate of this bug. ***
