On Fri, Jul 10, 2009 at 12:49:51AM +0400, Lebedev Sergey wrote:
> On 09 Jul, Afanasov Dmitry wrote:
> [skip]
> > > Я постарался реализовать прозрачное обновление сервера и
> > > библиотек.
> > > 
> > > 1) libldap2.4 обратно совместима с libldap2.3.
> > > 2) openldap 2.4.16 собран с новой версией berkeley db (4.7).
> > нет, и ещё раз нет.
> 
> Почему? В чем объективные причины этого не делать?
я рассуждаю не на уровне объективности, а на уровне последствий и их
приемлемости. те последствия, что я вижу сейчас мне не нравятся. не
нравятся по тем же причинам, что и Денису Смирнову

основные изменения, что здесь происходят: смена soname и смена формата
базы.

soname сейчас сменился, по SharedLibPolicy делать ссылку со старого soname
на старый просто нельзя. compat быть обязан.

я не знаю, объективен ли SharedLibPolicy, как я понимаю, это просто
формулировка того, что мы считаем неприелемым разъезд API и ABI программ
и библиотек.

второй пункт: конвертация баз из одного формата в другой в общем случае
является нетривиальной задачей. проблема в том, что у нас именно общий
случай - мы не знаем, как и где используется сизифный openldap.

более того, при смене формата баз конвертация должна запускаться на уровне
сервера, а не на уровне обновления.

наконец, я прошу учитывать, что разница между текущим сизифом и рабочей
системой не обязательно будет неделя-две-месяц, разница может быть в годы
и система может быть какой угодно, например точечно быть осизифленной, но
ни разу не dist-upgrade'нутой.

а теперь представим обновление сентябрского сизифа до текущего.
обвновляется будет порядка 1200 пакетов. интересно, много шансов заметить
в этом километровом листинге ошибку обновления ldap'а? не прервет ли этот
красивый листинг ошибка при обновлении ldap'а?

именно по причине сложности конвертации и высоких шансов пропустить, что
же там происходит, я считаю, что конвертацию базы на этапе rpm -Uhv делать
нельзя. максимум перекинуть её из %post в service openldap start, хотя и
здесь та же проблема: машина может запускаться без монитора, и опять
пользователь не увидит ошибки. либо отвалится по service slapd
condreload/condrestart при том же обвнолении.


я и здесь согласен с Денисом, что самым правильным вариантом будет вариант
postgresql: нужен openldap4 (или 24), а 2.3 оформить как compat.


это было по делу, дальше JT :)

> > я как представлю обновление машины на сизифе полугодичной давности, так
> > страшно становится.
> 
> Хотелось бы уточнить. У вас есть некий сервер на Сизифе с
> openldap'ом и вам страшно его обновлять, потому что в Сизифе
> будет новый openldap?
ай-ай-ай, не в ту ведь сторону уходим. причем здесь страшно/не страшно?
мне не страшно, я просто считаю, что ручную работу делать автоматической
неправильно.

а если бы и было, что это надо исправлять. разве правильно, когда народ
боится? :)

> > качество обновления нужно учесть не только сейчас, но и через год, два, а
> > то и три.
> 
> Дмитрий, что конкретно в сборке, которую я предлагаю, снижает
> качество обновления?
то что оно автоматическое и высок шанс пропустить, где же ошибка.

> > в var у меня 2Г, 1.5 которых часто занято apt-cache'ем. /var/log всегда
> > отдельно ибо нефиг размножаться.
> 
> Если размер свободного места на разделе недостаточно для создания 
> backup'а, то установка будет прекращена. Похожий вопрос уже был в 
> этом треде.
аха, и после обновления openldap будет в дауне, а причина будет описана
на 30 shift-pgdn'ов вверх и до неё будет не добраться - кеш у консоли
маленький.

> > кстати, это тянет не на openldap, а на openldap4 с сохранением
> > принципиально не обновляемого compat.
> 
> Лично я не вижу _существенных_ причин этого делать. 
надеюсь выше я объяснил, почему несущественные для вас причины для меня
являеются существенными.

если есть хоть шанс неожиданно усложнить жизнь - надо искать другой
способ. благо другой способ есть.
-- 
С уважением
Афанасов Дмитрий