From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Wed, 23 Mar 2011 14:56:24 +0300 From: Alexey Tourbin To: ALT Linux Team development discussions Message-ID: <20110323115624.GB28396@altlinux.org> References: <4D899620.4020304@mmedia2.kemsu.ru> <20110323110533.GA28396@altlinux.org> <20110323113139.GC28036@altlinux.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20110323113139.GC28036@altlinux.org> Subject: Re: [devel] debuginfo, or new branch X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 11:56:24 -0000 Archived-At: List-Archive: List-Post: On Wed, Mar 23, 2011 at 02:31:39PM +0300, Dmitry V. Levin wrote: > On Wed, Mar 23, 2011 at 02:05:34PM +0300, Alexey Tourbin wrote: > > По технологическому уровню есть два критических пункта: > > 1) конфликтующие симлинки в *-debuginfo пакетах; > > Конфликтующие симлинки в *-debuginfo пакетах это скорее преимущество чем > недостаток. Наличие альтернативных soname'ов в Сизифе есть следствие > того, что миграция на новые версии библиотек не происходит одномоментно. > В стабильном бранче никаких случайных альтернативных soname'ов не должно > быть вообще, а значит, и никаких случайных конфликтующих debuginfo-пакетов > не будет. Да, с другой стороны это интересная фича по проверке конфликтов. Но всё-таки это означает невозможность одновременно установить пакеты libfoo1-debuginfo и libfoo2-debuginfo из-за низкоуровневого файлового конфликта. Это нельзя считать всецело преимуществом перед возможностью нормальной установки пакетов. > > ясно, что всё придётся пересобирать ещё раз. > Это ещё зачем? Если не конфликтующие .debug симлинки/логика создания *-debuginfo пакетов, то i686. А если не i686, то скоро ещё что-нибудь придумается. > > По пакетной базе - идёт процесс распрямления зависимостей у *-devel > > пакетов. Ночью пересобрал cups. > > Зря ты это затеял в таком виде. На практике происходит искривление > пакетов, теряющих поддержку разного функционала. Риск того, что пакет, Нет, не зря, когда-то это всё равно нужно было делать, и если не идти на поводу у воротил от бизнеса, то подходящим поводом может считаться появление cpp.req: зависимости, которые обнаруживает cpp.req, удалить не удастся. Короче, наличие инструмента делает процесс изменения зависимостей прозрачным и оправданным. А если так подумать, то можно во все пакеты добавить зависимости на все другие пакеты, чтобы не потерять поддержку разного функционала. Например, в пакете libqt4-devel есть зависимость xorg-devel. Очевидно, чтобы другие пакеты не потеряли поддержку разного функционала. Ночью я собрал sisyphus_check, которые запрещает зависимость на xorg-devel. > прошедший test-only-сборку, окажется испорченным по окончании финальной > сборки из-за того, что между этими двумя сборками в Сизиф успел > проскочить "распрямленный" devel-пакет, сильно вырос. Теперь нужно > добавлять в girar-builder возможность автоматически превращать финальную > сборку в тестовую в случае, если финальная cборка не попадает в > категорию "no need to rebuild". И вывод rpmdiff'а стал теперь гораздо > актуальнее чем раньше. Да, в girar-builder должна быть интегрирована тестовая пересборка и диагностика изменения зависимостей. Так называемый метарепозиторий, который до сих пор не реализован вследствие тонкостей душевной конституции. Ну и вследствие того, что железа для тестовой пересборки за 5 лет так и не появилось.