LINUX.ORG.RU

Как собрать пакет из src.rpm ?

 ,


1

1

Добрый вечер. я наткнулся на оф. сайте на файл keepass-2.47-34.13.src.rpm Решил его собрать. Пошерстив на эту тему нашёл несколько вариантов по этому поводу:

  1. https://blog.onedollardata.com/how-to-install-src-rpm-packages-in-opensuse/
  2. https://www.linuxquestions.org/questions/linux-software-2/how-do-i-install-an-src-rpm-in-suse-173270/

В обоих случаях, вижу команду: rpmbuild –rebuild package_name.src.rpm Запускаю её у себя. Читаю.. Написано, что мол «This will create a RPM, normally located in /usr/src/packages/………» Но как понять отработала эта команда вообще? Создала ли она rpm-пакет?

Сделай проще, поставь mock, дефолтные настройки могут подойти, по умолчанию он должен собирать под твою систему, на всякий случай открой архиватором *.src.rpm и загляни в *.spec, бывает надо подправить. Когда закончишь эксперименты, просто удали mock и почисть от него /var/lib/mock и /var/cache/mock, тогда в системе ничего не останется.

papin-aziat ★★★★ ()
Ответ на: комментарий от hozman

Так а те команды, которые по моим ссылкам вообще не актуальные?

Нормальные команды, просто собирать будешь на своей системе, а mock тебе сделает это в chroot и без черной магии, всё чистенько, изолировано, впрочем, если пакетик без особых сборочных зависимостей, то фиг с ним, но моком всё равно будет проще.

mock keepass*.src.rpm --resultdir=/path/result

и всё, идешь в каталог result и забираешь keepass*.rpm

Если подправил spec, то

mock keepass*.src.rpm --resultdir=/path/result --spec=/path/keepass.spec

если надо добавить зависимость для сборки в мок, которой нет в репозитории, то

mock --install foo.rpm
mock -n keepass*.src.rpm

А вообще, его можно прикольно настроить, но ради одного пакета не стоит.

papin-aziat ★★★★ ()

В смысле как понять? Оно вообще то кучу всего в оутпут напишет. В том числе и какие пакеты были созданы и где лежат. Я через rpmbuild -ba собираю, собирается в хомяке, без /usr’ов.

anonymous ()
Ответ на: комментарий от papin-aziat

В итоге в этой ветке ни слова о реальном способен сборки пакета из src.prm. Как это сделать? Как я понимаю нативно никак? Если завируалить Центос, федору или Редхат и там собрать? Что предпочтительнее? Имею ввиду, какой пакет из тех систем более подходящ для Суса?

hozman ()
Ответ на: комментарий от hozman

Если завируалить Центос, федору или Редхат и там собрать?

Точняк, вариант, накати контейнер, туда mock.

Почитай: https://github.com/rpm-software-management/mock/wiki#mock-inside-podman-fedora-toolbox-or-docker-container

И ещё скажи ему собирать под сусю, варианты смотри в /etc/mock, например

mock -r opensuse-leap-15.2 your.src.rpm
papin-aziat ★★★★ ()
Ответ на: комментарий от hozman

Ну как, обычно так:

wget https://official.site/app.source.tar.gz
tar -xf app.source.tar.gz
cd app-source
./configure --help
./configure --prefix=/opt/app --disable-debug
make
sudo make install
sudo ldconfig

Предварительно нужно все сборочные и рабочие зависимости установить. Их можно подглядеть в спеках (src.rpm). А если deb based и прога есть в репах (но не той версии или глючная, например) то есть команда установки сборочных зависимостей sudo apt build-dep app без пляски с src.rpm

Для cmake:

wget https://official.site/app.source.tar.gz
tar -xf app.source.tar.gz
cd app-source
mkdir -p build && cd build
cmake .. -LH (список опций)
cmake .. -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/opt/app
make
sudo make install
sudo ldconfig

Для meson:

wget https://official.site/app.source.tar.gz
tar -xf app.source.tar.gz
cd app-source
meson --help
mkdir -p build && cd build
meson .. --prefix=/opt/app -Dbuildtype=release -Ddebug=false -Dstrip=true
ninja
sudo ninja install
sudo ldconfig
anonymous ()
Ответ на: комментарий от hozman

В итоге в этой ветке ни слова о реальном способен сборки пакета из src.prm. Как это сделать?

Тебе же дали ссылку на ALT вики. Была где-то инструкция для SUSE, но сейчас найти не могу (свой OBS пиарят). src.rpm пересобирается во всех rpm дистрах примерно одинаково и легко. Так что можешь почитать инструкции для Fedora (там самая лучшая документация). Для каждого дистра есть такая документация, даже для Mageia. Но мне кажется рановато тебе еще. И главное зачем? Поищи для начала готовый пакет (только не на помойках).

anonymous ()
Ответ на: комментарий от anonymous

Вот для Mageia, например https://www.opennet.ru/openforum/vsluhforumID15/4629.html#3

Вкрадце: устаналиваются зависимости из src.rpm, устанавливается src.rpm в хомяк (не под root!), команда пересборки, установка получившегося rpm (пакетным менеджером из под root). Имей в виду, при обновлении системы твой пакет может замениться системным, имеет смысл подправить версию. Но ты рискуешь поломать что-нибудь в системе. Так как это ставится все в системный /usr

команда пересборки

Выполняются те самые опции, что я давал в посте выше. Только на автомате. То что в спеках записано.

src.rpm можно сразу установить из под root, тогда сборка будет проходить в /usr/local/src вроде бы.

anonymous ()

Прочитать вывод команды, посмотреть содержимое /usr/src/packages не вариант?

ЕМНИП, в случае ошибок в конце будет ″RPM build errors:″.

mky ★★★★★ ()
Ответ на: комментарий от papin-aziat

Извиняюсь за задерку ответа. Я замотался эти дни. Вот на этой странице https://keepass.info/download.html можно увидеть пакет для openSUSE_Tumbleweed Вот ссылка на этот репозитрий https://download.opensuse.org/repositories/Mono/openSUSE_Tumbleweed/src/ В принципе, я уже использую такую же программу с более современным дизайном keepassxc Хотя, конечно, интересно науится собирать эти пакеты.

hozman ()
Ответ на: комментарий от ZenitharChampion

Я это уже проходил. Вот что вижу в терминале:

Victor@localhost:~> cd /home/Victor/Downloads/
Victor@localhost:~/Downloads> sudo zypper search rpmbuild

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

    #1) Respect the privacy of others.
    #2) Think before you type.
    #3) With great power comes great responsibility.

[sudo] password for root: 
Sorry, try again.
[sudo] password for root: 
Retrieving repository 'Main Update Repository' metadata .............................[done]
Building repository 'Main Update Repository' cache ..................................[done]
Loading repository data...
Reading installed packages...
No matching items found.
Victor@localhost:~/Downloads> 

hozman ()
Ответ на: комментарий от hozman

Да, без проблем собрался пакет, могу тебе его закинуть куда-нибудь, или сам раздобудь рхел или федору и сделай несколько команд.

sudo dnf install mock -y
mock -r opensuse-tumbleweed-x86_64 --init
mock -r opensuse-tumbleweed-x86_64 keepass-2.47-34.20.src.rpm

Всё! Пакет будет лежать в

/var/lib/mock/opensuse-tumbleweed-x86_64/result
papin-aziat ★★★★ ()
Ответ на: комментарий от papin-aziat

Предыдущий раз вы предлагали собрать пакет в CentOS, но в ним какой-то головняк в KVM. Интернета нет. Хотя, всё что кроме него устанавливал, везде всё в порядке. В итоге только что установил Fedora. Я вчитался в команду:

mock -r opensuse-tumbleweed-x86_64 --init

Откуда вы взяли opensuse-tumbleweed-x86_64 ? Как я понял, это опция. Какая из опций в мане в данном случае используется? Ман, если не в терминале можно посмотреть по ссылке http://rpm.pbone.net/manpage_idpl_28340461_numer_1_nazwa_mock.html, как я понимаю. Так же интересно, почему здесь нужна лишь команда –init ? Кроме того, по ссылке https://fedoraproject.org/wiki/Using_Mock_to_test_package_builds я вижу, что процесс сборки пакета происходит как-то совсем иначе:

mock -r <configfile> --rebuild package-1.2-3.src.rpm

или вот так:

mock package-1.2-3.src.rpm

Это ещё больше пугает..

hozman ()
Ответ на: комментарий от ZenitharChampion

То есть, тебе нужен в точности такой же пакет, только keepassxc, а не просто keepass?

На самом деле, не обязательно. Я лишь хочу понять, как собирать пакеты. Реально удобно научится. Не всегда в наличии пакеты для определённой системы. Поэтому собирать пакет весь полезный навык.

hozman ()
Ответ на: комментарий от hozman

Предыдущий раз вы предлагали собрать пакет в CentOS

Без разница — рхел, центос или федора.

Откуда вы взяли opensuse-tumbleweed-x86_64 ?

$ ls /etc/mock/opensuse-*
/etc/mock/opensuse-leap-15.1-aarch64.cfg
/etc/mock/opensuse-leap-15.1-x86_64.cfg
/etc/mock/opensuse-leap-15.2-aarch64.cfg
/etc/mock/opensuse-leap-15.2-x86_64.cfg
/etc/mock/opensuse-tumbleweed-aarch64.cfg
/etc/mock/opensuse-tumbleweed-i586.cfg
/etc/mock/opensuse-tumbleweed-ppc64.cfg
/etc/mock/opensuse-tumbleweed-ppc64le.cfg
/etc/mock/opensuse-tumbleweed-x86_64.cfg

Так же интересно, почему здесь нужна лишь команда -init ?

Да можно и без --init, наверно, просто разбил на два этапа, сначала инициализация чрута под целевую платформу, а потом сборка в нём.

я вижу, что процесс сборки пакета происходит как-то совсем иначе: mock -r configfile –rebuild package-1.2-3.src.rpm

<configfile> — это и есть целевая платформа, а --rebuild — опция по умолчанию, можно не писать.

или вот так: mock package-1.2-3.src.rpm

Так ты соберешь пакет для платформы по умолчанию, если ничего не настраивать, то будет собрано под хост, вот так посмотреть:

ls -l /etc/mock/default.cfg

У меня рхел-8, твой keepass собрался без проблем, я заглядывал в keepass.spec: зависимостей немного, все они простые, и что-то сусе-специфичное, всё хорошо кароче.

papin-aziat ★★★★ ()
Последнее исправление: papin-aziat (всего исправлений: 1)
Ответ на: комментарий от hozman

В общем с нуля с моком не просто разобраться, как и во всём, что касается шаляпных дистров, вот такая специфика, ну нет у них одного большого вики про всё(тут арч никто не переплюнет, да), зато, немного наловчившись, будь уверен — обязательно всю инфу найдешь.

Надо понять, что мок работает в чрут, то есть в систему ничего для сборки не попадает, только сам мок, потом можно его удалить и почистить за ним

sudo rm -rf /var/lib/mock
sudo rm -rf /var/cache/mock

всё!

По умолчанию он собирает под текущую систему, но можно настроить довольно гибко, в том числе с добавлением сторонних репозиториев, для начала надо выбрать нужную платформу в /etc/mock, кстати, работает автодополнение

$ mock -r open<TAB><TAB>
openmandriva-4.1-aarch64       openmandriva-rolling-x86_64
openmandriva-4.1-armv7hnl      opensuse-leap-15.1-aarch64
openmandriva-4.1-i686          opensuse-leap-15.1-x86_64
openmandriva-4.1-x86_64        opensuse-leap-15.2-aarch64
openmandriva-cooker-aarch64    opensuse-leap-15.2-x86_64
openmandriva-cooker-armv7hnl   opensuse-tumbleweed-aarch64
openmandriva-cooker-i686       opensuse-tumbleweed-i586
openmandriva-cooker-x86_64     opensuse-tumbleweed-ppc64
openmandriva-rolling-aarch64   opensuse-tumbleweed-ppc64le
openmandriva-rolling-armv7hnl  opensuse-tumbleweed-x86_64
openmandriva-rolling-i686   

Настроить платформу по умолчанию так

sudo ln -sf opensuse-tumbleweed-x86_64 default.cfg

Кастомизируется мок в

/etc/mock/site-defaults.cfg

Все возможные опции(они же настройки по умолчанию) смотреть в

/usr/share/doc/mock/site-defaults.cfg

Запутаться можно, только если надо добавить в чрут сторонние пакеты для сборки, тем более, если ты их сам и собираешь, ибо мок перед началом работы и в конце(даже неудачном) очищает чрут, а в начале ещё и директорию result, ну, ясно почему. Поэтому надо либо настроить result в другое место, тогда он тупо будет туда складывать, либо не забывать опцию --resultdir=/path/to/your-result-dir.

А вот с установкой пакетов веселее. Подкинуть пакет в чрут

mock -i package1-devel.rpm

Он их не вычистит после первого захода, а вот для сборки надо сказать ему, чтобы не чистил перед началом работы

mock -n package.src.rpm

Если поправил спек, то

mock --spec=/path/to/package.spec package.src.rpm

Вроде этого хватит, если без затей.

papin-aziat ★★★★ ()
Ответ на: комментарий от papin-aziat

А вот с установкой пакетов веселее. Подкинуть пакет в чрут

mock -i package1-devel.rpm

По сути, пакет я собрал. Многие моменты понял. Но это странно. Ведь, если пакет собран зачем нам это нужно? Разве нельзя установить как обычно менеджером пакетов? В том же openSUSE это zypper. Ведь команду: mock -i package1-devel.rpm В openSUSE я не выполню т.к. пакета mock там нет..

Он их не вычистит после первого захода, а вот для сборки надо >сказать ему, чтобы не чистил перед началом работы

mock -n package.src.rpm

Тоже не однозначно. Если я в Федоре собираю пакет под openSUSE зачем это нужно?

hozman ()
Последнее исправление: hozman (всего исправлений: 1)
Ответ на: комментарий от hozman

Ведь, если пакет собран зачем нам это нужно?

Смотри, тебе бы хватило моего первого поста с тремя командами, дальше я просто изложил для общей картины, ибо этот mock не сразу заходит, всё таки инструмент не для хомяков.

Это случай, когда чего-то в репах, о которых «знает» мок, нет, вот и всё. В твоём случае это не пригодиться скорее всего, так как у суси, видимо, богатые репы.

Разве нельзя установить как обычно менеджером пакетов? В том же openSUSE это zypper.

Мок находится в chroot, он всё своё носит с собой, общее у него с хостом только ядро, так думать правильно. Вот смотри

[me@my ~]$ ls /
BAKS  boot  etc   lib    lost+found  mnt  proc  run   srv  tmp  var
bin   dev   home  lib64  media       opt  root  sbin  sys  usr
[me@my ~]$ mock --shell
<mock-chroot> sh-4.4# ls /
bin   builddir  etc   installation-homedir  lib64  mnt  proc  run   srv  tmp  var
boot  dev       home  lib                   media  opt  root  sbin  sys  usr

В openSUSE я не выполню т.к. пакета mock там нет..

Мы говорим о сборке под федорой-шляпой-центос

Если я в Федоре собираю пакет под openSUSE зачем это нужно?

 -n, --no-clean        do not clean chroot before building

Забей, не пригодиться, если в репах суси всё есть.

papin-aziat ★★★★ ()