On Thu, Mar 24, 2011 at 11:52:24PM +0300, Alexey Tourbin wrote:
> После исправления зависимостей у *-devel пакетов некоторые пакеты стали
> собираться в урезнной конфигурации.  Большая часть таких пакетов может
> быть идентифицирована по результатам тестовой пересборки, после которой
> выполняется сравнение свежепересобранных пакетов с пакетами в репозитории.
> К письму приложен скрипт, который по логу сборки показывает "убывшие"
> имена библиотек - т.е. зависимости, которые присутствуют в репозитории,
> но отсутствуют после тестовой пересборки.  Это не очень совершенный метод
> идентификации потерянных зависимостей, и это лучшее, что у нас сейчас есть.
> Тем не менее, большую часть урезанных пакетов таким образом определить удаётся.

Поскольку не все devel-пакеты (пере)собраны, процесс оптимизации
зависимостей devel-пакетов ещё далек от завершения.  По мере этой
оптимизации неизбежно будут обнаруживаться пакеты, тестовая пересборка
которых будет выявлять урезание поддерживаемой конфигурации.

Я думаю, что теперь нам нужно в первоочередном порядке внедрять в
girar-builder инструмент для предотвращения непреднамеренных потерь
soname-зависимостей.

Если множество soname-зависимостей (без учета версионирования) всех
пакетов, собранных в рамках одного подзадания, не содержит хотя бы одной
soname-зависимости, которая присутствует во множестве soname-зависимостей
всех пакетов, полученных в результате сборки действующего релиза нашего
исходного пакета, то эта soname-зависимость либо изменилась (soname
change), либо потерялась.

Задания, прошедшие все проверки, в которых происходит подобное, я
предлагаю переводить в некое новое состояние ожидания подтверждения,
аналогичное TESTED.  Адресатам задания при этом должно приходить
соответствующее уведомление, на основании которого автор задания будет
смотреть, является ли столь существенное изменение зависимостей допустимым,
и принимать решение о подтверждении отправки этого задания в репозиторий.

Если удастся отличить случай изменения soname-зависимостей от потери
soname-зависимостей, то вероятность ложных срабатываний будет низкой.

Осталось придумать имя для нового состояния "waiting for manual confirmation",
и реализовать его.


-- 
ldv