hasher сборка не src.rpm

[gBopHuk]

Прочёл много документации так и не понял можно ли hasher'ом собирать не src.rpm пакеты, а допустим из обычных тарболлов ?

[Jinn]

Можно, но это равносильно сборке двигателя через выхлопную трубу.
Проще завернуть тарбол в src.rpm и собирать по технологии.

[Meatcoins]

Прочёл много документации так и не понял можно ли hasher'ом собирать не src.rpm пакеты, а допустим из обычных тарболлов ?

А-а-а!!!  ;D
Вот я тоже с этим ОЧЕНЬ долго парился!!!  ;D
Прочитал всё с altlinux.org - ничего не понятно!!!  ;D
Не понятно что откуда берётся и зачем оно надо - непонятная документация!
Вот как собирать пакеты из tar.bz:

Код: [Выделить]

[me@Linux ~]$ cd RPM
[me@Linux RPM]$ cd SPECS
[me@Linux SPECS]$ ls
botinok.spec  hello2.spec  hello.spec  hello.spec~  hodkonem.spec
[me@Linux SPECS]$ rpm -bb hello.spec
Выполняется(%prep): /bin/sh -e /home/me/tmp/rpm-tmp.91407
+ umask 022
+ /bin/mkdir -p /home/me/RPM/BUILD
+ cd /home/me/RPM/BUILD
+ cd /home/me/RPM/BUILD
+ rm -rf hello-1.0
+ /bin/mkdir -p hello-1.0
+ cd hello-1.0
+ echo 'Source #0 (hello.tar.bz2):'
Source #0 (hello.tar.bz2):
+ /bin/bzip2 -dc /home/me/RPM/SOURCES/hello.tar.bz2
+ /bin/tar -xf -
+ /bin/chmod -c -Rf u+rwX,go-w .
+ exit 0
Выполняется(%build): /bin/sh -e /home/me/tmp/rpm-tmp.91407
+ umask 022
+ /bin/mkdir -p /home/me/RPM/BUILD
+ cd /home/me/RPM/BUILD
+ cd hello-1.0
+ make
make: Entering directory `/home/me/RPM/BUILD/hello-1.0'
g++ -c hello.cpp -o hello.o
g++ -o hello hello.o
make: Leaving directory `/home/me/RPM/BUILD/hello-1.0'
+ exit 0
Выполняется(%install): /bin/sh -e /home/me/tmp/rpm-tmp.96807
+ umask 022
+ /bin/mkdir -p /home/me/RPM/BUILD
+ cd /home/me/RPM/BUILD
+ /bin/chmod -Rf u+rwX -- /home/me/tmp/hello-buildroot
+ /bin/rm -rf -- /home/me/tmp/hello-buildroot
+ cd hello-1.0
+ mkdir -p /home/me/tmp/hello-buildroot/usr/bin
+ cp hello /home/me/tmp/hello-buildroot/usr/bin
+ /usr/lib/rpm/brp-alt
Cleaning files in /home/me/tmp/hello-buildroot (auto)
Verifying and fixing files in /home/me/tmp/hello-buildroot (binconfig,pkgconfig,libtool)
Compressing files in /home/me/tmp/hello-buildroot (auto)
Verifying ELF objects in /home/me/tmp/hello-buildroot (arch=normal,fhs=normal,rpath=normal,stack=normal,textrel=normal,unresolved=normal)
Stripping binaries in /home/me/tmp/hello-buildroot (executable,shared)
Обрабатываются файлы: hello-1.0-alt1
Поиск Provides (используя /usr/lib/rpm/find-provides)
Выполняется(Provides): /bin/sh -e /home/me/tmp/rpm-tmp.19411
+ umask 022
+ /bin/mkdir -p /home/me/RPM/BUILD
+ cd /home/me/RPM/BUILD
+ /usr/lib/rpm/find-provides
find-provides: running scripts (alternatives,lib,pam,perl,pkgconfig,python,shell)
+ exit 0
Поиск Requires (используя /usr/lib/rpm/find-requires)
Выполняется(Requires): /bin/sh -e /home/me/tmp/rpm-tmp.52360
+ umask 022
+ /bin/mkdir -p /home/me/RPM/BUILD
+ cd /home/me/RPM/BUILD
+ /usr/lib/rpm/find-requires
find-requires: running scripts (files,lib,pam,perl,pkgconfig,pkgconfiglib,python,rpmlib,shebang,shell,static,symlinks)
+ exit 0
Requires: /lib/ld-linux.so.2, libc.so.6(GLIBC_2.0), libc.so.6(GLIBC_2.1.3), libstdc++.so.6(CXXABI_1.3), libstdc++.so.6(GLIBCXX_3.4), rtld(GNU_HASH)
Поиск unpackaged files (используя /usr/lib/rpm/check-files)
Выполняется(check-files): /bin/sh -e /home/me/tmp/rpm-tmp.54470
+ umask 022
+ /bin/mkdir -p /home/me/RPM/BUILD
+ cd /home/me/RPM/BUILD
+ /usr/lib/rpm/check-files
+ exit 0
Записан: /home/me/RPM/RPMS/i586/hello-1.0-alt1.i586.rpm
[me@Linux SPECS]$ cat hello.spec
Name: hello
Version: 1.0
Release: alt1

Summary: hello
License: GPL
Group: Network

Url: www.URL.ru
#Source: %name-%version-%release.src.rpm
Source: %name.tar.bz2
BuildArch: i586
Packager: Me <me@email.ru>

%description
Hello World!

%prep
%setup -c hello

%build
#g++ -o hello hello.cpp
make

%install
mkdir -p $RPM_BUILD_ROOT/usr/bin
cp hello $RPM_BUILD_ROOT/usr/bin

%files
/usr/bin/hello
[me@Linux SPECS]$ cd ..
[me@Linux RPM]$ ls
BUILD  log  RPMS  SOURCES  SPEC  SPECS  SRPMS
[me@Linux RPM]$ cd SOURCES
[me@Linux SOURCES]$ ls
botinok-1.0.tar.gz  hello.tar.bz2  hodkonem-1.0.tar.bz2
[me@Linux SOURCES]$ cd ..
[me@Linux RPM]$ cd RPMS/i586
[me@Linux i586]$ ls
hello-1.0-alt1.i586.rpm
[me@Linux i586]$ cd ..
[me@Linux RPMS]$ cd ..
[me@Linux RPM]$ cd SRPMS
[me@Linux SRPMS]$ ls
botinok-1.0-alt1.src.rpm  hello-1.0-alt1.src.rpm  hodkonem-1.0-alt1.src.rpm
[me@Linux SRPMS]$Надо почитать только про SPEC'ки.
 :) :) :)
Hasher вообще не нужен для сборки пакетов!
Он нужен только для их тестирования в изолированной среде, чтоб не ставить всё на реальный Linux.

[NotHAM]

...
Hasher вообще не нужен для сборки пакетов!
Он нужен только для их тестирования в изолированной среде, чтоб не ставить всё на реальный Linux.

Вот только ерунду такую не нужно говорить.

Создаём хашерницу:
1.$ hsh --init ~/каталог_хашера
В каталоге ~/каталог_хашера/chroot/... будет создан мини-линукс, в котором можно работать,
как в обычном линуксе, не захламляя основную систему ничем (обычно ненужными devel).

2.$ hsh-install ~/каталог_хашера mc rpm-utils  ## Теперь там есть почти всё, что нужно...

Далее уходим в хашер ("логинимся") и "осматриваемся", чтобы понять, куда мы попали...
3.$ hsh-shell ~/каталог_хашера
4.$ cd ~/RPM
5.$ mc

Тут следует иметь в виду, что в хашере ваш логин - builder, а не "Вася пупкин",
и что ваша домашняя директория вовсе не /home, а /usr/src, других отличий пожалуй нет.

Чтобы уйти из хашера - просто делаем ...
$ exit

Теперь можно установить в хашер всё необходимое для сборки...
6.$ hsh-install ~/каталог_хашера <список пакетов из спека по зависимостям>

Далее закидываем в хашер (в каталог .../chroot/.in/...) исходники, спек и что ещё
нужно (если нужно), делаем
7.$ hsh-shell ~/каталог_хашера
8.$ mc      # сейчас окажемся в /chroot/.in/
перекидываем всё что закинули в /usr/src/RPM/куда_нужно (в домашнюю директорию),
и, как обычно, находясь в /usr/src/RPM/SPECS делаем
9.$ rpm -ba ... (-bb, -bi), или buildreq -bi...(-ba...)
Если облом (чего-то не хватает, обычно какой нибудь ...devel)
10. $ exit
И повторяем начиная с п. 6 пока не получится.

Итого - имеем полноценную сборочную среду и основная система ничем не
захламлена.
Чтобы очистить хашерницу - повторяем $ hsh --init ~/каталог_хашера,
или просто удаляем из под рута  ~/каталог_хашера

[andrew_b]

Зачем всё это, все эти заходы в хэшер с последующими выходами? Почему нельзя собрать src.rpm в системе (rpm -bs --nodeps foo.spec. Правда, тут могут возникнуть нераскрывшиеся макросы, что потребует установки некторых devel-пакетов в систему), а потом просто собрать этот src.rpm командой hsh?

[NotHAM]

Зачем всё это, все эти заходы в хэшер с последующими выходами? Почему нельзя собрать src.rpm в системе (rpm -bs --nodeps foo.spec. Правда, тут могут возникнуть нераскрывшиеся макросы, что потребует установки некторых devel-пакетов в систему), а потом просто собрать этот src.rpm командой hsh?

Можно конечно, но после сборки большого количества пакетов, особенно с непересекающимися
зависимостями, на систему страшно смотреть делается, да и меняются эти devel довольно
регулярно, обновлений требуют. (Поначалу и сам так делал, потом отказался ..., и не жалею.)

А так среда обычно всегда "свежая", да и сделать её довольно просто, и...

...
Итого - имеем полноценную сборочную среду и основная система ничем не
захламлена.
...

[Skull]

Прочёл много документации так и не понял можно ли hasher'ом собирать не src.rpm пакеты, а допустим из обычных тарболлов ?

Через gear — легко. Правда, нужно импортировать через gear-update.

[NotHAM]

author=Skull link=topic=7433.msg103635#msg103635 date=1277109734]
...
Через gear — легко. Правда, нужно импортировать через gear-update.

Да. Легко. Но однажды столкнулся с проблемой (примерно год назад).
Собирал Tux Commander с нуля. Сделал именно так (из тарбола). Gear-update отработал
нормально, но gear-hsh отказался работать (начал выделываться на предмет того, что все
исходники подготовлены якобы для i386, хотя там про это ни слова, и в спеке ошибок вроде
не наделал). Выручил именно hsh-shell, там с помощью rpm -ba... всё собралось и после
этого проблем больше не было. Src.rpm были впоследствии съедены хашером без претензий,
и вытащеный из них (src.rpm) тарбол gear-update с последующим gear-hsh воспринял уже нормально.
Почему - так и не понял.

[Meatcoins]

Вот только ерунду такую не нужно говорить.

Мелкие пакеты без зависимостей можно и без hasher'а собрать.

[NotHAM]

...
Мелкие пакеты без зависимостей можно и без hasher'а собрать.

Да. Можно. Даже сравнительно крупные можно (темы например, где нет бинарников).
Недавно именно так собирал тему WinClassic2 для icewm, но в хашернице как-то
спокойнее (имхо). Есть уверенность, что основная система ничем не будет
захламлена. У меня Гном 2.28 с ноября - и в системе нет ни одного ...-devel
пакета, и вообще нет ничего лишнего (кроме плейеров. hi!), зато хашерницу
приходится пересоздавать примерно раз в неделю. Но это дело вкуса.  ;)

И ещё - сидя на сизифе легко могу сделать пакет для бранча 5.1 (р5, 4.1), это
зависит от того, откуда хашерница инициализируется (apt-get-ом), при этом
основная система совершенно не повреждается.

[gBopHuk]

Всё, понял, Хэшер это тупо среда, а вот внутри неё пользуемся обычными средствами сборки. Вот только проблема возникла: захотел я собрать dockbarx это плагин такой на Гном-панель, так этот Хэшер попросил поставить в него всю Графическую систему. Как-нибудь можно это обойти?

[NotHAM]

Всё, понял, Хэшер это тупо среда, а вот внутри неё пользуемся обычными средствами сборки.
...

Почти так, но не совсем. Это инструмент, который собирает всё с помощью
rpm... в изолированной среде.
Что, впрочем, не мешает использовать его как среду для ручной сборки.  :)

...
так этот Хэшер попросил поставить в него всю Графическую систему. Как-нибудь можно это обойти?

Это не хашер попросил, а rpm (точнее gcc). Проблема, скорее всего в зависимостях (spec).
Такое может быть, если проект сделан на паскале (tuxcmd например). Тут нужно
точно знать зависимости (buildreq... бесполезен - всю систему может затребовать).
А может Вы его запустить в хашере попытались? Или установить?

[kostyalamer]

Чувствую без меня тут не обойдется  ;) . Анатолий, твой способ конечно хорош, но есть кое-какие нюансы.
Я действую немного по другому, поскольку пакечу в основном собственные проги то для сборки пользуюсь
Etersoft-build-utils и buildreq до кучи, что и советую делать всем кто пакетит свои программы . Дело в том что все необходимое итак ставится в систему при их написании.
После того как вы собрали (думаю не с первого захода) свои пакеты командой rpm -ba блабла.spec, закидываем готовую src-ху в hasher и если Вы не в тиме ( а если в тиме зачем глупые вопросы задавать  :P )
hsh --no-sisyphus-check блабла.src.rpm. Идем пьем кофе и если сборочные зависимости у вас правильные и интернет более-менее быстрый  то через некоторое время пакеты собираются.
Но это еще не все , это только означает что ваш пакет может собрать другой человек в своей системе на том же бранче, и не более того.
А вот теперь самое интересное берем minimal от NotHAM ( ставим его в виртуалку или на раздел диска ) и туда пытаемся поставить ваш *.rpm. Весьма вероятно что сразу обломаетесь напоровшись на проблемы с зависимостями. ( кстати у меня минималка устанавливается минут за 20, не многим больше чем собираются пакеты в хашере ). Чешете репу, ставите на нее пакеты вручную, добиваясь того что rpm  у вас поставится.
После чего идете в основную систему, добавляете зависимости в спек  и собираете все по-новой  ;)
Потом берете свежую минималку и снова ставите пакет. В результате будет понятно что пакет не только можно пересобрать (hasher), но он еще и будет работать  :D.
Если бы Альтовские мантейнеры пользовались подобным алгоритмом ( проверкой на минимале ), проблем у пользователей было бы гораздо меньше, а так иногда хочется им руки оторвать ( не пользователям, понятно а мантейнерам   ;) )

[kostyalamer]

Вообще конечно документация по сборке пакетов у нас не того, я пока разбирался с этим безобразием
кроме родного: http://www.altlinux.org/%D0%A1%D0%B1%D0%BE%D1%80%D0%BA%D0%B0_%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2_(etersoft-build-utils)
http://www.altlinux.org/Buildreq
http://www.altlinux.org/Spec
http://www.altlinux.org/Hasher/%D0%A0%D1%83%D0%BA%D0%BE%D0%B2%D0%BE%D0%B4%D1%81%D1%82%D0%B2%D0%BE
глядел сюда:
http://www.lexpr.ru/node/11
http://bog.pp.ru/work/rpm.html
http://www.linuxcenter.ru/lib/articles/system/rpm_guide.phtml
и сюда до кучи
http://forum.lissyara.su/viewtopic.php?f=47&t=19213
 Есть у нас на форуме еще совершенно "позорная" тема http://forum.altlinux.org/index.php/topic,927.0.html, где 2 умных человека пытались научить 3-его весьма неглупого этому делу. ( правда близко к сердцу принял обучение только Drool, а Алексей по-моему ограничивался легким стебом ), хотел я на нее эпитафию написать ( Геннадий и Алексей  совсем ушли с форума, а топикстартер обиделся и тоже не появляется) , о том как не надо учить людей, но руки так и не дошли  ;)

[NotHAM]

... Чешете репу, ставите на нее пакеты вручную, добиваясь того что rpm  у вас поставится.
После чего идете в основную систему, добавляете зависимости в спек  и собираете все по-новой  ;)
...

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

Альтовские майнтейнеры в 99.9% случаев всё делают правильно. Всё, что нужно для
нормальной работы пакета, обычно проставляется автоматически при сборке
пакета за редчайшим исключением (типа каких-то плагинов к чему нибудь).
А вот сборочные зависимости - в основном проблема майнтейнера, при неправильных
пакет не соберётся.
Простой пример - pcmanfm2. Собран вполне корректно. Работает нормально.
Но без gvfs - не может ходить по ftp. Требуется доустановка. По зависимостям не
подтягивает. Так что ж теперь - принудительно ставить эту gvfs на машины, которые
не подключены к сети (интернету)? Да не нужна она там вовсе. Всё правильно
сделано. Неправильно тогда, когда в подобной ситуации не выдаётся никаких
сообщений (рекомендаций, предупреждений), а это уже на совести разработчика.