Bug 22272

по другому избавится от 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 и при необходимости.

Разламывать плохо, но цепляться вусмерть по мелочам ещё хуже. :)