[sisyphus] Предложения по формированию бранчей

Led ledest на gmail.com
Пт Май 22 15:16:46 MSD 2009


On Friday 22 May 2009 12:47:51 Grigory Batalov wrote:
> On Fri, 22 May 2009 09:15:58 +0400, Alexey Novikov wrote:
> > Почему бы не воспользоваться модифицированной
> > дебиановской схемой:
> > 1. unstable (Sisyphus) - как есть на данный момент.
> > 2. testing, в который попадают пакеты из Сизифа после обкатки и
> > на котором смогут жить майнтейнеры и тестеры. Требуется
> > гарантировать обновляемость до Сизифа. Требуются достаточно свежие
> > версии apt+rpm, чтобы можно было запускать hasher с Сизифом.
>
> Насколько я понял обсуждение в devel@, вопрос в том, как повлияют
> обновлённые пакеты на бранч testing. Допустим, в бранч приходит
> новый gcc, пропущенный туда по всем формальным признакам. Может
> так случиться, что уже лежащие в бранче пакеты перестанут
> пересобираться, что неоднократно встречалось в Сизифе.

Никто не заставляет "новый gcc" выставлять как "CC по-умолчанию". Нет никакой сложности добавить для rpm ключ --cc, выставлющий CC в нужное значение при сборке (что в своём варианте rpm-4.0.4 я и сделал) и указывать нужное значение при тестовых пересборках.

>
> Как это выявить? Пересобрать весь бранч после приёма обновлённого
> пакета.

Зачем пересобирать бранч новым gcc? Хотите добавить в бранч новый gcc? Пожалуйста. Но зачем тут же делать из него "cc, которым собран бранч"?

> Пока что на пересборку не хватает мощностей. Еженедельная 
> пересборка не даёт однозначного ответа, какой из пакетов навредил,
> без участия человеческого арбитра.
>
> Как исправить? Вместе с обновляемым пакетом одной транзакцией
> пересобрать зависимые. Это большой труд. Как уже здесь писалось,
> не все мейнтейнеры интересуются бранчами, и на их поддержку трудно
> рассчитывать.
>

-- 
Led
----------- следующая часть -----------
Вложение в формате HTML было удалено...
URL: <http://lists.altlinux.org/pipermail/sisyphus/attachments/20090522/0cbb32eb/attachment-0001.html>


Подробная информация о списке рассылки Sisyphus