On Fri, May 22, 2009 at 02:16:46PM +0300, Led wrote:
> 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_version тогда не забудьте,
не все пакеты во время сборки используют %__cc.

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

gcc был приведён в качестве примера.
Вопрос не в том, зачем, а в том, что делать, когда _такой_ пакет
туда отправлен.  Автомат должен не искать ответ на вопрос "зачем?",
а решать, пускать пакет или нет.


-- 
ldv