From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <43012C55.7010202@altlinux.ru> Date: Tue, 16 Aug 2005 03:59:17 +0400 From: Alexey Gladkov Organization: ALT Linux User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050814) X-Accept-Language: ru-ru, ru MIME-Version: 1.0 To: ALT Devel discussion list Subject: Re: [devel] Re: I: Sisyphus-20050816 unmets: +7 (102/46) References: <20050815200812.GA6862@basalt.office.altlinux.org> <4300FCD0.1060708@parkheights.dyndns.org> <20050815231752.GE19097@solemn.turbinal.org> In-Reply-To: <20050815231752.GE19097@solemn.turbinal.org> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit X-BeenThere: devel@altlinux.ru X-Mailman-Version: 2.1.5 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: Tue, 16 Aug 2005 00:00:05 -0000 Archived-At: List-Archive: List-Post: Alexey Tourbin пишет: > incominger (робот) переупорядочивает пакеты в очереди на пересборку, > это описано в incominger-0.0.7.3/docs/README (ищите гуглом). При этом > если робот дает сбой, то последствия могут быть гораздо хуже, чем если > бы оставалось старое правило для упорядочивания по BUILDTIME или st_mtime. Вот зараза неужели уже за индексировали ?! :) Сейчас сбои случаются из-за того, что incominger не учитывает версии в BuildRequires. > Нужно бы ввести правило, чтобы, вопреки какому-то там закону > термодинамики, количество unmet'ов в главном репозитарии не > увеличивалось. Если же транзакция увеличивает количество unmet'ов, > то пакеты, которые порождают unmet'ы, исключаются из транзакции и > помещаются в отстойник, до следующей обработки/транзакции. Сейчас работаю над реализацией этой проверки. В incominger уже давно есть скрипт для проверки unmets, но он не использовался из-за того, что genbasedir ооооочень медленно работает. > Только вот как определить пакеты, которые порождают unmet'ы? Допустим, > Мда, астрономично. Нужен какой-нибудь более хитроумный dependency > solver. smartpm надо бы поковырять, но там питон. :) Если интеграл не берется целиком, его можно попробовать взять по частям. Все unmets можно классифицировать. После этого можно рассмотреть каждую группу и принять решение. Это реально сделать. Вопрос в другом и ты его задал. Сделаю это еще раз: что делать если неудовлетворенность порождается пакетом от которого зависят другие пакеты в разобранном инкоминге? По логике нужно исключить битый пакет и попробовать собрать пакеты без него. Но это может долгая и бессмысленная работа. Если же откладывать всех требующих битый пакет, мы можем получить некоторый ДОС. Но это жертва на которую я готов пойти. Ведь виновника можно очень просто выявить(до пересборки допускаются только подписанные пакеты) и дать по мозгу. > Нет, задним числом пакеты в репозитарии заменять нельзя. > Наверное, робот сможет добавить .1 к релизу. В данном случае incominger не виноват. Пакеты он собрал в нужном порядке. > Кстати, я написал/дописал утилиту для *упрощенного* поиска unmet'ов. > Казалось бы, куда уж проще, но всё же... > > $ ./unmets -s m24-sources.list Отлично! Я предпочитаю пользоваться простой старой табуреткой: aptbox+diff. -- Rgrds, legion