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

[Evgeny Sinelnikov]

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

27 июля 2009 г. 0:08 пользователь Alexander Bokovoy (ab at altlinux.org) написал:
> 2009/7/26 Evgeny Sinelnikov <sin at 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)