Bug 29633

Нетути никакого 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. ***