From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <3FC4A051.2070302@altlinux.com> Date: Wed, 26 Nov 2003 15:45: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> In-Reply-To: <20031125225916.GE19276@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 12:40:09 -0000 Archived-At: List-Archive: List-Post: Денис Смирнов wrote: > On Tue, Nov 25, 2003 at 03:29:11PM +0300, Stanislav Ievlev wrote: > > >>> и что такое "надёжность sisyphus" по-определению. > >> Не знаю; не вводил. > > нет определения - значит нет правила перекочёвки пакетов из этого "pre-sisyphus" в sisyphus. > > У меня есть. Надёжность это величина равная 1-<ненадёжность>, а > ненадёжность, это вероятность поиметь геморрой после dist-upgrade в виде > неработоспособного сервера (т.е. не выполняющего свои функции так же > хорошо, как до апгрейда). Ой ой ой... господа, я _не рекоменду_ использовать Sisyphus на серверах любого маштаба. > > Конечная цель моего предложение -- довести надёжность Сизифа до такой > степени, чтобы можно было себе позволить по крайней мере на своей личной > машине apt-get upgrade -y в cron'е, а при выполнении такого апдейта > ручками на сервере масштаба хотя бы офиса быть увереным, что это не будет > грозить увольнением. Собственно а зачем Sisyphus ??? Есть же Master 2.2 - его + updates должно хватить. > > >> * .classic, который и применяется > >> _пользователями_ Sisyphus. > >> (в т.ч. и разработчиками Sisyphus на хостах, которые можно > >> себе позволить / требуется держать на Sisyphus, но которые > >> желательно иметь в работоспособном состоянии), > >> при условии минимальных изменений в текущей схеме. > > До настоящего момента у нас не был "сизифа-дистрибутива", а был только "сизиф для разработчико и желающих". Идеологи должны решить эту проблему до конца, прежде чем начнутся какие-то реальные шаги. > > de-facto динамичный репозиторий пакетов востребован конечными > пользователями (в первую очередь этими пользователями являются > разработчики и тестеры, но далеко не только они). > > Поэтому можно либо закрывать глаза на такое его использование, либо > искать принимать меры, которые позволят убить сразу уйму зайцев без > негативных последствий для тех, кто привык и кому нравится нынешний > механизм разработки. > > > Как показывает практика что пакет может лежать в daedalus. Большиство > > знает что там unstable и не пользуется им. Когда пакет приходит из > > daedalus в Cизиф там обнаруживаются проблемы. > > Это всё потому, что даже Сизиф не является более-менее надёжным > дистрибутивом. Daedalus в этом смысле рассматривается как "лучше я сразу > сделаю rm -rf /, результат тот же, а работы меньше". Sisyphus вообще не дистрибутив. > > Я же предлагаю отслоить от Сизифа надёжную его часть, и позволить людям, > которым это необходимо, использовать именно его. Зачем ? > > > Так в где гарантии что на пакет из incoming хоть кто-нибудь будет смотреть. > > Для начала надо приучить _разработчиков_ пользоваться deadalus иначе > > просто будет добавлен новый совершенно неиспользуемый репозитарий. > > Это равносильно попытке приучить людей тестировать на себе новые > лекарства. Daedalus это экспериментальный дистрибутив, а никак не > нестабильный. Это не дистрибутив, а репозитарий.. и именно экспериментальный... есть много людей, которые хотят тестировать новые лекарства, если этим самые лекарства могут спасти их от неминуемой смерти или ятжелоизлечимой болезни. > > > > > 3. кто всё это будет поддерживать. > > > Скрипты. > > Не всё можно охватить скриптами. > > Даже сейчас при наличии большого количества скриптов приходится иногда > > incoming переводить на ручное управление. > > Все те изменения, которые я предложил здесь, отлично скриптуемы. Нет. Не скриптуемы до тех пор, пока в Sisyphus не появятся кем-то (неважно кем) разработанный набор скриптов. И пока этот набор скриптов не решит использовать наш incoming@ > > > Нет никаких гарантий, что нетривиальные замены библиотек, > > преименование/образование подпакетов можно будет полностью охватить скриптами. > > Образование подпакетов легко, потому как работать система будет на уровне > src.rpm, и сколько там подпакетов ей будет всё равно. Переименование -- > отлично сработает само, так как новый помещаемый в дистрибутив пакет (с > другим именем) должен конфликтовать со старым (насколько я помню), таким > образом, если у этих пакетов один и тот же мантейнер, то он может быть > вынесен скриптом автоматически. Не.. не все так просто.... для начала рекомендую попробовать вычислить набор provides для бинарных пакетов, которые получаются из src.rpm > > >> Для "заглушки" критерием может быть > >> время модификации, от которого прошло N часов (24?); > >> это даст эффект "админ должен быть в меру тормознутым" -- у > >> разработчиков будет фора в эти N часов на dist-upgrade и > >> использование пакета. > > Как и кем определяются эти N часов. Если была бага на которую кто-то ещё > > не напарывался - то не факт что через N часов она самоликвидируется. > > За N часов её можно найти и повесить в BTS, и тогда пакет перемещён не > будет. Выбирать это самое N пока придётся опытным путём, потом можно > анализировать статистику. Как показывает практика - большинство ошибок будет выявляться уже _после_ перемещения пакета, ибо для того, что бы его проверить в нестабильном репозитарии нужно неопределенно большое количество пользователей этого пакета, ежедневно обновляющихся из _нестабильного_ репозитария. Unreal. Rgds, Rider