[sisyphus] libgtk+2 symbol map

[Andrei Bulava]

Michael Shigorin wrote:
> On Wed, Oct 12, 2005 at 03:52:02PM +0400, Alexey Rusakov wrote:
> 
>>>>Но как бороться с этой особенностью NMU, пока не знаю.
>>>
>>>Системой контроля версий, вестимо.
>>
>>Не спасёт. Забыть сделать co/ci перед/после правкой спека -
>>милое дело.  Особенно когда у тебя как правило самая последняя
>>копия.
> 
> 
> Ну так собиралку-то научить сделать co и определить, а был ли ci,
> всё-таки реальней, чем человека -- не забывать.

Кстати, да. "Забыть сделать co/ci" не сработает, если 'rpmbuild -bs
foo.spec' будет делаться _на сервере_.

Однажды я уже участвовал в решении задачи по контролируемому
выкладыванию war-сборок в контейнер сервлетов, и решил задачу так:

- все исходные коды хранятся в системе контроля версий (далее - СКВ)
локально по отношению к контейнеру сервлетов;

- все готовые библиотеки jar, использующиеся в проекте, лежат вне СКВ и
добавляются с подачи разработчика (нюанс с тем, что разработчики могут
вытереть старые версии jar'ов и сломать старые сборки, был разрешён
"нетехническими средствами", но об этом следует хорошо подумать; как и о
целостности, хотя бы в виде подписанных gpg-ключами md5/sha1 хешей);

- каждый раз на коммит "возбуждается" сборка и установка war.

При таком раскладе забывчивый человек при попытке коммита без
предварительного чекаута обязательно будет об этом уведомлён недремлющей
СКВ.

Думаю, аналогия с нашей ситуацией понятна, и уже витает в головах не
первый день.

Плюсы хранения spec'ов и, что стоит обдумать, патчей в СКВ + тарболов с
сохранением предыдущих версий:

- возможность воссоздать конфигурацию репозитария на любой заданный
момент в прошлом;
- избавление от утомительных "перезаливок" src.rpm, отличающихся только
%release.

Минусы:

- это довольно ресурсоёмкое занятие по требуемым объёмам жёстких дисков.

-- 
// AB1002-UANIC