From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <3FC4BB81.9060901@altlinux.com> Date: Wed, 26 Nov 2003 17:41:05 +0300 From: Anton Farygin Organization: ALT Linux User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.5) Gecko/20031108 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ALT Devel discussion list Subject: Re: [devel] =?KOI8-R?Q?=CF=C2_=CF=C2=D3=D5=D6=C4=C5=CE=C9=C9_?= =?KOI8-R?Q?=D0=CF=C4=C8=CF=C4=CF=D7_=CB_=CF=C3=C5=CE=CB=C5_=CE=C1=C4?= =?KOI8-R?Q?=A3=D6=CE=CF=D3=D4=C9_Sisyphus?= References: <20031125001230.D78905@elefant.dgtu.donetsk.ua> <20031125072830.GE2421@basalt.office.altlinux.org> <20031125094848.GH10424@osdn.org.ua> <20031125122911.GA9809@basalt.office.altlinux.org> <20031125225916.GE19276@localhost.localdomain> <3FC4A051.2070302@altlinux.com> <20031126140358.GC27949@localhost.localdomain> In-Reply-To: <20031126140358.GC27949@localhost.localdomain> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: devel@altlinux.ru X-Mailman-Version: 2.1.3 Precedence: list Reply-To: ALT Devel discussion list List-Id: ALT Devel discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2003 14:36:12 -0000 Archived-At: List-Archive: List-Post: Денис Смирнов wrote: > On Wed, Nov 26, 2003 at 03:45:05PM +0300, Anton Farygin wrote: > > >> Конечная цель моего предложение -- довести надёжность Сизифа до такой > >> степени, чтобы можно было себе позволить по крайней мере на своей личной > >> машине apt-get upgrade -y в cron'е, а при выполнении такого апдейта > >> ручками на сервере масштаба хотя бы офиса быть увереным, что это не будет > >> грозить увольнением. > > Собственно а зачем Sisyphus ??? > > Есть же Master 2.2 - его + updates должно хватить. > > На сервере, в большинстве случаев, да. Однако во многих оказывается > необходимость пол-сизифа бэкпортить. ну так это лучше чем держать кучу непонятных репозитариев. > > >> Я же предлагаю отслоить от Сизифа надёжную его часть, и позволить людям, > >> которым это необходимо, использовать именно его > > Зачем ? > > Затем, что есть ненулевое количество людей, которым такой репозиторий > нужен в работе. Самоубийцы должны быть на самообслуживании... все остальные - Welcom 2 Sisyphus, постоянно нестабильную среду разработки. > > >> Это равносильно попытке приучить людей тестировать на себе новые > >> лекарства. Daedalus это экспериментальный дистрибутив, а никак не > >> нестабильный. > > Это не дистрибутив, а репозитарий.. и именно экспериментальный... есть > > много людей, которые хотят тестировать новые лекарства, если этим самые > > лекарства могут спасти их от неминуемой смерти или ятжелоизлечимой болезни. > > Фишка в том, что у нас есть только Мастер (в который попадают пакеты в том > числе после freeze, и который тажже далёк от идеала в плане надёжности), и > Сизиф, использование которого сами разработчики считают склонностью к > суициду. Я же предлагаю ввести дополнительную прослойку между Сизифом и > Мастером. Ага... называется профессиональный суицид чужими руками... нет. Как-то это выглядит намного хуже, чем введение новых правил в sisyphus_check. > > >>>>> 3. кто всё это будет поддерживать. > >>>> Скрипты. > >>> Не всё можно охватить скриптами. > >>> Даже сейчас при наличии большого количества скриптов приходится иногда > >>> incoming переводить на ручное управление. > >> Все те изменения, которые я предложил здесь, отлично скриптуемы. > > Нет. Не скриптуемы до тех пор, пока в Sisyphus не появятся кем-то > > (неважно кем) разработанный набор скриптов. > > И пока этот набор скриптов не решит использовать наш incoming@ > > Я думал что это не требует уточнение, ибо абсолютно ясно всем. Ясно что? Что не будет использовать или что будет использовать? > > > > > Нет никаких гарантий, что нетривиальные замены библиотек, > > > > преименование/образование подпакетов можно будет полностью охватить > > > скриптами. > >> Образование подпакетов легко, потому как работать система будет на уровне > >> src.rpm, и сколько там подпакетов ей будет всё равно. Переименование -- > >> отлично сработает само, так как новый помещаемый в дистрибутив пакет (с > >> другим именем) должен конфликтовать со старым (насколько я помню), таким > >> образом, если у этих пакетов один и тот же мантейнер, то он может быть > >> вынесен скриптом автоматически. > > Не.. не все так просто.... для начала рекомендую попробовать вычислить > > набор provides для бинарных пакетов, которые получаются из src.rpm > > provides-то зачем? А как иначе узнать реальный список пакетов, которые получаются из этого src.rpm ? Да, еще нужно вычислить Obsoletes... > > >>>> Для "заглушки" критерием может быть > >>>> время модификации, от которого прошло N часов (24?); > >>>> это даст эффект "админ должен быть в меру тормознутым" -- у > >>>> разработчиков будет фора в эти N часов на dist-upgrade и > >>>> использование пакета. > >>> Как и кем определяются эти N часов. Если была бага на которую кто-то ещё > >>> не напарывался - то не факт что через N часов она самоликвидируется. > >> За N часов её можно найти и повесить в BTS, и тогда пакет перемещён не > >> будет. Выбирать это самое N пока придётся опытным путём, потом можно > >> анализировать статистику. > > Как показывает практика - большинство ошибок будет выявляться уже > > _после_ перемещения пакета, ибо для того, что бы его проверить в > > нестабильном репозитарии нужно неопределенно большое количество > > пользователей этого пакета, ежедневно обновляющихся из _нестабильного_ > > репозитария. Unreal. > > Тут есть один нюанс, с которым я пока не знаю как бороться. Дело в том, > что, например, basesystem я тестировать на себе не хочу. А вот тот же php > и apache -- хочу. Потому как лучше я их сам оттестирую, чем буду иметь > проблемы при обновлении. Ну так тестируйте из Sisyphus, вешайте баги, убивайте ошибки, пересобирайте для Master 2.2 - и вперед !!! На мой взгляд наиболее правильное и обоснованное решение - сделать стабильный, нестестируемый, неподдерживаемый репозитарий для последнего выпущенного дистрибутива, куда выкладывать такие вот сборки для уже вышедших дистрибутивов. > > Собственно моя первая цель -- убиение большинства критических ошибок > и явных ляпов (которые выявляются минимальным тестированием даже 2-3 > человек), и эту цель моя идея позволит выполнить. Нет, ибо для ее выполнения придется написать некоторый набор скриптов, реализующий такую функциональность, что до конца жизни придется исправлять ошибки в своих собственных скриптах. Rgds, Rider