Re: [devel] tdb-1.0.6-alt3: Sisyphus/i586 test rebuild failed [12]

[Evgeny Sinelnikov <sin@altlinux.ru>]

25 июля 2009 г. 14:08 пользователь Alexander Bokovoy (ab@altlinux.org) написал:
> 2009/7/24 Evgeny Sinelnikov <sin@altlinux.ru>:
>> 20 июля 2009 г. 14:49 пользователь Mykola S. Grechukh
>> (gns@altlinux.org) написал:
>>> 2009/7/20 QA Team Robot <qa@altlinux.org>:
>>>> Package: tdb-1.0.6-alt3
>>>> Status: Sisyphus/i586 test rebuild failed
>>>
>>>
>>> ффпечь
>>
>> Таким образом, путь для выкладывания libtdb и libtalloc от samba4 открыт.
>>
>> Прошу конструктивно указать на препятствия и проблемы, которые есть в
>> текущих сборках Fedora в этом плане, и чем это грозит нам в текущих
>> условиях. "О, ужас, ужас, ужас..." - это не совсем понятно :)
>>
>> Для большей ясности прикладываю diff'ы для libtdb и libtalloc между
>> samba-3.4.0 и samba-4.0.0alpha8. Прошу заметить, что критической
>> разницы в ABI там нет.
> Проблема, которую я вижу, состоит в том, что мы будем делать с
> применением результатов той самой дискуссии в samba-technical@. По git
> diff release-4-0-0alpha8 HEAD -- lib/talloc и git diff release-3-4-0
> HEAD -- lib/talloc можно видеть, что изменения в API и ABI
> существенные.

Я прислал два дифа для lib/talloc и lib/tdb - как раз для
git diff release-4-0-0alpha8 HEAD
(4ceae35d7eb3b7e2e38f226e39853cff40d92464 - ветка v4-0-stable)
и
git diff release-3-4-0 (51b334e2d9739abc748490f6085ed8b8e5e1f4b4 -
ветка v3-4-stable)
Репозиторий git://git.samba.org/samba.git

По этим дифам видно, что ABI и API критичных различий _не_ имеют. В
связи с этим сборка в Fedora выглядит вполне правомерно.

Я не там смотрю? Почему я вижу отсутствие разницы, а вы говорите о
существенных различиях?

Давайте посмотрим... Разница для talloc:

diff -Nur talloc-v3.4/talloc.h talloc-v4alpha8/talloc.h
--- talloc-v3.4/talloc.h    2009-07-03 15:21:14 +0400
+++ talloc-v4alpha8/talloc.h    2009-07-09 18:46:46 +0400
@@ -121,7 +121,7 @@
 /* The following definitions come from talloc.c  */
 void *_talloc(const void *context, size_t size);
 void *talloc_pool(const void *context, size_t size);
-void _talloc_set_destructor(const void *ptr, int (*destructor)(void *));
+void _talloc_set_destructor(const void *ptr, int (*_destructor)(void *));
 int talloc_increase_ref_count(const void *ptr);
 size_t talloc_reference_count(const void *ptr);
 void *_talloc_reference(const void *context, const void *ptr);

diff -Nur talloc-v3.4/talloc.c talloc-v4alpha8/talloc.c
--- talloc-v3.4/talloc.c        2009-07-03 15:21:14 +0400
+++ talloc-v4alpha8/talloc.c    2009-07-09 18:46:46 +0400
@@ -1008,6 +1008,11 @@
                return NULL;
        }

+       /* don't let anybody try to realloc a talloc_pool */
+       if (unlikely(tc->flags & TALLOC_FLAG_POOL)) {
+               return NULL;
+       }
+
        /* don't shrink if we have less than 1k to gain */
        if ((size < tc->size) && ((tc->size - size) < 1024)) {
                tc->size = size;

Разница для tdb, чуть побольше...

diff -Nur tdb-v3.4/include/tdb.h tdb-v4alpha8/include/tdb.h
--- tdb-v3.4/include/tdb.h    2009-07-03 15:21:14 +0400
+++ tdb-v4alpha8/include/tdb.h    2009-07-09 18:46:46 +0400
@@ -129,6 +129,7 @@
 tdb_log_func tdb_log_fn(struct tdb_context *tdb);
 void *tdb_get_logging_private(struct tdb_context *tdb);
 int tdb_transaction_start(struct tdb_context *tdb);
+int tdb_transaction_prepare_commit(struct tdb_context *tdb);
 int tdb_transaction_commit(struct tdb_context *tdb);
 int tdb_transaction_cancel(struct tdb_context *tdb);
 int tdb_transaction_recover(struct tdb_context *tdb);

--- tdb-v3.4/docs/README    2009-07-03 15:21:14 +0400
+++ tdb-v4alpha8/docs/README    2009-07-09 18:46:46 +0400
@@ -236,3 +236,11 @@
    commit a current transaction, updating the database and releasing
    the transaction locks.
.
+----------------------------------------------------------------------
+int tdb_transaction_prepare_commit(TDB_CONTEXT *tdb)
+
+   prepare to commit a current transaction, for two-phase commits.
+   Once prepared for commit, the only allowed calls are
+   tdb_transaction_commit() or tdb_transaction_cancel(). Preparing
+   allocates disk space for the pending updates, so a subsequent
+   commit should succeed (barring any hardware failures).

в файле transaction.c добавлена соответствующая функциональность.

В master'е для tdb добавлена косметика. Для talloc изменения
действительно есть... Но если ждать 3.5, то его можно всё время ждать
и вообще ничего не паковать... Причём я не вижу разницы для 4.0 и 3.4
сейчас - они идут в ногу... Это снова разговор о будущем...

Объясните мне, пожалуйста, где эта существенная разница. Может у меня
нет тот репозиторий?

> Если мы сейчас запакуем "не master", то будет необходимо
> решать эту проблему при следующей сборке -- когда выйдет либо
> очередная альфа 4.0, либо релиз 3.5, что будет гораздо сложнее, потому
> что в тот момент придется снова согласовывать сборки.

Да, и решать эту проблему можно жёсткой зависимостью на версию.
Понимаете, ни в одной стабильной ветке этим новым API talloc ещё не
пахнет. И пока мы с вами рассуждаем, на счёт будущих проблем, в Fedora
этим уже пользуются... И завтра, когда будет новое API, тоже будут
пользоваться...

К чему вести речь о коде из master'а, если он отсутствует в обоих
стабильных ветках? Это же забалтывание проблемы.

Сейчас можно запаковать 3.4 и 4.0, а там тех существенных отличий, о
которых идёт речь нет.

> Поскольку предыдущая дискуссия в devel@ продемонстрировала, что в
> Сизифе все равно не верят в стабильность сборок Самбы, то я предлагаю
> поступить следующим образом:
> 1. Собрать 4.0 и 3.4+ в том виде, как оно есть сейчас в master, не
> решая проблемы обновления в пост-установочных скриптах. Бинарные
> пакеты будут иметь имена samba3 и samba4, пакет samba-* исчезнет.
> Установка samba3-* будет приводить к сносу samba-* с бэкапом имеющихся
> настроек samba-* в определенное место.
> 2. Создать пакет samba-migration, который бы мигрировал настройки,
> созданные бэкапом, в новые насколько это возможно.
> 3. Добавить поддержку миграции в samba3 на основе samba-migration.

Здесь не сказано про общие библиотеки, которые должны сходится.
Давайте определимся. Я считаю, стоит придерживаться подхода выбранного
в Fedora, когда общие либы буду выделены в отдельные пакеты...

Два вида библиотек быть не должно... Иначе это чревато другими
проблемами... Когда одна либа слинкована с libtalloc-samba3, другая -
с libtalloc-samba4, а приложение с этими двумя... Подход с двумя
либами - это не решение.

> Таким образом, в Сизифе некоторое время будет разломана Самба в смысле
> переноса старых настроек и ожиданий конфигуратора. Также надо будет
> пересобрать несколько пакетов, которые используют libsmbclient,
> поскольку ABI изменится.

Я полагаю, что "ломание" самбы - это префекционисткая мера, которая
нужна нескольким процентам пользователей, которые используют самбу
совместно с тесной интеграцией с AD. Для большинства пользователей
Сизифа эта проблема решается удалением старых баз от самбы. Вот и вся
миграция. Кроме как гостя и системных пользователей у нас обычно
никого не используют...

Для тех же кому это миграция нужна сидеть на Сизифе не
рекомендуется... Я бы предложил вместо ломания сделать после
обновления автоматический бекап в специально выделенное место. Далее,
написанный, в будущем, мигратор позволит восстанавливать базы до тех
пор пока они нормально не восстановятся...

Такой подход позволит обновить самбу ничего не ломая.

-- 
Sin (Sinelnikov Evgeny)