29633 2013-12-05 15:17:09 +0400 SONAME убежал в другой пакет 2024-02-14 11:31:32 +0300 1 1 4 Development Sisyphus libexiv2 unstable all Linux REOPENED https://bugzilla.altlinux.org/show_bug.cgi?id=48097 P3 normal --- 28944 46625 48097 48415 48416 49392 1 zerg aris amakeenk arseny rider qa-sisyphus oldest_to_newest 144089 0 zerg 2013-12-05 15:17:09 +0400 SONAME libexiv2.so.12 убежал из пакета libexiv2 в пакет libexiv2_12 236546 1 aris 2023-11-07 21:52:58 +0300 Нетути никакого libexiv2_12. 236567 2 zerg 2023-11-08 10:39:59 +0300 Повторяется от версии к версии. 236573 3 zerg 2023-11-08 11:44:28 +0300 (Ответ для Yuri N. Sedunov на комментарий #1) > Нетути никакого libexiv2_12. Нужно перестать паковать разные библиотеки с одним и тем же именем -- libexiv2, тогда и прятать содеянное не придётся. 236966 4 arseny 2023-11-13 15:08:35 +0300 Я, конечно, напрямую не соприкасался с клиентами libexiv2, но тем не менее, не понимаю, в чём именно проявляется проблема, которую следует устранить. Смею подозревать, что этого не понимаю не только я. Сейчас в Sisyphus только один сонейм libexiv2. После задания 333714 в репозитории тоже будет только один сонейм libexiv2. До и после пакет, в котором находится libexiv2.so.2[78], будет иметь одно и то же имя. Что здесь не так и как это мешает закрытию bug 48097, bug 48415, bug 48416? Кто-нибудь, поясните, пожалуйста, подробнее. 236983 5 zerg 2023-11-13 16:59:57 +0300 (Ответ для Arseny Maslennikov на комментарий #4) > Сейчас в Sisyphus только один сонейм libexiv2. Поэтому вам кажется, что всё в порядке. > После задания 333714 в репозитории тоже будет только один сонейм libexiv2. Не уверен. 236984 6 zerg 2023-11-13 17:06:24 +0300 (Ответ для Arseny Maslennikov на комментарий #4) > не понимаю, в чём именно проявляется проблема, которую следует устранить. https://www.altlinux.org/Shared_Libs_Policy_and_updates https://www.altlinux.org/Shared_Libs_Policy 237509 7 aen 2023-11-20 11:47:31 +0300 (Ответ для Sergey V Turchin на комментарий #5) > (Ответ для Arseny Maslennikov на комментарий #4) > > Сейчас в Sisyphus только один сонейм libexiv2. > Поэтому вам кажется, что всё в порядке. > > > После задания 333714 в репозитории тоже будет только один сонейм libexiv2. > Не уверен. Давайте конкретно. 237510 8 zerg 2023-11-20 11:49:00 +0300 (Ответ для AEN на комментарий #7) > > > После задания 333714 в репозитории тоже будет только один сонейм libexiv2. > > Не уверен. > Давайте конкретно. Ждите. 237511 9 aen 2023-11-20 11:51:27 +0300 (Ответ для Sergey V Turchin на комментарий #8) > (Ответ для AEN на комментарий #7) > > > > После задания 333714 в репозитории тоже будет только один сонейм libexiv2. > > > Не уверен. > > Давайте конкретно. > Ждите. Сергей, бага должна быть конкретной. Не уверены -- проверьте. 237517 10 zerg 2023-11-20 12:07:12 +0300 (Ответ для AEN на комментарий #7) > > > После задания 333714 в репозитории тоже будет только один сонейм libexiv2. > > Не уверен. > Давайте конкретно. Оффтопик. 237522 11 zerg 2023-11-20 13:59:17 +0300 (Ответ для AEN на комментарий #9) > Не уверены -- проверьте. Проверил, удостоверился и создал этот баг. Перебегание SONAME-а в другой пакет без provides/obsoletes является багом без каких-то деталей ещё. Этот баг возникает из-за того, что пакет libexiv2 упакован не в соответствии c https://www.altlinux.org/Shared_Libs_Policy 237528 12 zerg 2023-11-20 15:10:06 +0300 Поставил блок на #46625 , что позволит избежать дополнительных проблем при обновлении p10 --> p11. https://www.altlinux.org/Shared_Libs_Policy_and_updates 237537 13 arseny 2023-11-20 17:21:21 +0300 (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 и её клиентов ситуация, где администратор явно хочет так сделать, представляется мне маловероятной, а пара десятков клиентов являются концевыми узлами графа зависимостей, от них не зависит ничего. Или это не так? 237538 14 arseny 2023-11-20 17:22:08 +0300 С другой же стороны, от противников перевода libexiv2 на Shared Libs Policy и вообще противников Shared Libs Policy мы вообще никаких аргументов в защиту своей точки зрения не услышали. 237555 15 zerg 2023-11-21 09:35:30 +0300 (Ответ для Arseny Maslennikov на комментарий #13) > риск фактически сломать обновление Не сломать, а невозможность произвести. Ну и кроме Сизифа и бранчей есть весь остальной мир с пакетами RPM. > появится в тот > момент, когда при обновлении (внутри Sisyphus или между бренчами) зачем-то > возникнет необходимость захолдить Нет. При обновлении с ветки на ветку, когда _без_ холда надо вручную обновить один пакет с некорректными зависомостями, т.к. автоматом apt его он не хочет, из-за этого блокируется всё обновление. Возможно, у вас нет опыта обновления с ветки на ветку. 241557 16 zerg 2024-02-13 11:06:46 +0300 Это будет кто-то решать? Или главное было хоть как-то обновить, а потом хоть трава не расти? 241559 17 zerg 2024-02-13 11:27:21 +0300 Я даже больше скажу. Это в p10 надо исправлять на данный момент. 241568 18 zerg 2024-02-13 12:31:28 +0300 Короче! Даю на размышление неделю. Если движений не будет, исправляю в p10 и буду каждый раз подтирать мантейнеру в каждом новом бранче. 241580 19 zerg 2024-02-13 13:44:39 +0300 Как вижу, мантейнер не против. 241627 20 zerg 2024-02-14 11:31:32 +0300 *** Bug 49392 has been marked as a duplicate of this bug. ***