From: Evgeny Sinelnikov <sin@altlinux.ru> To: ALT Linux Team development discussions <devel@lists.altlinux.org> Subject: Re: [devel] tdb-1.0.6-alt3: Sisyphus/i586 test rebuild failed [12] Date: Mon, 27 Jul 2009 01:29:51 +0400 Message-ID: <921f6bb40907261429i57488bbeldf2ae5035f6553f6@mail.gmail.com> (raw) In-Reply-To: <6062a6e60907261308t16be8f4vd42ce96bdb9e9e03@mail.gmail.com> 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)
next prev parent reply other threads:[~2009-07-26 21:29 UTC|newest] Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top 2009-07-20 10:49 ` Mykola S. Grechukh 2009-07-24 17:34 ` Evgeny Sinelnikov 2009-07-25 10:08 ` Alexander Bokovoy 2009-07-26 19:23 ` Evgeny Sinelnikov 2009-07-26 20:08 ` Alexander Bokovoy 2009-07-26 21:29 ` Evgeny Sinelnikov [this message] 2009-07-27 4:08 ` Alexander Bokovoy 2009-07-27 6:28 ` Evgeny Sinelnikov
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=921f6bb40907261429i57488bbeldf2ae5035f6553f6@mail.gmail.com \ --to=sin@altlinux.ru \ --cc=devel@lists.altlinux.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
ALT Linux Team development discussions This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \ devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru public-inbox-index devel Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.devel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git