clicman писал(а):Хмм.. конечно php я собрал, но чтобы сборка заработала пришлось странные вещи делать.
Например:
BuildRequires: lib64enchant-devel
Как итог - сборка работает только под x64
При этом, если взглянуть на спеку php из официального репозитория, там в BuildRequires архитектура не фигурирует.
Что я делаю не так?
Сейчас объясню подробно. В BuildRequires указываются зависимости сборки, которые вычисляются на основе данных Provides других пакетов. Имя пакета входит в Provides, но также туда входят и другие значения, часть из которых прописывается вручную, а часть генерируется автоматически (алгоритмы там разные и в такие детали сейчас углубляться не будем).
Вот вывод списка Provides для 32-битного пакета libenchant-devel из платформы 2012.1:
Код: Выделить всё
$ rpm -q libenchant-devel --provides
devel(libenchant)
enchant-devel = 1.6.0-5
pkgconfig(enchant) = 1.6.0
libenchant-devel = 1.6.0-5:2012.1
А вот аналогичный список для 64-битной версии пакета:
Код: Выделить всё
$ rpm -q lib64enchant --provides
devel(libenchant(64bit))
enchant-devel = 1.6.0-5
pkgconfig(enchant) = 1.6.0
lib64enchant-devel = 1.6.0-5:2012.1
1. Первым в списке идёт автоматически сгенерированная архитектурно-зависимая запись. Как правило, этот формат Provides/Requires используется только самим RPM для определения зависимостей собранных devel-пакетов, чтобы не прописывать весь список зависимостей вручную.
2. Вторым в списке идёт прописанная вручную архитектурно-независимая запись. В спеках это выглядит так:
Provides: %{name}-devel = %{EVRD}
или так:
Provides: %{name}-devel = %{version}-%{release}
%{EVRD} - это макрос, включающий кроме Version и Release ещё значения Epoch и Distepoch. Для некоторых пакетов в Provides указывают ещё lib%{name}-devel (хотя лучше так не делать, т.к. это только вносит путаницу, но такое встречается).
3. Далее идёт автоматически сгенерированная архитектурно-независимая запись. pkgconfig(enchant) генерируется на основе имени файла в пакете: /usr/lib/pkgconfig/enchant.pc (/usr/lib64/pkgconfig/enchant.pc для 64-битного пакета).
Именно этот формат наиболее предпочтительно использовать в BuildRequires. Если же такой Provides у пакета отсутствует (*.pc файлы есть не во всех пакетах), то использовать значение из п.2. В целом логика такая: архитектурно-независимые предпочтительнее архитектурно-зависимых, сгенерированные автоматически предпочтительнее прописанных вручную.
4. И последним идёт автоматически сгенерированная архитектурно-зависимая запись. Она формируется на основе имени пакета.
Если внимательно посмотреть на список, то видно, что у некоторых Provides отсутствует информация о версии и релизе, а у некоторых о релизе. Более того, значение версии pkgconfig(...) записей берётся из содержимого *.pc файла, так что в некоторых случаях может отличаться от тэга Version, указанного в спеке. Хотя обычно это баг, а не фича. Ну да ладно, теории и так уже достаточно, дальше ещё много можно о нюансах написать, но это уже перебор для форума будет.
В данном конкретном случае с lib64enchant-devel в Марафоне рекомендую заменить BuildRequires на pkgconfig(enchant).
P.S. Для того, чтобы посмотреть имя пакета по Provides, есть команда:
urpmq --whatprovides (например, urpmq --whatprovides "pkgconfig(enchant)").