Журнал LinuxFormat - перейти на главную

LXF155:RPM:

Материал из Linuxformat
(перенаправлено с «LXF154:RPM:»)
Перейти к: навигация, поиск
Подписка на печатную версию
Весь 2015 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)
Подписка на электронную версию
Весь 2015 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)
Подшивки старых номеров журнала (печатные версии)
Весь 2014 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)


Содержание

RPM: Сде­ла­ем па­кет са­ми

В ва­шей сис­те­ме най­дет­ся при­ло­же­ние, дос­той­ное сбор­ки? От­лич­но. По­то­му что мы с Оль­гой Хлоп­ко­вой при­сту­па­ем к соз­да­нию соб­ст­вен­но­го RPM-па­ке­та. Как пра­ви­ло, сбор­ка но­вых па­ке­тов – пре­ро­га­ти­ва раз­ра­бот­чи­ков ПО ли­бо ку­ра­то­ров-мейн­тейнеров, от­ве­чаю­щих за вы­пуск и под­держ­ку па­ке­тов. Од­на­ко пе­ре­краи­вание су­ще­ст­вую­ще­го па­ке­та – на­вык, по­лез­ный и сис­тем­но­му ад­минист­ра­то­ру: на­при­мер, ес­ли тре­бу­ет­ся пе­ре­со­брать RPM под необ­хо­ди­мую про­цес­сор­ную ар­хи­тек­ту­ру или ди­ст­ри­бу­тив, до­ба­вить в па­кет за­плат­ки или из­менить оп­ции уста­нов­ки.

RPM-па­кет: что внут­ри?

Ес­ли па­кет дво­ич­ный (рас­ши­рение rpm), в нем хра­нят­ся ском­пи­ли­ро­ван­ные под оп­ре­де­лен­ную ар­хи­тек­ту­ру фай­лы. Пра­ви­ла хо­ро­ше­го то­на и со­гла­шения об име­но­вании обя­зы­ва­ют ука­зы­вать ар­хи­тек­ту­ру, для ко­то­рой со­б­ран па­кет, в его на­звании. Па­кет со­дер­жит ис­пол­няе­мые фай­лы, кон­фи­ги, уста­но­воч­ные и необ­хо­ди­мые для уда­ления дей­ст­вия, а так­же ме­та­дан­ные со спи­ска­ми фай­лов, кон­троль­ны­ми сум­ма­ми и про­чей слу­жеб­ной ин­фор­ма­ци­ей.

Па­кет с ис­ходника­ми src.rpm со­дер­жит сред­ст­ва, необ­хо­ди­мые для сбор­ки дво­ич­но­го па­ке­та. В этом-то и за­клю­ча­ет­ся пре­лесть RPM – об­ла­дая src-па­ке­том, мож­но пе­ре­со­би­рать дво­ич­ный па­кет для раз­лич­ных це­ле­вых ар­хи­тек­тур и ди­ст­ри­бу­ти­вов!

Как пи­сать spec-файл

Spec-файл – файл спе­ци­фи­ка­ции RPM-па­ке­та с рас­ши­рением .spec. Иг­ра­ет клю­че­вую роль в пе­ре­сбор­ке па­ке­та и оп­ре­де­ля­ет ди­рек­ти­вы rpm для его уста­нов­ки и уда­ления. К нему ути­ли­та rpmbuild об­ра­ща­ет­ся во вре­мя по­строения при­ло­жения. Кста­ти, име­на spec-фай­лам при­ня­то да­вать по имени па­ке­та.

Ин­ст­рук­ции внут­ри spec-фай­ла раз­би­ты на сек­ции, раз­де­ляю­щие­ся сим­во­лом “ %”, и име­ют неза­мы­сло­ва­тый син­так­сис

имя по­ля: зна­че­ние

при­чем имя по­ля ре­гис­тро­не­за­ви­си­мо. Ком­мен­та­рии обо­зна­ча­ют­ся сим­во­лом “#”.

В spec-фай­лах мо­гут ис­поль­зо­вать­ся мак­ро­сы. Например:

%define Hello echo “Hello World”

%{hello}

Рас­смот­рим ти­по­вую струк­ту­ру про­стей­ше­го spec-фай­ла HelloWorld-1.0.spec. 

1. Summary: Hello World program

2. %define version 1.0

3. Name: HelloWorld

4. Version: %{version}

5. Release: 1

6. Copyright: GPL

7. Source: HelloWorld-1.0.tar.gz

8. Buildroot: /tmp/HelloWorldrpm

9. %prep

10. %setup

11. %build

12. ./configure

13. make

14. %install

15. make install

16. %clean

17. rm -rf $RPM_BUILD_ROOT

Сек­ция «За­го­ло­вок» (стро­ки 1 – 8) со­дер­жит основ­ные по­ля:

  • Summary – од­но­строч­ное опи­сание при­ло­жения.
  • Name, Version и Release – кри­тич­ны для ра­бо­ты при­ло­жения и долж­ны сов­па­дать с ин­фор­ма­ци­ей в на­звании RPM-па­ке­та.
  • Source – рас­по­ло­жение ар­хи­ва с ис­ходника­ми.
  • BuildRoot – путь, по ко­то­ро­му бу­дет со­би­рать­ся па­кет.

Сек­ция “prep” (стро­ки 9, 10) необ­хо­ди­ма для под­го­тов­ки ис­ходников к по­строению: в ней про­ис­хо­дит рас­па­ков­ка и на­ло­жение за­плат. В про­стых слу­ча­ях доста­точ­но мак­ро­са %setup.

По­сле под­го­тов­ки сле­ду­ет про­цесс сбор­ки. За него от­ве­ча­ет сек­ция с го­во­ря­щим на­званием “build” (стро­ки 11 – 13).

И вот, ста­дия сбор­ки прой­де­на, и мож­но при­сту­пить непо­сред­ст­вен­но к уста­нов­ке, за ко­то­рую от­ве­ча­ют ко­ман­ды сек­ции “install” (стро­ки 14, 15).

На­конец, в сек­ции “clean” (стро­ки 16, 17) очи­ща­ют­ся ка­та­ло­ги сбор­ки и уста­нов­ки.

Конеч­но, это да­ле­ко не все сек­ции, ко­то­рые мо­гут при­сут­ст­во­вать в spec-фай­ле, но для на­ча­ла вполне доста­точ­но.

От­ли­ча­ют­ся ли spec-фай­лы раз­ных ди­ст­ри­бу­ти­вов?

Да, и по­рой су­ще­ст­вен­но. Соб­ст­вен­ные мак­ро­оп­ре­де­ления, раз­ли­чия в на­звании по­лей, пра­ви­ла за­полнения сек­ций... Все это при­во­дит к несо­вмес­ти­мо­сти spec-фай­лов ме­ж­ду ди­ст­ри­бу­ти­ва­ми и необ­хо­ди­мо­сти их пре­об­ра­зо­вания. В Fedora, на­при­мер, от­сут­ст­ву­ет по­ле buildRoot: ме­сто сбор­ки при­ло­жения за­да­ет­ся по умол­чанию. Но ча­ще все­го разница ме­ж­ду spec-фай­ла­ми не кри­тич­на, а ис­прав­ление не отнима­ет мно­го вре­мени.

Техника безо­пас­но­сти

В сек­ции %install spec-фай­ла корневым ка­та­ло­гом мо­жет быть ука­зан /, и тогда стро­ка

rm -rf $RPM_BUILD_ROOT

из сек­ции %clean снесет ваш Linux пре­ж­де, чем вы пой­ме­те, что про­ис­хо­дит. Не так страш­но, но то­же ве­ро­ят­но: па­кет уста­но­вит­ся пря­мо в до­машний ка­та­лог %{_prefix} (/usr) и по­вре­дит фай­лы поль­зо­ва­те­ля.

Вы­вод оче­ви­ден: для манипу­ля­ций с тон­кой ма­те­ри­ей RPM-па­ке­тов не по­ме­ша­ет за­вес­ти но­во­го непри­ви­ле­ги­ро­ван­но­го поль­зо­ва­те­ля. По крайней ме­ре, не сто­ит со­би­рать па­ке­ты из-под root.

Что бу­дем со­би­рать?

При­ло­жение сто­роннего раз­ра­бот­чи­ка? Про­грам­му с де­сят­ком но­вых по­пра­вок? А мо­жет, соб­ст­вен­но­руч­но на­пи­сан­ный код? В лю­бом слу­чае нам по­тре­бу­ет­ся ар­хив tar.gz или tar.bz2 при­ло­жения, в ко­то­ром долж­ны на­хо­дить­ся ис­ходники и Makefile.

Ин­ст­ру­мен­та­рий

Что­бы при­сту­пить к соз­данию соб­ст­вен­но­го па­ке­та, нам по­тре­бу­ет­ся rpm-build – па­кет, со­дер­жа­щий ути­ли­ты и скрип­ты для сбор­ки RPM. Ес­ли вы не об­на­ру­жи­ли его в со­ста­ве ди­ст­ри­бу­ти­ва, не от­чаи­вай­тесь: он есть в ре­по­зи­то­ри­ях (еще один плюс RPM-па­ке­тов – их рас­про­странен­ность и доступ­ность).

В дальней­шем для сбор­ки RPM мы восполь­зу­ем­ся ути­ли­той rpmbuild, вхо­дя­щей в со­став это­го па­ке­та. Ес­ли вы со­би­рае­те RPM под Fedora, то вам по­на­до­бят­ся па­ке­ты Development Tools и rpmdevtools.

Го­то­вим по­ли­гон для сбор­ки

По умол­чанию пра­ва­ми для сбор­ки па­ке­тов об­ла­да­ет толь­ко root. Но ими мож­но на­де­лить и обыч­но­го поль­зо­ва­те­ля (це­ле­со­об­раз­ность дан­но­го ме­ро­прия­тия под­черк­ну­та вы­ше). Для это­го соз­да­ем в до­машней ди­рек­то­рии мак­рос .rpmmacros. За­пи­сы­ва­ем в этот файл ди­рек­ти­ву: %_topdir /home/username/BUILD_ROOT

Путь /home/username/ в секции %_topdir – домашний каталог. В нем бу­дет про­хо­дить сбор­ка.

Фи­наль­ный штрих в под­го­тов­ке поль­зо­ва­тель­ско-спе­ци­фич­но­го ок­ру­же­ния: для сбор­ки па­ке­тов нам тре­бу­ет­ся сле­дую­щая ие­рар­хия ка­та­ло­гов: 

BUILD_ROOT

- BUILD	rpmbuild про­во­дит здесь сбор­ку фай­лов при­ло­же­ния

- RPMS	rpmbuild хра­нит со­б­ран­ные дво­ич­ные RPM-па­ке­ты

- SOURCES	Вы по­ме­щае­те сю­да тар­бол­лы про­грамм для сбор­ки

- SPECS	Вы соз­дае­те здесь spec-фай­лы про­ек­тов для сбор­ки

- SRPMS	rpmbuild хра­нит здесь src.rpm-па­ке­ты

Поль­зо­ва­те­ли Fedora для соз­да­ния этой струк­ту­ры мо­гут вос­поль­зо­вать­ся ко­ман­дой

rpmdev-setuptree

Вруч­ную же это де­ла­ет­ся так:

mkdir ~/BUILD_ROOT/{RPMS,SRPMS,SPECS,SOURCES,BUILD}

Кста­ти, в ка­та­ло­ге RPMS во вре­мя сбор­ки, в за­ви­си­мо­сти от ар­хи­тек­ту­ры це­ле­вой сис­те­мы, ав­то­ма­ти­че­ски соз­да­дут­ся под­ка­та­ло­ги (на­при­мер, i386 или noarch).

Что ж, де­ре­во не­об­хо­ди­мых ка­та­ло­гов у нас име­ет­ся, ос­та­лось их за­пол­нить.

Ар­хив с ис­ход­ни­ка­ми прло­же­ния, ко­то­рое мы на­ме­ре­ны со­брать в RPM-па­кет, по­ме­ща­ем в пап­ку /SOURCES, а spec-файл – в ка­та­лог /SPECS. И у tar-ар­хи­ва, и у фай­ла спе­ци­фи­ка­ции долж­ны быть име­на оп­ре­де­лен­ной струк­ту­ры: на­зва­ние-вер­сия-ре­лиз.

rpmbuild: стро­им па­кет

Ба­зо­вый син­так­сис rpmbuild –

rpmbuild -bSTAGE package_name.spec

Оп­ция b ис­поль­зу­ет­ся для сбор­ки па­ке­та, а STAGE ука­зы­ва­ет за­вер­шаю­щую ста­дию сбор­ки. Для на­ча­ла вам мо­гут при­го­дить­ся сле­дую­щие зна­че­ния STAGE:

  • a – Сбор­ка дво­ич­но­го па­ке­та и па­ке­та с ис­ход­ни­ка­ми.
  • b – Сбор­ка толь­ко дво­ич­но­го па­ке­та RPM.
  • s – Сбор­ка толь­ко па­ке­та с ис­ход­ни­ка­ми src.rpm.
  • l – Про­вер­ка спи­ска фай­лов для па­ке­та с вы­во­дом оши­бок.

Уз­нать ос­таль­ные па­ра­мет­ры, как обыч­но, по­мо­жет оп­ция -help.

По­про­бу­ем со­брать па­кет из на­ше­го tar-ар­хи­ва HelloWorld-1.0.tar.gz и од­но­имен­но­го spec-фай­ла HelloWorld-1.0.spec:

rpmbuild -ba HelloWorld-1.0.spec

Cобрать па­кет для дру­гой ар­хи­тек­ту­ры мож­но таким об­ра­зом:

rpmbuild -ba --target i686 HelloWorld-1.0.spec

А вот как вы­гля­дит рас­про­стра­нен­ная ошик­бка, вы­да­вае­мая rpmbuild:

error: Installed (but unpackaged) file(s) found

Та­ким об­ра­зом rpmbuild со­об­ща­ет о най­ден­ных, но не упа­ко­ван­ных фай­лах. Ес­ли вы не хо­ти­те вклю­чать их в ар­хив, до­бавь­те в на­ча­ло spec-фай­ла стро­ку

%define _unpackaged_files_terminate_build 0

В про­тив­ном слу­чае пе­ре­чис­ли­те фай­лы в сек­ции %files.

По­сле соз­да­ния па­ке­та очи­стим ди­рек­то­рии сбор­ки и ус­та­нов­ки при­ло­же­ния:

rpmbuild --clean HelloWorld-1.0.spec

За­гля­ни­те в ди­рек­то­рии RPMS и SRPMS: ес­ли сбор­ка про­шла глад­ко, там поя­вят­ся со­от­вет­ст­вен­но дво­ич­ный па­кет и па­кет ис­ход­ни­ков.

Па­кет го­тов. Что даль­ше?

Наш RPM со­б­ран – ос­та­лось его про­тес­ти­ро­вать. Ус­та­нав­ли­ва­ет­ся па­кет ко­ман­дой rpm:

rpm -i HelloWorld-1.0.rpm

Ес­ли в сис­те­ме при­сут­ст­ву­ет бо­лее ста­рая вер­сия па­ке­та, вос­поль­зуй­тесь оп­ци­ей -U для об­нов­ле­ния. Поя­ви­лось же­ла­ние сде­лать про­цесс ин­стал­ля­ции бо­лее ин­фор­ма­тив­ным? В со­че­та­нии с эти­ми оп­ция­ми ис­поль­зуй­те -hv и на­сла­ж­дай­тесь кон­соль­ным про­гресс-ин­ди­ка­то­ром:

rpm -ihv HelloWorld-1.0.rpm

Preparing... ############################# [100%]

1: HelloWorld ############################# [100%]

Для уда­ле­ния па­ке­та пред­на­зна­че­на оп­ция -e. В ар­се­на­ле про­грам­мы rpm мас­са по­лез­ных средств, сре­ди ко­то­рых – про­вер­ка вер­сии ус­та­нов­лен­но­го па­ке­та, элек­трон­ной под­пи­си и це­ло­ст­но­сти.

Те­перь, ко­гда вы ос­вои­ли азы и го­то­вы по­сти­гать тон­ко­сти па­ке­то­строе­ния, пе­ред ва­ми от­кры­ва­ют­ся мно­го­чис­лен­ные воз­мож­но­сти: на­строй­ка ба­зы дан­ных RPM, скрип­тинг па­ке­тов или да­же соз­да­ние соб­ст­вен­ных ре­по­зи­то­ри­ев RPM.

Име­но­ва­ние RPM-фай­лов

Тра­ди­ци­он­но име­на RPM-па­ке­тов име­ют сле­дую­щий фор­мат: на­зва­ние-вер­сия- ре­лиз.[ар­хи­тек­ту­ра|noarch|src].[rpm|rpms]

На­при­мер: clamav-0.95.2-4.rh7.rf.i386.rpm.

Как не­труд­но до­га­дать­ся, ес­ли вме­сто кон­крет­ной плат­фор­мы ука­зы­ва­ет­ся “noarch”, то со­дер­жи­мое па­ке­та плат­фор­мо­не­за­ви­си­мо. Как пра­ви­ло, та­кие па­ке­ты со­дер­жат ин­тер­пре­ти­руе­мые скрип­ты, до­ку­мен­та­цию, GUI-над­строй­ки для дру­гих при­ло­же­ний. Пост­фикс .src.rpm ука­зы­ва­ет­ся для па­ке­та с ис­ход­ным ко­дом.

Шаг за шагом: Это легче, чем может показаться

1 Но­вый поль­зо­ва­тель

За­хо­дим в кон­соль от имени root, что­бы за­ре­ги­ст­ри­ро­вать но­во­го поль­зо­ва­те­ля. Для это­го пред­на­зна­че­на ко­ман­да useradd (в неко­то­рых ди­ст­ри­бу­ти­вах – adduser). Ана­ло­гич­но, для уда­ления ис­поль­зу­ет­ся deluser (или userdel).

2 Мак­рос

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


3 Ие­рар­хия ка­та­ло­гов

Ути­ли­той mkdir соз­да­дим в до­машнем ка­та­ло­ге ие­рар­хию ди­рек­то­рий, необ­хо­ди­мую для сбор­ки RPM-па­ке­тов.

4 Фай­лы — по мес­там

По­сле под­го­тов­ки струк­ту­ры ка­та­ло­гов ко­пи­ру­ем tar-ар­хив про­грам­мы, ко­то­рую мы планиру­ем по­мес­тить в RPM-па­кет, в пап­ку SOURCES. Spec-файл по­ме­ща­ем в пап­ку SPECS.

5 Сбор­ка па­ке­та

Со­бе­рем па­кет ути­ли­той rpmbuild. По хо­ду ра­бо­ты она вы­во­дит в кон­соль эта­пы вы­полнения. В и­тоге успеш­ной сбор­ки в ка­та­ло­ге RPMS ока­жет­ся дво­ич­ный па­кет, а в SRPMS – па­кет с ис­ходника­ми! И вправду легко.

Тер­ми­но­ло­гия па­ке­то­строения

  • RPM (ак­роним от RPM Package Manager) – менед­жер па­ке­тов RPM, ис­поль­зуе­мый во мно­гих ди­ст­ри­бу­ти­вах (Red Hat, Suse, Fedora, ASP, Alt Linux, CentOs и др.). Так­же под RPM под­ра­зу­ме­ва­ют са­ми RPM-па­ке­ты. При­ня­то счи­тать па­кет дво­ич­ным, ес­ли не уточнено, что в нем со­дер­жат­ся ис­ходники и не ука­зан пост­фикс src.rpm.
  • Spec-файл (файл спе­ци­фи­ка­ции) – тек­сто­вый файл с рас­ши­рением .spec, необ­хо­ди­мый ути­ли­те rpmbuild и оп­ре­де­ляю­щий дей­ст­вия при по­строении при­ло­жения.
  • rpmbuild – ути­ли­та для сбор­ки па­ке­тов, как дво­ич­ных, так и с ис­ход­ным ко­дом. Вхо­дит в со­став па­ке­та rpm-build.
  • NVR (name-version-release) – по­ля имени, вер­сии и ре­ли­за в фай­ле спе­ци­фи­ка­ции. Цен­траль­ная ча­сть сек­ции опи­сания. На ос­но­ве данных этих по­лей выполня­ет­ся кон­троль вер­сий и за­ви­си­мо­стей па­ке­та.
  • Ба­за дан­ных RPM – БД ди­ст­ри­бу­ти­ва, содержащая ин­фор­ма­цию обо всех па­ке­тах, уста­нов­лен­ных в сис­те­ме. На­хо­дит­ся в пап­ке /var/lib/rpm.
Источник — «http://wiki.linuxformat.ru/wiki/index.php?title=LXF155:RPM:&oldid=16531»
Персональные инструменты
купить
подписаться
Яндекс.Метрика