Определение пакетов с зависимостями для разрабатываемого ПО

1.

По выхлопу ldd ищешь so, правильно

Далее, вместо rpm -q попробуй yum provides. Ищет во всех пакетах в репозиториях, а не только локально.

(Для собранных пакетов лежащих в репозатории так же полезными будут команды pkcon get-depends, pkcon get-requires . Не помню точно, есть ли packagekit в centos/rhel )

2.

Имхо, только анализ исходного кода и систем сборки. Далее ищешь соответствующие пакеты в своем дистре

2.
Имхо, только анализ исходного кода и систем сборки. Далее ищешь соответствующие пакеты в своем дистре

Спасибо за советы, я попробую.

А нельзя вытащить из gcc или из make какой-нибудь лог, чтобы увидеть все хедеры, с которыми он по умолчанию компилирует тот или иной объектник?

да, существует. dpkg-depcheck

есть OBS, он открыт, там при сборе пакета ему прописываться зависимости сами, даже ругают елси сам будешь писать

https://build.opensuse.org/package/binary/openSUSE:Factory/Mesa?arch=x86_64&a...

вот спек
https://build.opensuse.org/package/view_file/openSUSE:Factory/Mesa/Mesa.spec?...

Как узнать какие библиотеки нужны для компиляции? Вопрос сложный, ведь многое зависит от параметров с которыми ты будешь собирать, их все ровно нужно знать, единственное что может помогать это pkg-config, с ним не нужно заучивать и прописывать полные имена пакетов, если мне нужен libudev я просто напишу
BuildRequires: pkgconfig(libudev)
а не
BuildRequires: libudev-devel
мне все ровно как будет называться этот пакет, главное что есть
пакет который предоставляет
pkgconfig(libudev)
причем это pkgconfig(libudev) прописываться тоже само.
https://build.opensuse.org/package/binary/Base:System/systemd?arch=i586&f...

По первому вопросу читай http://www.rpm.org/max-rpm-snapshot/s1-rpm-depend-auto-depend.html, rpmbuild все делает автоматически и в Requires нужно прописывать только неявные зависимости.

По второму посмотри http://people.redhat.com/~rjones/auto-buildrequires/. Нашел только что по 'yum search rpmbuild', поэтому как работает сказать не могу.

поэтому как работает сказать не могу.

Делает dlsym на open и execve, пишет имена файлов в журнал, потом ищет их в локальной базе rpm. То есть если devel пакеты установлены, auto-buildrequires должен красиво напечатать BuildRequires после сборки пакета.

Даже описав проблему на нескольких форумах, ты проблему не решишь. Чем может тебе mock, имхо, непонятно. Я тебе уже сказал, что нужно бы Makefile'ы смотреть.

По второму посмотри http://people.redhat.com/~rjones/auto-buildrequires/.

Круто, это же знаменитый разработчик libguestfs.

Делает dlsym на open и execve, пишет имена файлов в журнал, потом ищет их в локальной базе rpm. То есть если devel пакеты установлены, auto-buildrequires должен красиво напечатать BuildRequires после сборки пакета.

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

Спасибо за ответ, в следующий раз спрашиваю только на Лоре :)

Про mock тоже не знаю, действительно слышу о нём впервые.

Я не спорю, что вся полезная информация должна содержаться в Makefile. Но часто он большой и написанный чужой рукой, и, с моей точки зрения, не позволяет очевидным образом понять, какой devel пакет или что-то там ещё скрывается за каждым параметром типа -l*******. Ведь ******* - это, как правило, surname библиотеки. Здесь до конца не ясны ни имя, ни версия.

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

Не, на SEX'e тоже быстро и часто по делу отвечают =)

... какой devel пакет или что-то там ещё скрывается за каждым параметром типа -l*******. Ведь ******* - это, как правило, surname библиотеки. Здесь до конца не ясны ни имя, ни версия.

Здесь не совсем понятно, чего ты хочешь добиться. Вдолбить зависимостей по максимуму?

Спасибо, очень интересно. Но не совсем понятно, как им пользоваться? Надо скачать этот образ и поставить его на хард?

А если мне надо собирать, например, в окружении (с репозиториями) RHEL/CentOS 6.4, чтобы завиcимости потянулись от них? Или даже если у меня репозиторий с самосборными (пересобранные из src.rpm) пакетами?

Здесь не совсем понятно, чего ты хочешь добиться. Вдолбить зависимостей по максимуму?

Наверное, да! Просто заполнить соответствующие поля в spec файле, чтобы и rpm нормально встал, и src.rpm пересобрался у других.

завтра буду изучать. Если всё это так, то это просто выдающийся инструмент.

Но основную задачу, как я понял, он не решает, так как devel пакеты уже должны быть установлены. Можно попробовать поправить, чтобы искал отсутствующие файлы в базе репозитория.

Также есть вопросы по кол-ву ложных срабатываний.

Круто, это же знаменитый разработчик libguestfs.

Подписался на http://rwmj.wordpress.com/.

А нельзя вытащить из gcc или из make какой-нибудь лог, чтобы увидеть все хедеры, с которыми он по умолчанию компилирует тот или иной объектник?

Поделюсь тем, как я вижу ситуацию. Я так понимаю, исходные данные: некий проект, для которого есть исходники, и которых хочется собрать и опакетить. Во-первых, нужно разделять сборку проекта и «опакечивание». Второе является специфичной для дистрибутива задачей, а первое - для проекта.

Я обычно делаю так. Нужно собрать проект при штатном окружении дистрибутива, имеется ввиду без установки зависимостей костылями вида make install, а только пакетным менеджером. Предполагаю, что собирается наиболее часто используемым способом. Поэтому итеративно запускаю ./configure && make, и выписываю все ошибки которые относятся к зависимостям - ненайденные хедеры, unreferenced link. Ищу по именам функций, хедеров и другим особенностям гуглом и yum provides <что>(поддерживает маски wild card), если не знаю, к какому пакету в данном дистрибутиве относится зависимость. Ставлю нужный, yum install <needs>-devel. В случае отсутствия пакета в дистре - гуглю усЕрднее, и, если ничего выяснить не удается, то приходится зависимость тоже опакечивать. Ну вот, в итоге у меня полчился список зависимостей для проекта, и они уже установлены, проект собирается. Теперь, даже не указывая BuildRequires в spec файл, ты можешь сделать rpmbuild -ba <proj>.spec и rpm соберется. Далее, как указали выше, понадобится auto-buildrequires в дополнении к составленному списку зависимостей. Пишу список BuildRequires в spec.

Причем, как уже заметили, зависимости автоматически попадают в rpm. Ты можешь убедиться в этом, зайдя в .rpm файл как в архив, например Midnight Commander-ом, и посмотрев файл INFO/REQUIRENAME - там будут указаны зависимости твоего пакета, в том числе те, которые автоматически нашлись. Для регулировки версий зависимостей и неявных - нужно Requires в spec.

И читай еще раз и еще больше мануалов и доков по всем командам, включая ./configure --help проекта. Все нюансы я в посте не охвачу конечно же, да и не знаю

Спасибо за подробное объяснение, да, примерно так я и сам стараюсь собирать пакеты. В целом не хватало лишь такого инструмента, как auto-buildrequires.

Ещё раз спасибо всем, кто помогал.

Для первой проблемы пришлось написать небольшой скрипт, развивающий предложенный подход - запросы к rpm базе и рекурсивное определение зависимостей.

Для второй проблемы хорош auto-buildrequires, хоть и работает не идеально.