The following packages will be REPLACED: libbluez4 (by libbluez) Зачем было ломать то, что в большей степени соответствовало http://www.altlinux.org/SharedLibsPolicy?
по другому избавится от bluez-3.36 возможности не вижу. полиси не читал
(В ответ на комментарий №1) > по другому избавится от bluez-3.36 возможности не вижу. полиси не читал Почитайте, пожалуйста. Разработчик должен читать и соблюдать полиси. Если не видите возможности его соблюсти -- напишите в devel@.
Valery, you shall NEVER do things like this.
1. прежде чем давать советы, Вы бы сначала разобрались в вопросе. 2. что предлагается делать по этому REOPENED?
(In reply to comment #4) > 1. прежде чем давать советы, Вы бы сначала разобрались в вопросе. Разобраться в вопросе -- это дело мантейнера. Если у него есть вопросы, то, к счастью, есть у кого спросить. > 2. что предлагается делать по этому REOPENED? Предлагаю выпустить 4.57-alt3, в котором переименовать библиотеку обратно в libbluez4, как оно было в <=4.57-alt1, и расставить соответствующие provides/obsoletes/conflicts. Если есть другие соображения, то предлагаю обсудить их, а не закрывать баг сразу с WONTFIX.
1. как мантентейнер разобрался, вопросы с невразумительными ответами были в devel@ 2. bluez-3.36 в ближайшее время быдет удален, поэтому смысла в libbluez[4ит.д.] не вижу
(In reply to comment #2) > Почитайте, пожалуйста. Разработчик должен читать и соблюдать полиси. Чтобы начинать что-то соблюдать, надо это что-то принять. Только все заинтересованные не торопятся начинать процедуру описанную в http://www.altlinux.org/PolicyPolicy
это точно... лично я во многом не согласен с http://www.altlinux.org/SharedLibsPolicy. от мусора надо избавляться, а не плодить его, он карму портит. живой пример: $ apt-cache whatdepends libicu40 libicu40-1:4.0.1-alt3 dwdiff-1.5.2-alt1 Требует: <libicuuc.so.40> libicu40-1:4.0.1-alt3 libicu40 до сих пор жива не потому что для dwdiff нужна именно 4.0, а потому что dwdiff пересобирать нЕкто не спешит. будем дальше обезъяничать аля дебиан?
(In reply to comment #6) > 1. как мантентейнер разобрался, вопросы с невразумительными ответами были в > devel@ > 2. bluez-3.36 в ближайшее время быдет удален, поэтому смысла в libbluez[4ит.д.] > не вижу Люди будут много лет испытывать проблемы с обновлениями, зачем нам это делать? $ rpmsodiff libbluez3-3.36-alt4.x86_64.rpm libbluez-4.57-alt2.x86_64.rpm sonames only in libbluez3-3.36-alt4 [1]: libbluetooth.so.2 /usr/lib64/libbluetooth.so.2.11.2 sonames only in libbluez-4.57-alt2 [2]: libbluetooth.so.3 /usr/lib64/libbluetooth.so.3.4.2 no common sonames Т.е. с точки зрения клиентских пакетов это две разные библиотеки. Зачем их нужно тащить под одну крышу?
(В ответ на комментарий №9) > (In reply to comment #6) > > 1. как мантентейнер разобрался, вопросы с невразумительными ответами были в > > devel@ > > 2. bluez-3.36 в ближайшее время быдет удален, поэтому смысла в libbluez[4ит.д.] > > не вижу > > Люди будут много лет испытывать проблемы с обновлениями, зачем нам это делать? хоть раз бы кто нибудь показал эти проблемы, пока это только слухи > $ rpmsodiff libbluez3-3.36-alt4.x86_64.rpm libbluez-4.57-alt2.x86_64.rpm > sonames only in libbluez3-3.36-alt4 [1]: > libbluetooth.so.2 /usr/lib64/libbluetooth.so.2.11.2 > > sonames only in libbluez-4.57-alt2 [2]: > libbluetooth.so.3 /usr/lib64/libbluetooth.so.3.4.2 > > no common sonames > > Т.е. с точки зрения клиентских пакетов это две разные библиотеки. > Зачем их нужно тащить под одну крышу? разные у них только soname, после перезборки клиентских пакетов разницы уже не будет. сейчас для клиентских пакетов они разные потому что libbluez-devel-3.36 вовремя не был удален
и еще. для того что бы избежать проблем с обновлениями не к чему плодить одни и теже библиотеки разных версий с разными soname. карму портят
(In reply to comment #8) > это точно... лично я во многом не согласен с > http://www.altlinux.org/SharedLibsPolicy. "Скажу вам по секрету, тоже не очень доволен нашим календарем. Но я не позволяю себе срывов!" > от мусора надо избавляться, а не > плодить его, он карму портит. живой пример: > $ apt-cache whatdepends libicu40 > libicu40-1:4.0.1-alt3 > dwdiff-1.5.2-alt1 > Требует: <libicuuc.so.40> > libicu40-1:4.0.1-alt3 > > libicu40 до сих пор жива не потому что для dwdiff нужна именно 4.0, а потому > что dwdiff пересобирать нЕкто не спешит. Надо уметь поддерживать нормальные контакты с людьми. Баги на dwdiff нет, обсуждения в devel тоже нет. Может быть, есть личная переписка? > будем дальше обезъяничать аля дебиан? Debian -- это наше отдалённое будущее, если мы, конечно, будем иметь счастье дожить до него.
ключевое слово если... а вот свежее для примера http://lists.altlinux.org/pipermail/devel/2009-November/176917.html тут тебе и devel@, и личная переписка. в результате таск канул в лету
(In reply to comment #13) > ключевое слово если... а вот свежее для примера > http://lists.altlinux.org/pipermail/devel/2009-November/176917.html > тут тебе и devel@, и личная переписка. в результате таск канул в лету Эти самые правила придумали для того, чтобы не превращать жизнь мейнтейнеров в ад. Если ты не следуешь этим правилам, то не стоит удивляться, что эти мейнтейнеры тебя плохо слышат.
а вот другая сказочка, так сказать результат libbtctl - GNOME bluetooth control library * Tue Nov 10 2009 Alexey Rusakov <ktirf@altlinux> 0.11.1-alt1 - New version (0.11.1), ported to Bluez 4.
т.ч. тут не понятно что лучше - сначало разломать, потом починить (как это было раньше), или не ломать и заплесневеть (то к чему мы стремимся)
есть ряд случаев, когда SharedLibsPolicy не работает. Например, когда старая библиотека перестаёт работать в новом окружении, то её лучше удалить, а её клиентов - пересобрать/исправить. Иначе мы можем незаметно для нас получить сломанный функционал в некоторых компонентах Sisyphus.
в данном случае это еще и заметно. всякие gnome-bluetooth/blueman/kbluetooth давно используют bluez-4 и их в первую очередь будет ставить любой пользователь, а потом долго удивляться почему же не работает эээ... Мишь, не помню как оно назвается, кажется что то на g, слинкованное с libbluetooth.so.2
на букву g имелось ввиду gammu
(In reply to comment #1) > по другому избавится от bluez-3.36 возможности не вижу. полиси не читал У меня не было претензий к последним версиям этого полиси, всё же рекомендую. > 2. bluez-3.36 в ближайшее время быдет удален, поэтому смысла в libbluez[4ит.д.] > не вижу Ну так когда-нить будет 5.x, переезд на него опять сложно будет сделать синхронным -- охота ли наступать на те же грабли? PS: про gammu: не успел тогда сразу сделать и проверить, сегодня вспоминал -- надеюсь добраться, я не назло торможу :(
(В ответ на комментарий №9) ... > Т.е. с точки зрения клиентских пакетов это две разные библиотеки. > Зачем их нужно тащить под одну крышу? по результатам последней пересборки эти самые клиентские пакеты так не думают
При соответствии bluez SharedLibsPolicy достаточно пересборки gammu, что и делаю. [ага, вспомнил -- застопорился с изменениями в 1.30.1, вот и задержалась своевременная пересборка] => отправил 1.23.1-alt5, извини за тормоза.
тема исчерпана?
Давай вернёмся к ней при следующей смене soname и при необходимости. Разламывать плохо, но цепляться вусмерть по мелочам ещё хуже. :)
