[devel] rpm 4.0.4-alt82

Alexey Tourbin =?iso-8859-1?q?at_=CE=C1_altlinux=2Eru?=
Пн Янв 14 22:56:15 MSK 2008


On Mon, Jan 14, 2008 at 10:00:45PM +0300, Dmitry V. Levin wrote:
> > Я пока воспринимаю ещё как экспериментальную.  Хотелось бы замутить
> > пересборку сизифа с 4.0.4-alt82 и потом проверить/обсудить, устраивает
> > ли нас новая схема зависимостей или нет.
> 
> Это ещё актуально?  Сейчас заканчивается очередная тестовая пересборка,
> можно попробовать.

Я думаю что там всё нормально, если только сама идея "цементировать"
или "наращивать" зависимости между подпакетами за счёт файловых
зависимостей не вызывает возражений.

Вот нетривиальный пример того, какой эффект даёт это "цементирование".

В пакете valgrind-devel-3.2.3-alt1.i586.rpm
имеется файл /usr/lib/pkgconfig/valgrind.pc
в котором имеется строка
Libs: -L${libdir}/valgrind/x86-linux -lcoregrind -lvex -lgcc

Здесь речь идёт о зависимостях на файлы
/usr/lib/valgrind/x86-linux/libcoregrind.a
/usr/lib/valgrind/x86-linux/libvex.a

Эти зависимости обнаруживаются с помощью pkgconfiglib.req.

Старый алгоритм поведения pkgconfiglib.req был такой:
поскольку эти файлы обнаружены под $RPM_BUILD_ROOT, то ничего не делать,
потому что как бы "внешнех зависимостей" нет.  Куда эти файлы будут
запакованы и будут ли они запакованы вообще, it's up to maintainer.

Новый алгоритм pkgconfiglib.req такой: ok, ставим файловую зависимость
на эти файлы, то есть
Requires: /usr/lib/valgrind/x86-linux/libcoregrind.a
Requires: /usr/lib/valgrind/x86-linux/libvex.a

Если эти файлы запакованы в тот же самый пакет, что и файл
/usr/lib/pkgconfig/valgrind.pc, то rpm оптимизирует (удалит)
эти Requires зависимости.  В противном случае зависимости останутся --
появляется требование, что эти файлы должны быть куда-то запакованы
(имеется в виду, что они должны быть запакованы в один из подпакетов,
на которые распилен пакет valgrind, но в точности передать имеено эту
семантику нельзя).

Правда в данном случае состоит в том, что файлы
/usr/lib/valgrind/x86-linux/libcoregrind.a
/usr/lib/valgrind/x86-linux/libvex.a
запакованы в другой пакет -- valgrind-tool-devel-3.2.3-alt1.i586.rpm.

То есть у пакета valgrind-devel появится косвенная зависимость на
valgrind-tool-devel, через файловые зависимости (которые можно понимать
почти что как обычные виртуальные зависимости).

Но пакет valgrind-tool-devel в свою очередь явно зависит от пакета
valgrind-devel (с точностью до = %version-%release).

Получается, что эффект "цементирования" как бы "нарушает" оригинальный
замысел maintainer'а отпилить два *-devel пакета.  С другой стороны,
этот оригинальный замысел допускает "прокол": можно установить пакет
valgrind-devel, но при этом нельзя слинковаться через valgrind.pc,
потому что не хватает соответствующих библиотек, которые были отпилены
в другой подпакет.  То есть "цементирование" теперь запрещает
незамкнутые зависимости между подпакетами.
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип     : application/pgp-signature
Размер  : 197 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20080114/a7b7122a/attachment-0002.bin>


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