Re: lug-bg: rpm

[Sava Chankov <sava@xxxxxxxxxxxxx>]

Sava Chankov wrote:
> Georgi Georgiev wrote:
> > Здравейте, Въпросът ми е следния: Може ли да ме насочите към
> > информация (за предпочитане на български) за това как може от сорсове
> > да си направя *.rpm файлове за Mandrake10.1? 
> Статията на Дядо Мец:
> http://linux-bg.org/cgi-bin/y/index.pl?page=article&id=advices&key=362985172 
Извинявам се, в тази статия не е обяснено. Тъй като на мен не ми е известен такъв източник на български, и може би поради тази причина много хора все още смятат пакетната система на Slackware за хитроумно изобретение :) ще се опитам да синтезирам опита си в изграждането на rpm пакети. 

Всъщност, всичко става в три прости стъпки:
1. Слагаш изходния код в /usr/src/packages/SOURCES
2. Съставяш си spec файл, който за удобство можеш да сложиш в /usr/src/packages/SPECS
3. С командата rpmbuild --ba /usr/src/packages/SPECS/твоя_spec_файл.spec се изграждат двоичният (.rpm) и изходният (.srpm) пакет. Желателно е винаги да си правиш и изходни пакети, защото така при обновяване на дистрибуцията можеш да ги престроиш с командата rpmbuild --rebuild твоя_изходен.srpm

От казаното дотук става ясно, че ако има някаква магия, тя е в т.2. Лесно е да я научиш, като разгледаш един spec файл от дистрибуцията ти: достатъчно е да инсталираш изходен (.srpm) пакет и вече ще имаш един такъв в /usr/src/packages/SPECS.

Ще разгледам един примерен spec файл, който аз съм написал за perl-XML-LibXML. Секциите са просто отделни логически части. Когато пиша spec файлове, ги разделям с нов ред за прегледност.  Файлът започва така:

#author: Sava

Name:           perl-XML-LibXML
Summary:        XML::LibXML - Perl Binding for libxml2
Version:        1.58
Release:        BB5
License:        Artistic/GPL
Group:          Development/Libraries/Perl
Source:         http://search.cpan.org/CPAN/authors/id/P/PH/PHISH/XML-LibXML-%{version}.tar.gz
Patch0:          XML-LibXML-SAX-parse_chunk.patch
BuildRoot:      %{_tmppath}/%{name}-%{version}-build
Requires:       perl = %{perl_version}, libxml2 >= 2.5, perl-XML-SAX >= 0.12
BuildRequires:  libxml2-devel zlib-devel

Редовете, започващи с диез, са коментари.

Name e името на пакета. Summary e кратко описание. Version е версията на ИЗХОДНИЯ КОД, Relеase - версията на пакета (т.е. на spec файла). Group e менюто, в което виждаш пакета в някой графичен инструмент за инсталиране на RPM. 
Source може да URL на изходния код или името на архива (спрямо/usr/src/packages/SOURCES). Ако Source е URL, но има файл XML-LibXML-%{version}.tar.gz в /usr/src/packages/SOURCES се използва файлът, ако не - той ще бъде изтеглен.
Patch e кръпка, която се прилага към изходния код след разархивирането му. Можеш да посочиш колкото ти трябват такива : Patch1, Patch2, ... Patch242,... Разбира се, кръпките не са задължителни.
BuildRoot е мястото, където се ИНСТАЛИРА пакета след компилация (иначе той се компилира в /usr/src/packages/BUILD). 
В Requires ръчно указваш от кои пакети зависи този пакет. По принцип пакетната система проследява зависимостите от динамични библиотеки по един доста примитивен начин - записва името на библиотечния файл. Така че ако не посоча изрично libxml2 >= 2.5, в зависимостите на пакета ще се запише автоматично Requires: /usr/lib/libxml2.so.2.6.7 . Ако бях на мястото на пакетната система, тук бих проверил кой пакет съдържа файла /usr/lib/libxml2.so.2.6.7 и бих записал него като зависимост (това може и да стане в някоя бъдеща версия на RPM).
В BuildRequires ръчно указваш кои пакети са необходими за изграждането. Така спестяваш разгадаването на съобщенията на configure скрипта (в програми, които го ползват - в този случай неговата роля играе командата perl Makefile.PL) като "libxml2 not found" въпреки, че е инсталиран, защото в случая наличието му се проверява като се компилира и свързва кратка програмка, включваща заглавни файлове от zlib-devel. Няма да казвам колко време ми отне, докато открия това в конкретния случай. Разбира се, повечето програми, които се пакетират, нямат такива странни зависимости.

Нещата от вида %{_tmppath} или %_tmppath са макроси на пакетната система, които се заместват със стойността си.  %{_tmppath} ще бъде заместен с /var/tmp/ на моята система. Има доста дефинирани такива - виждат се с командата rpm --showrc. Разликата между %{_tmppath} и %_tmppath, че първият вариант може да се използва непосредствено до друг текст.

Следващата секция от spec файла е 
%prep
%setup -q -n XML-LibXML-%{version}
%patch0

setup разархивира изходния код в /usr/src/packages/BUILD, а patch0 прилага patch0 от секцията с декларации. При дефинирани Patch1, ... Patch242 трябва да ги укажеш. Разбира се, не е нужно да прилагаш всички.

В следващата секция се изгражда кода:
%build
perl Makefile.PL
make
make test

Тъй като това е библиотека на perl, командите са по-особени. Най-общо казано, в нея се слагат командите, с които програмата се изгражда. Обикновено са указани в документацията и за повечето програми тази секция изглежда така:

%build
./configure --options=...
make


Следва секцията за инсталиране:
%install
rm -rf %buildroot
make DESTDIR=$RPM_BUILD_ROOT install_site
%perl_process_packlist

rm -rf %buildroot изтрива предишната временна инсталация в BuildRoot (ако има такава). Внимавай да не посочиш в BuildRoot кореновата директория, защото ако изграждаш пакета като суперпотребител в този момент ще имаш няколко секунди да кажеш "чао" на данните си. По принцип пакетите ЗАДЪЛЖИТЕЛНО се изграждат като обикновен потребител (поне аз правя така), не само заради този случай, но и защото кирливо написани (а не генерирани) Make файлове понякога не дефинират цел DESTDIR и всъщност инсталацията протича не в %buildroot, а в / , което цапа системата.

Следващата секция е 
%post
perl -MXML::SAX -e "XML::SAX->add_parser(q(XML::LibXML::SAX::Parser))->save_parsers()"
perl -MXML::SAX -e "XML::SAX->add_parser(q(XML::LibXML::SAX))->save_parsers()"

Тя се изпълнява от пакетната система СЛЕД инсталиране на пакета, докато %prep, %build и %install се изпълняват САМО при изграждането му. По принцип повечето пакети не се нуждаят от нея. В нея се слагат всякакви команди, които обикновено се изпълняват от под-цели make install след инсталацията. 

Секцията
%clean
rm -rf $RPM_BUILD_ROOT

се изпълнява след като пакетирането е приключило успешно. Понякога (а всъщност почти винаги в началото), когато пишеш нов spec файл, от него не успяваш да изградиш пакет от раз - примерно не си посочил всички файлове на пакета в секцията %files (виж по-надолу) и процесът на изграждане завършва аварийно. Ето защо е необходим rm -rf %buildroot в %install секцията.

В секцията %files се изброяват файловете и директориите, които инсталира пакета. Винаги съм се чудил защо е необходима - нали инсталацията протича в %{buildroot} ? Май това е направено за да можеш да инсталираш само избрани файлове. Обаче при съвременните дистрибуции подобен опит няма да е успешен от първия път - процесът на изграждане ще завърши с грешката "RPM build errors:    Installed (but unpackaged) file(s) found:". За да успееш да пакетираш само избрани файлове, трябва изрично да го посочиш в променлива на средата (коя точно оставям като упражнение за читателя).
За този пакет секцията изглежда така:
%files
%doc %_mandir/man3/*
%doc README Changes
%{perl_sitearch}/XML/*
%{perl_sitearch}/auto/XML/*
/var/adm/perl-modules/%{name}

Нужно е да поясня, че така посочваш файловете от %{buildroot}  - вижда се, че и уайлдокардовете вършат работа. %doc е макрос, който се грижи за документацията - в моята дистрибуция той ще сложи файловете README и Changes в 
/usr/share/doc/packages/името-на-пакета/
В последната секция поставям история на spec файла. Тя може да стои и на други места, примерно в началото, но по-пригледно накрая:

%changelog -n perl-XML-LibXML
* Fri Jan 14 2005 - sava@xxxxxxxxxxxxx
- require libxml2-devel for build

Добра практика е да подписваш пакетите, които изграждаш. Как става това Весо Колев е описал отлично на http://linux-bg.org/cgi-bin/y/index.pl?page=article&id=advices&key=362631501 , а ползата от подписването e огромна за сървъри в производство (Весо имаше отлична статия и за това, но за съжаление я е изтрил или не мога да я открия).

И накрая, след като си изградил и евентуално подписал пакета, е хубаво да го качиш в някое хранилище. В твоя случай най-добре да потърсиш на сайта на твоята дистрибуция къде има подходящо.

Разбира се, това кратко ръководство не е изчерпателно - има още хитрини като дефиниране на собствени макроси и  %if-%еlse конструкцията, но за тях някой друг път.

--
Sava Chankov                                     Сава Чанков
research and development                  проучване и развой
http://www.blueboard.biz                         блуборд оод
============================================================================
A mail-list of Linux Users Group - Bulgaria (bulgarian linuxers).
http://www.linux-bulgaria.org - Hosted by Internet Group Ltd. - Stara Zagora
To unsubscribe: http://www.linux-bulgaria.org/public/mail_list.html
============================================================================