[devel] I: Механизм отображения сборочного окружения на зависимости (was: mplayer q)

[Aleksey Avdeev]

led на altlinux.ru пишет:
> Friday, 23 November 2007 17:54:09 Денис Смирнов написав:
>> On Thu, Nov 22, 2007 at 03:04:48PM +0200, Led wrote:
>>
>> L> Предположим, завтра новая libcairo, слинкованная с libdirectfb-1.2 уйдёт
>> в L> сизиф. Вроде всё красиво? А ldd mplayer будет показывать
>> libdirectfb-1.1 + L> libdirectfb-1.2, как будет работать и будет ли -
>> неизвестно. Твои L> предложения?
>>
>> Хороший вопрос. Ты прав.
>>
>>>> Не, речь именно о том, чтобы rpm при сборке (вернее verify_elf)
>>>> обматерил пакет. Вплоть до вывода в STDERR той строчки conflicts,
>>>> которую человеку надо добавить в spec.
>> L> Ещё раз - посмотри всё дерево библиотек, которое использует mplayer
>> прямо (это L> ещё как-то можно отследить, но с ними и так всё нормально
>> разруливается по L> сонеймам), и косвено (их намного больше) - как их
>> предлагаешь "отслеживать"? L> разве что постоянно , внимательно читать
>> cyber-talks@ и анализировать КАЖДЫЙ L> обновлённый пакет: а не влияет ли он
>> КОСВЕНО на mplayer?
>>
>> Это должен делать робот, или не делать никто.
> 
> Т.е. робот должен заворачивать вполне корректный пакет mplayer из-за разнобоя, 
> вносимых legacy-библиотеками в репозитарии? И будет заворачивать до тех пор, 
> пока "вдруг" этот разнобой каким-то образом, случайно исчезнет? Или я просто 
> неправильно тебя понял?
> 
>> L> ИМХО если библиотека обновилась - нужно срочно пересобрать ВСЁ, что с
>> ней L> слинковано - либо роботом, либо уведеомлением мейнтейнера через
>> багзиллу. L> Ориентироваться на возможность "точечного обновления"
>> непродуктивно, для этих L> редких и нетривиальных случаев есть бэкпорты и
>> бэкпортирование как таковое L> (хотя с переходом на git оно может "кануть в
>> Лету" или быть на порядок L> затруднено).
>>
>> Увы, как я говорил, работоспособность точечных обновлений необходима. В
>> противном случае apt можно просто выбросить за ненадобностью.
> 
> Наверное, иногда необходима... Я просто думал, что вариант с бэкпортами 
> подойдёт для таких редких случаев. Но, возможно, я и неправ...
> 
>> L> Практика legacy-библиотек в репозитарии вносит беспорядок,
>> непредсказуемые L> проблемы (как видно на примере mplayer) и отнимает время
>> у мейнтейнеров для L> их сборки и поддержки.
>>
>> А с этим я полностью согласен. Только ты предлагаешь использовать это
>> чтобы замаскировать другую проблему.
> 
> И с этим я полностьб согласен:) Я прелагаю это, потому как пока не вижу других 
> решений :(

  Может стоит придумать механизм трансляции текущего сборочного
окружения на зависимости?

  Например так (в порядке бреда ;-)):

1. После сборки пакета с некоим нечто (библиотекой/приложением, назовём
nameAAA для определённости) получаем список пакетов содержащих
библиотеки, с которыми собираемое слинковано по факту:

а) Бинарникам кладущимся в пакет делается ldd для определения списка
lib* с которыми они слинкована по факту.

б) По списку библиотек определяем список пакетов их предоставляющий.
Пусть это будут nameBBB, nameCCC, ... nameDDD.

2. Используя полученный на предыдущем шаге список, в создаваемый пакет
добавляем пачку рrovides специального вида: %name-rnameBBB,
%name-rnameCCC, ... %name-rnameDDD (с версиями данных пакетов). Этот шаг
позволит позволит языком понятным для rpm/apt сохранить информацию о
том, с чем собственно мы собрались по факту. (Данная информация нам
потребуется на следующем шаге.)

3. Создаём список уточняющих requires, которые будут говорить что нам
нужна не просто libBBB, а libBBB собранная с libCCC нужной версии:

а) Для списка пакетов nameBBB, nameCCC, ... nameDDD получаем список
предоставляемых рrovides вида nameBBB-rnameССС, ... nameBBB-rnameXXX,
... nameDDD-rnameYYY (эту информацию сохранил шаг 2, выполненный при
сборке данных пакетов).

б) Фильтруем данный список на предмет нахождения в нём библиотек с
которыми наше nameAAA слинковано. В частности
name*-rname{BBB,ССС,...DDD} это пример того, что мы ищем, а всякие
name*-rname{XXX,...ZZZ} -- ненужный, в данный момет, мусор.

в) Дополняем список requires найденными name*-rname{BBB,ССС,...DDD} с
версиями соответствующих, использованных при сборке (!),
name(BBB,ССС,...DDD}, возможно не тех, что найдены в рrovides данных
пакетов (это то, ради чего всё и затеяно).

  После работы данного алгоритма на выходе, для нашего nameAAA будем
иметь следующие requires:

1. name{BBB,ССС,...DDD} соответствующих версий (как это происходит сейчас)

2. name{BBB,ССС,...DDD}-rname{BBB,ССС,...DDD} с версиями соответствующих
name{BBB,ССС,...DDD}, с которыми эти name{BBB,ССС,...DDD} должны быть
собраны для корректной работы нашего nameAAA.

  Соответственно, если некоторого nameBBB-rnameССС-Y предоставлено не
будет -- nameAAA не встанет, пусть даже в репозетарии существует
nameBBB, предоставляющий nameBBB-rnameССС-X (т. е. собранный с
nameССС-X, а не с nameССС-Y как нам для nameAAA нужно).

  Недостатки такого решения, что вижу сразу:

1. Алгоритм не спасёт от случая использования 2х библиотек с разной
версией третьей, если эта третья в сборке конечного продукта не
участвует. (На данный случай алгоритм достаточно просто можно расширить.)

2. Рост бызы rpm/apt.

-- 

С уважением. Алексей.


----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : signature.asc
Тип     : application/pgp-signature
Размер  : 544 байтов
Описание: OpenPGP digital signature
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20071125/a7130492/attachment-0002.bin>