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

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

[Mykola S. Grechukh]

2009/7/20 QA Team Robot <qa@altlinux.org>:
> Package: tdb-1.0.6-alt3
> Status: Sisyphus/i586 test rebuild failed


ффпечь

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

[Evgeny Sinelnikov]

[-- Attachment #1: Type: text/plain, Size: 675 bytes --]

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 там нет.


-- 
Sin (Sinelnikov Evgeny)

[-- Attachment #2: tdb-v4alpha8.diff.gz --]
[-- Type: application/x-gzip, Size: 15365 bytes --]

[-- Attachment #3: talloc-v4alpha8.diff.gz --]
[-- Type: application/x-gzip, Size: 11632 bytes --]

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

[Alexander Bokovoy]

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

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

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

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

[Evgeny Sinelnikov]

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)

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

[Alexander Bokovoy]

2009/7/26 Evgeny Sinelnikov <sin@altlinux.ru>:
> По этим дифам видно, что ABI и API критичных различий _не_ имеют. В
> связи с этим сборка в Fedora выглядит вполне правомерно.
>
> Я не там смотрю? Почему я вижу отсутствие разницы, а вы говорите о
> существенных различиях?
Вы не туда смотрели.

> Давайте посмотрим... Разница для talloc:
>
> diff -Nur talloc-v3.4/talloc.h talloc-v4alpha8/talloc.h
Как я сказал -- смотреть надо в разницу между master и этими
стабильными ветками. Вся суть дискуссии была именно в этом.

> Объясните мне, пожалуйста, где эта существенная разница. Может у меня
> нет тот репозиторий?
Вы читали дискуссию в samba-technical@, на которую сами же и ссылались?


>> Если мы сейчас запакуем "не master", то будет необходимо
>> решать эту проблему при следующей сборке -- когда выйдет либо
>> очередная альфа 4.0, либо релиз 3.5, что будет гораздо сложнее, потому
>> что в тот момент придется снова согласовывать сборки.
>
> Да, и решать эту проблему можно жёсткой зависимостью на версию.
> Понимаете, ни в одной стабильной ветке этим новым API talloc ещё не
> пахнет. И пока мы с вами рассуждаем, на счёт будущих проблем, в Fedora
> этим уже пользуются... И завтра, когда будет новое API, тоже будут
> пользоваться...
Я говорю о том, что уже есть и то, с чем придется иметь дело. Задача
мейнтейнера -- обеспечить минимальные проблемы для своих
пользователей. Двойной переезд за короткое время, который Вы
предлагаете, таким свойством не обладает.

> Здесь не сказано про общие библиотеки, которые должны сходится.
> Давайте определимся. Я считаю, стоит придерживаться подхода выбранного
> в Fedora, когда общие либы буду выделены в отдельные пакеты...
>
> Два вида библиотек быть не должно... Иначе это чревато другими
> проблемами... Когда одна либа слинкована с libtalloc-samba3, другая -
> с libtalloc-samba4, а приложение с этими двумя... Подход с двумя
> либами - это не решение.
О двух библиотеках я речь и не вел, перечитайте мое предложение. Я
вообще не говорю сейчас о двух библиотеках, я веду речь о сборке
master, в котором source4 и source3 используют единые версии служебных
библиотек.

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

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

Я пока не готов разменивать осторожный подход к данным пользователей
на сборку без оглядки.

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

-- 
/ Alexander Bokovoy

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

[Evgeny Sinelnikov]

2ab@:Читайте последовательно, моё осознание вашего предложения
протекало постепенно, по мере прочтения вашего ответа... ;)

27 июля 2009 г. 0:08 пользователь Alexander Bokovoy (ab@altlinux.org) написал:
> 2009/7/26 Evgeny Sinelnikov <sin@altlinux.ru>:
>> По этим дифам видно, что ABI и API критичных различий _не_ имеют. В
>> связи с этим сборка в Fedora выглядит вполне правомерно.
>>
>> Я не там смотрю? Почему я вижу отсутствие разницы, а вы говорите о
>> существенных различиях?
> Вы не туда смотрели.

Ответ не совсем конструктивен... Я спрашивал, куда смотреть?

>> Давайте посмотрим... Разница для talloc:
>>
>> diff -Nur talloc-v3.4/talloc.h talloc-v4alpha8/talloc.h
> Как я сказал -- смотреть надо в разницу между master и этими
> стабильными ветками. Вся суть дискуссии была именно в этом.

Я не совсем понимаю необходимости смотреть на разницу между тем, "что
есть" и тем, "что будет", с задаче запаковать "то, что есть". А
именно. 4.0alpha8 и 3.4.0.

Я искренне полагаю, что вы усложняете задачу этим сравнением. К чему
решать вопросы, с которыми upstream ещё не определился? Сегодня и
завтра оно работать будет...

К тому же, если вопрос не в библиотеках, то в чём собственно
предложение? Сейчас можно собрать то, что есть...

>> Объясните мне, пожалуйста, где эта существенная разница. Может у меня
>> нет тот репозиторий?
> Вы читали дискуссию в samba-technical@, на которую сами же и ссылались?

Да, но я никак не могу добиться какую часть из этой большой и
длительной дискуссии вы приводите в качестве аргументов, а самое
главное, аргументов для чего... Я не понимаю сути вопроса по сравнению
master и того, "что есть" (samba4.0 и samba3.4). Когда для сборки
важно соответствие того, "что есть" (samba4.0) и того, "что есть"
(samba3.4).

>
>>> Если мы сейчас запакуем "не master", то будет необходимо
>>> решать эту проблему при следующей сборке -- когда выйдет либо
>>> очередная альфа 4.0, либо релиз 3.5, что будет гораздо сложнее, потому
>>> что в тот момент придется снова согласовывать сборки.
>>
>> Да, и решать эту проблему можно жёсткой зависимостью на версию.
>> Понимаете, ни в одной стабильной ветке этим новым API talloc ещё не
>> пахнет. И пока мы с вами рассуждаем, на счёт будущих проблем, в Fedora
>> этим уже пользуются... И завтра, когда будет новое API, тоже будут
>> пользоваться...
> Я говорю о том, что уже есть и то, с чем придется иметь дело. Задача
> мейнтейнера -- обеспечить минимальные проблемы для своих
> пользователей. Двойной переезд за короткое время, который Вы
> предлагаете, таким свойством не обладает.

По моему, вы путаете "пользователей", которые будут устанавливать и
запускать пакеты, с "пользователями", которые будут самостоятельно
компилировать приложения с библиотеками от самбы.

Первых обеспечить безопасным переездом будет можно, вторых - нет. Но
кто эти вторые? Человек, который использует библиотеку с нестабильным
API, он должен быть к этому готов.

Я вообще не понимаю вашего предложения на этот счёт. Неужели вы
предлагаете вместо того, чтобы собрать стабильные выпуски Samba,
"похачить" их на предмет совместимости с будущей версией их же
внутренних библиотек, дабы чего-то избежать?


>> Здесь не сказано про общие библиотеки, которые должны сходится.
>> Давайте определимся. Я считаю, стоит придерживаться подхода выбранного
>> в Fedora, когда общие либы буду выделены в отдельные пакеты...
>>
>> Два вида библиотек быть не должно... Иначе это чревато другими
>> проблемами... Когда одна либа слинкована с libtalloc-samba3, другая -
>> с libtalloc-samba4, а приложение с этими двумя... Подход с двумя
>> либами - это не решение.
> О двух библиотеках я речь и не вел, перечитайте мое предложение. Я
> вообще не говорю сейчас о двух библиотеках, я веду речь о сборке
> master, в котором source4 и source3 используют единые версии служебных
> библиотек.
>

То есть совсем про master?
Честное слово, я удивлён...

Действительно интерпретировать "Собрать 4.0 и 3.4+ в том виде, как оно
есть сейчас в master" можно по разному...

Я полагал, что вы имеете в виду текущие срезы и обновления у к ним...

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

Хорошо, я спорить здесь не могу... Вероятно, я не понимаю всех
вариантов проблем.

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

Я ощущаю некоторые противоречия в ваших предложениях.

С одной стороны вы говорите о пользователях, с другой - подразумеваете
разработчиков.

С одной стороны заявляете о том, что "предыдущая дискуссия в devel@
продемонстрировала, что в
Сизифе все равно не верят в стабильность сборок Самбы", с другой - "не
готовы разменивать осторожный подход к определённым пользователям".

> Я пока не готов разменивать осторожный подход к данным пользователей
> на сборку без оглядки.

В итоге, я не понимаю какого же компромисса мы хотим добиться. Я готов
принять "почти" любой :) Но я хочу его понять и не тянуть с этим долго
;)

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

На деле я предложил то же самое, что и вы, только другими словами.
Только для вас вариант слетевших баз - это сломанная самба, а я не
вижу в этом ничего плохого, для большинства пользователей... Везде,
где у меня используется интеграция с доменом, я не поднимался выше
5.0.

Так, что ваш вариант, если я его теперь правильно осознаю, я поддерживаю...
Резюмируя, своими словами, я понял вас так.
- Собираем самбу из master (то есть из самого распоследнего git'а
разработчиков), в котором сливаются samba3 и samba4.
- Делаем это так, что получаем две самбы.
- Настройки разносим так, чтобы у новых сборок они были в новых
местах, тем самым обеспечивая пресловутый бекап для миграции.

Мне нравится это вариант. Но, я как-то полагаю, что обеспечить сборку
4.0.0alpha8 и 3.4.0 можно сегодня-завтра. А этот красивый вариант мы
ещё до осени пилить будем, если не определимся с минимальным
результатом... При этом, если результат будет слишком минимальным,
стабильность этого варианта, для меня, выглядит намного более
сомнительной, чем миграция.

Возможно мои опасения излишни... Как вы предлагаете это собирать и тестировать?
Собираем из одного git'а обе самбы в одном спеке?
Как поступаем с клиентскими библиотеками?

-- 
Sin (Sinelnikov Evgeny)

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

[Alexander Bokovoy]

2009/7/27 Evgeny Sinelnikov <sin@altlinux.ru>:
> На деле я предложил то же самое, что и вы, только другими словами.
> Только для вас вариант слетевших баз - это сломанная самба, а я не
> вижу в этом ничего плохого, для большинства пользователей... Везде,
> где у меня используется интеграция с доменом, я не поднимался выше
> 5.0.
Если учетные записи, в том числе и машин, вдруг "исчезнут",
пользователям (администраторам) будет абсолютно все равно, какая
версия Самбы приехала в виде обновления.  Заведение этих пользователей
(если Самба использовалась как контроллер домена даже в самом простом
варианте с tdbsam или smbpasswd) влечет за собой организационные
проблемы в виде действий пользователей по вводу паролей в очередной
раз и по перевводу рабочих станций обратно в домен. Это довольно
трудоемкая организационная процедура, когда системой пользуются даже
несколько десятков пользователей, не говоря уже о сотнях.

В случае LDAP все немного проще, но и здесь переезд означает смену
конфигурационного файла (idmap config alloc backend и тому подобное).

> Так, что ваш вариант, если я его теперь правильно осознаю, я поддерживаю...
> Резюмируя, своими словами, я понял вас так.
> - Собираем самбу из master (то есть из самого распоследнего git'а
> разработчиков), в котором сливаются samba3 и samba4.
> - Делаем это так, что получаем две самбы.
> - Настройки разносим так, чтобы у новых сборок они были в новых
> местах, тем самым обеспечивая пресловутый бекап для миграции.
Да.

> Возможно мои опасения излишни... Как вы предлагаете это собирать и тестировать?
> Собираем из одного git'а обе самбы в одном спеке?
Собираем из одного git-а двумя спеками -- по разным тэгам. Приоритет
при сборке не важен, нужно определиться с чем-то одним, что будет
содержать libtdb, libtalloc, libtevent. Остальное собирается с ними
как с системными. Можно даже собирать их отдельным спеком (все три
основных библиотеки вместе). Напомню, что все это gear позволяет
организовать.

> Как поступаем с клиентскими библиотеками?
Клиентские библиотеки в 3.х и 4.х различаются, они даже по именам не
пересекаются. Аналога libsmbclient в 4.0 нет, libcli более
низкоуровневая. С остальными немного проще.

-- 
/ Alexander Bokovoy

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

[Evgeny Sinelnikov]

27 июля 2009 г. 8:08 пользователь Alexander Bokovoy (ab@altlinux.org) написал:
> 2009/7/27 Evgeny Sinelnikov <sin@altlinux.ru>:
>> На деле я предложил то же самое, что и вы, только другими словами.
>> Только для вас вариант слетевших баз - это сломанная самба, а я не
>> вижу в этом ничего плохого, для большинства пользователей... Везде,
>> где у меня используется интеграция с доменом, я не поднимался выше
>> 5.0.
> Если учетные записи, в том числе и машин, вдруг "исчезнут",
> пользователям (администраторам) будет абсолютно все равно, какая
> версия Самбы приехала в виде обновления.  Заведение этих пользователей
> (если Самба использовалась как контроллер домена даже в самом простом
> варианте с tdbsam или smbpasswd) влечет за собой организационные
> проблемы в виде действий пользователей по вводу паролей в очередной
> раз и по перевводу рабочих станций обратно в домен. Это довольно
> трудоемкая организационная процедура, когда системой пользуются даже
> несколько десятков пользователей, не говоря уже о сотнях.

Это безусловно плохо... Но решать вопрос иначе, чем поэтапно, мне
кажется довольно сложно. Наши средства совместной разработки не
приспособлены к такой коллективной работе, которая бы не требовала
"перепрыгивать пропасть в два и более прыжков..."

Всё, что мы себе можем позволить - это плодить бранчи. А, в текущем
workflow, это чревато поддержкой их всех по цепочке из-за особенностей
обновления. Последнее для сборки приспособлено, а вот, для
тестирования, аналогичной штуки, которую привёл в недавнем сообщении
mike@ (что-то вроде btrfs на руте для откатов системы) у нас пока не
практикуется.

> В случае LDAP все немного проще, но и здесь переезд означает смену
> конфигурационного файла (idmap config alloc backend и тому подобное).

В случае же Samba нужно сначала ручной способ обнаружить... У меня, на
первый взгляд, сложилось впечатление, что этот процесс не особо
описан... Даже здесь:
http://samba.org/samba/docs/man/Samba-HOWTO-Collection/upgrading-to-3.0.html
довольно не густо.

Чтобы написать мигратор, нужно понимать, а что же должно переехать. У
кого-нибудь есть опыт переезда?

>> Так, что ваш вариант, если я его теперь правильно осознаю, я поддерживаю...
>> Резюмируя, своими словами, я понял вас так.
>> - Собираем самбу из master (то есть из самого распоследнего git'а
>> разработчиков), в котором сливаются samba3 и samba4.
>> - Делаем это так, что получаем две самбы.
>> - Настройки разносим так, чтобы у новых сборок они были в новых
>> местах, тем самым обеспечивая пресловутый бекап для миграции.
> Да.
>
>> Возможно мои опасения излишни... Как вы предлагаете это собирать и тестировать?
>> Собираем из одного git'а обе самбы в одном спеке?
> Собираем из одного git-а двумя спеками -- по разным тэгам. Приоритет
> при сборке не важен, нужно определиться с чем-то одним, что будет
> содержать libtdb, libtalloc, libtevent. Остальное собирается с ними
> как с системными. Можно даже собирать их отдельным спеком (все три
> основных библиотеки вместе). Напомню, что все это gear позволяет
> организовать.

Да, полагаю, что либы можно отдельными тегами... Но вы не перечислили
ещё одну довольнo не простую деталь - libldb.

В случае с samba4 сборка модулей для libldb сделана довольно
странно..Сборка модулей в so не завершена, вместо этого они линкуются
во все нужные бинарники статиком. В итоге питоновские модули из
каталога сборки работают, а из установленной системы - нет.

Полагаю, что собирать есть смысл только liblbdb от samba4 - на его API
завязаны другие проекты.

>> Как поступаем с клиентскими библиотеками?
> Клиентские библиотеки в 3.х и 4.х различаются, они даже по именам не
> пересекаются. Аналога libsmbclient в 4.0 нет, libcli более
> низкоуровневая. С остальными немного проще.
>

Ну, тогда осталось отделить внутренние библиотеки от клиентских.

Вот это у нас куда пойдёт?
%_libdir/libdcerpc.so.*
%_libdir/libdcerpc_samr.so.*
%_libdir/libndr.so.*
%_libdir/libsamba-hostconfig.so.*
%_libdir/libsamba-util.so.*
Для него ведь и devel есть.

Winbind'ов два разных планируем?

Samba-common каким планируем?

-- 
Sin (Sinelnikov Evgeny)