Jak utworzyć pakiet RPM
- 3123
- 82
- Tacjana Karpiński
RPM to zarówno menedżer pakietów, jak i format pakietu używany przez wiele dystrybucji Linux, takich jak Fedora, Red Hat i Centos, do zarządzania oprogramowaniem i rozpowszechnianiem oprogramowania w formie binarnej. W tym samouczku zobaczymy, jak budować i pakować prostą aplikację.
W tym samouczku nauczysz się:
- Jakie są podstawowe koncepcje procesu budowania RPM.
- Jakie jest środowisko kompilacji.
- Co to jest.
- Jak używać makr w specyfiku.
- Jak zainstalować zależności kompilacji.
- Jak utworzyć specyl.
- Jak zbudować pakiet RPM.
Zastosowane wymagania i konwencje oprogramowania
| Kategoria | Wymagania, konwencje lub wersja oprogramowania |
|---|---|
| System | Fedora 29 |
| Oprogramowanie | Nie dotyczy |
| Inny | Uprzywilejowany dostęp do systemu Linux jako root lub za pośrednictwem sudo polecenie do zainstalowania potrzebnych pakietów. |
| Konwencje | # - Wymaga, aby podane polecenia Linux są wykonywane z uprawnieniami root bezpośrednio jako użytkownik root lub za pomocą sudo Komenda$ - Wymaga, aby podane polecenia Linux zostały wykonane jako zwykły użytkownik niepewny |
Podstawowe koncepcje RPM

Instalowanie, usuwanie, aktualizacja (jednym słowem, zarządzanie) Oprogramowanie jest niezbędnym zadaniem w każdym systemie operacyjnym. Kiedy menedżerowie pakietów nie byli rzeczą, jedynym sposobem na zainstalowanie programu było opracowanie jego kodu źródłowego i umieszczenie uzyskanych plików w odpowiednich miejscach na system pliku. Śledzenie zależności każdego kawałka kodu było naprawdę trudne i czasochłonne. Następnie wprowadzono menedżerów opakowań i wszystko stało się łatwiejsze.
Każda nowoczesna dystrybucja Linux ma obecnie jego kierownik pakietu: Debian i jego pochodne używają dpkg, chwilaRPM jest używany w rodzinie dystrybucji Red Hat. Oprogramowanie jest dostarczane wstępnie kompilowane w formie pakiety, które są zasadniczo skompresowane archiwa zawierające metadane dotyczące wersji oprogramowania, jej zależności i możliwych konfliktów z innymi pakietami.
W tym samouczku zobaczymy, jak utworzyć pakiet RPM, począwszy od kodu źródłowego aplikacji. Aplikacja, którą zapakujemy Feh, Prosty przeglądarka obrazu wiersza poleceń: jest dość mały i ma niewiele zależności. Przed rozpoczęciem budowania naszego pierwszego pakietu istnieją jednak pewne podstawowe pojęcia, które powinniśmy zrozumieć.
Środowisko kompilacji
Korzeniem drzewa środowiska kompilacji RPM jest rpmbuild katalog, który zawiera 6 podwodników: ZBUDOWAĆ, Buildroot, RPM, Źródła, OKULAR I SRPMS. Zobaczymy, jak można wygenerować to środowisko, uruchamiając proste polecenie; Na razie wspomnijmy o roli tych katalogów. Oto reprezentacja drzewa roboczego:
rpmBuild |- Build |- Buildroot |- RPMS |- Źródła |- specyfikacje |- SRPMS
Każdy z tych katalogów ma szczególną rolę w procesie budowania:
-
ZBUDOWAĆKatalog jest miejscem, w którym zbudowano kod źródłowy programu, który chcemy pakować -
BuildrootKatalog jest miejscem, w którym kopiowane są pliki wynikające z kompilacji oprogramowania wewnątrz katalogu kompilacji, odzwierciedlając strukturę systemu docelowego wewnątrz podkładu z pakietem MAME:
W naszym przypadku binarna „feh”, która zostanie zainstalowana w/usr/binzostanie zgłoszony jako Buildroot/FeH-3.0-1.FC29.x86_64/usr/bin. -
RPMkatalog jest miejscemRPMPakiety są generowane: Każda obroty zostanie umieszczone w podwodnicy
nazwany na cześć jego architektury lub,NoarchJeśli nie jest to specyficzne dla architektury. -
ŹródłaDirektory hostuje skompresowany kod źródłowy oprogramowania, który chcemy zapakować, często w formie tarball z pliku zip. -
OKULARkatalog, to miejsce, w którym umieszczamy.SpecPlik z instrukcjami budowania naszego pakietu: za chwilę przeanalizujemy strukturę tego pliku. -
SRPMSKatalog jest odpowiednikiem RPM, ale dla źródłowych RPM. Te specjalne pakiety zawierają oryginalny kod źródłowy aplikacji, ewentualne łatki i specyfile używane do budowy pakietu.
Plik specyfikacji
Plik, w którym zdefiniowane są wszystkie instrukcje i informacje potrzebne do zbudowania pakietu RPM, to .Spec plik. Specile zawiera, między innymi, buduj zależności (oprogramowanie potrzebne do skompilowania programu, który chcemy zapakować), Zależności w czasie wykonywania (Biblioteki potrzebne do poprawnego uruchomienia programu) i Ommands, które należy wykonać, aby skompilować oprogramowanie.
Plik składa się z dwóch makro-sekcji: a preambuła i ciało. W każdej z tych sekcji można określić różne instrukcje. Zobaczmy niektóre z nich. preambuła Sekcja może zawierać następujące instrukcje:
-
- Nazwa: Nazwa podstawy pakietu (powinna to pasować do nazwy pliku specyfikacji)
- Wersja: Wersja upstream pakowanego oprogramowania
- Uwolnienie: Numer wydania pakietu
- Licencja: Licencja używana do oprogramowania, które chcemy pakować
- URL: URL oprogramowania powyżej oprogramowania
- Źródło 0: Bezpośredni adres URL lub ścieżka skompresowanego kodu źródłowego oprogramowania (plik tarball lub zapinany)
- Buildarch: Architektura pakietu: Jeśli nie zostanie określona architektura, zostanie użyty jeden z systemów hosta
- BuildRequires: Zależności potrzebne do zbudowania oprogramowania
- Wymaga: Zależności potrzebne do uruchomienia oprogramowania
ciało Sekcja specyl, zazwyczaj zawiera następujące sekcje:
- %opis: Opcjonalnie wieloletni opis pakowanego oprogramowania
- %przygotowanie: Polecenia potrzebne do przygotowania kodu źródłowego (na przykład polecenia potrzebne do wyodrębnienia tarball)
- %zbudować: Polecenia potrzebne do zbudowania oprogramowania
- %zainstalować: Polecenia potrzebne do skopiowania pliku wynikającego z procesu kompilacji do
Buildrootinformator - %akta: Lista plików dostarczonych przez pakiet, które zostaną zainstalowane w systemie
Makra
Aby złagodzić naszą pracę, wewnątrz pliku, możemy użyć niektórych makr, które pozwalają nam odwoływać się do wielu przydatnych rzeczy i automatycznie wykonywać określone zadania. Przede wszystkim mamy Makra katalogu RPM które pozwalają korzystać z katalogów naszego środowiska kompilacji; Zawsze powinniśmy ich używać zamiast bezpośrednich ścieżek:
- %_ topdir: To makro odnosi się do
rpmbuildinformator - %_ builddir: Odniesienia
ZBUDOWAĆkatalog wewnątrz naszego drzewa kompilacji - %_ rpmdir: Odniesienia do ścieżki
RPMinformator - %_ quenicedir: To makro jest oceniane na ścieżkę
Źródłainformator - %_ specdir: Makro, które reprezentuje ścieżkę
OKULARinformator - %_ srcrpmdir: Odnosi się do ścieżki
SRPMSinformator - %_ Buildrootdir: Odniesienia do ścieżki
Buildrootinformator
Inne makra pozwalają nam odwoływać się do najważniejszych katalogów w systemie plików naszego maszyny, na przykład:
- %_ SYSCONFIGDIR:
/itpinformator - %_prefiks:
/usrinformator - %_ bindir:
/usr/bininformator - %_ mandir: Ścieżka do
/usr/share/maninformator
Ten powyżej nie jest pełną listą, ale daje pomysł. Dodatkowo możemy również użyć zestawu makr, które wykonują określone zadania. Aby rozwinąć definicję makra, a więc zobaczyć jego treść, możemy użyć RPM -Eval polecenie, które uważa makro jako argument. Oto kilka przykładów często używanych makr:
-
%organizować cośmakro jest używany w%ConfigSekcja Specile i zasadniczo wykonuje następujące działania:- Wyodrębnia kod źródłowy programu, który chcemy zapakować do
Builddirinformator - Przełącza się na wyodrębniony katalog
- Ustawia odpowiednie uprawnienia do pliku
- Wyodrębnia kod źródłowy programu, który chcemy zapakować do
-
%make_buildmakro jest używane w%zbudowaćsekcja specjalisty i zasadniczo uruchamiarobićpolecenie z predefiniowanymi zestawami opcji, aby skompilować kod źródłowy oprogramowania. Jeśli go rozszerzymy, możemy sprawdzić, co uruchamia polecenie:$ rpm --val "%Make_Build"/usr/bin/bin/make -o -J4
-
%make_installzamiast tego makro jest używany w%zainstalowaćsekcja pliku i uruchamiaZrób instalacjęzDestdirParametr, używany do instruowania polecenia do zainstalowania skompilowanych plików stosunkowo do danego katalogu zamiast rzeczywistego systemu/:$ rpm --val "%Make_Install"/usr/bin/make instaluj destdir =/home/egdoc/rpmbuild/buildroot/%nazwa-%wersja-%release.x86_64 install = "/usr/bin/install -p"
Jak utworzyć instrukcje dotyczące pakietu RPM
Teraz, gdy nauczyliśmy się podstawowej koncepcji procesu budowania pakietów, możemy zobaczyć, jak stworzyć nasze środowisko kompilacji i nasz pierwszy pakiet RPM. Utwórzmy nasz pakiet.
Zainstaluj zależności kompilacji
Jako pierwszą rzeczą musimy zainstalować RPMDevtools, Plus zależności potrzebne do budowy Feh:
$ sudo dnf instalacja rpmDevtools gcc Make IMlib2-devel libjpeg-devel libpng-devel libxt-devel libxinerama-devel libexif-devel \ perl-test-command Perl-Test-Test-Harness LIBCURL-DEVEL
Po zainstalowaniu pakietów możemy wygenerować nasze środowisko kompilacji. Wszystko, co musimy zrobić, to uruchomić następujące polecenie:
$ rpmdev-setuptree
W tym momencie rpmbuild Direktory i wszystkie podajowce, które widzieliśmy wcześniej, należy stworzyć. Następnym krokiem jest napisanie naszego specyl.
Utwórz specyl
Tworzymy specyl z naszym ulubionym edytorem tekstu i zapisujemy go w OKULAR katalog o tej samej nazwie pakietu. Oto, jak powinien wyglądać minimalny spefile:
Nazwa: Wersja FEH: 3.0 Wydanie: 1%?Dist Podsumowanie: Fast Command Linia Przeglądarka obrazu za pomocą IMLIB2 Licencja: MIT URL: http: // feh.FinalrewInd.ORG ŹRÓDŁO 0: http: // feh.FinalrewInd.org/feh-%wersja.smoła.Bz2 BuildRequires: GCC BuildRequires: Imlib2-Devel BuildRequires: libcurl-devel buildRequires: libjpeg-devel buildRequires: libpng-devel buildRequires: libxt-devel buildRequires: libxinerAm-devel-cubleRequires Test -Starness %Opis Widok obrazu szybkiego wiersza poleceń za pomocą IMLIB2 %PREP %konfiguracja -q %kompilacja %Make_Build %instalacja %make_install prefix = %_ prefiks %pliki/usr/feh/usr/lib/debug/debug /usr/bin/feh-3.0-1.FC29.x86_64.debugowanie/usr/share/aplikacje/feh.Desktop/usr/share/doc/feh/autorzy/usr/share/doc/feh/changelog/usr/shar.MD/usr/share/doc/feh/todo/usr/share/doc/feh/przykłady/przyciski/usr/share/feh/przykłady/find-lowres/usr/shar usr/share/doc/feh/przykłady/tematy/usr/share/feh/czcionki/czarny.styl/usr/share/feh/czcionki/menu.styl/usr/share/feh/czcionki/judit.ttf/usr/share/feh/images/feh.png/usr/share/feh/images/feh.svg/usr/share/feh/images/menubg_default.png/usr/share/icons/hicolor/48x48/apps/feh.png/usr/share/icons/hicolor/scalable/apps/feh.svg/usr/share/man/man1/feh.1.GZ
Przeanalizujmy to. Najpierw określiliśmy podstawowe informacje o oprogramowaniu, które chcemy zapakować: jego nazwa i wersja upstream, jego licencja, lokalizacja strony głównej projektu i bezpośredni link do kodu źródłowego Tarball, a następnie zadeklarowaliśmy buduj zależności za pomocą BuildRequires. Lista zależności może być reprezentowana jako lista inline oddzielona przestrzenią lub przecinkiem, ale ze względu na czytelność zadeklarowaliśmy jedną zależność na linię, powtarzając BuildRequires instrukcja.
Po ogłoszeniu zależności potrzebnych do zbudowania oprogramowania, podaliśmy krótki opis w %opis sekcja, a niż przejść do najważniejszej części specyfikacji: instrukcje przygotowywania, budowy i instalacji oprogramowania odpowiednio w %przygotowanie, %zbudować I %zainstalować Sekcje.
w %przygotowanie sekcja, dostarczająca %konfiguracji -q Makro wystarczy: jak powiedziano wcześniej, to makro uruchomi polecenia potrzebne do rozpakowania źródłowego tarballu i umieszczenia wyodrębnionego katalogu w ZBUDOWAĆ teczka.
%zbudować Sekcja to miejsce, w którym określamy polecenia, które należy uruchomić, aby zbudować kod źródłowy. Nawet tutaj wszystko, czego musieliśmy użyć, to tylko %make_build makro, które działa robić polecenie z opcjami, które widzieliśmy wcześniej, w katalogu hostującym rozpakowany kod źródłowy aplikacji, którą chcemy zapakować.
w %zainstalować sekcja, użyliśmy kolejnego makro, %make_install, dostarczanie również PREFIKS parametr, ustawiając go na %_prefiks, które zostaną rozszerzone na /usr. Powstałe polecenie spowoduje, że pliki wytworzone przez kompilację kodu źródłowego zostaną umieszczone w „fałszywym korzeniu”, ustawione z Destdir parametr zawarty w makra. Ponieważ w %make_install Macro, „destdir” jest ustawiony /home/egdoc/rpmbuild/buildroot/%nazwa-%wersja-%release.x86_64, Pliki zostaną zainstalowane pod: /home/egdoc/rpmbuild/buildroot/%nazwa-%wersja-%release.x86_64/usr.
Wreszcie, zapewniliśmy, w %akta sekcja, lista plików, które zostaną zainstalowane przez nasz pakiet. Ta lista można później sprawdzić, uruchamiając RPM -qlp/ścieżka/do/obr/min polecenie lub, jeśli pakiet jest już zainstalowany, po prostu uruchamiając RPM -QL Packagename.
Zdobądź źródła i zbuduj pakiet RPM
Teraz, gdy nasz plik specyfikacji jest w końcu gotowy, możemy zbudować nasze RPM. Możesz zauważyć, że nie pobraliśmy jeszcze źródłowej tarbal „feh”: nie trzeba tego robić ręcznie, ponieważ możemy użyć Spectool Komenda:
$ spectool -g -r ~/rpmbuild/specyfikacje/feh.Spec dostanie http: // feh.FinalrewInd.org/feh-3.0.smoła.BZ2 do/home/egdoc/rpmbuild/źródła/feh-3.0.smoła.BZ2 % Całkowity % Otrzymano % XFerd Średnia prędkość czas czas czasu prąd przesyłane DLOAD Całkowita spędzona lewa prędkość 100 185 100 185 0 0 898 0-::--::-:-:-:-:- -898 100 2057K 100 2057K 0 0 1988K 0 0:00:01 0:00:01-:-:-4191k
To polecenie pobranie źródeł, do których wspominaliśmy z adresem URL w specyfiku, w odpowiednim katalogu naszego drzewa roboczego: ~/rpmbuild/źródła. Ze źródłami możemy zbudować nasz rpm: wszystko, co musimy zrobić, to uruchomić rpmbuild polecenie i podaj ścieżkę do specyfiku. Po uruchomieniu z -nocleg ze śniadaniem opcja, RPMBuild zbuduje tylko pakiet binarny: jeśli chcemy wygenerować również źródło RPM, Musimy użyć -BA Zamiast tego (skonsultuj się z Manpage RPMBuild, aby uzyskać przegląd opcji możliwości).
Jedną bardzo ważną rzeczą do zapamiętania jest to, że polecenie RPMBuild nigdy nie powinno być uruchamiane z uprawnieniami korzeniowymi: gdy to robi, nawet prosty błąd w specyfilu może wywoływać niechciane efekty na naszym systemie. Uruchommy rpmbuild:
$ rpmbuild -bb ~/rpmbuild/specs/feh.Spec
Wyjście wykonanych operacji zostanie wydrukowane na ekranie, a jeśli wszystko pójdzie zgodnie z oczekiwaniami, pakiet RPM zostanie wygenerowany w środku RPM informator.
Wnioski
W tym samouczku poznaliśmy podstawowe koncepcje związane z tworzeniem pakietu RPM. Nauczyliśmy się niektórych makr i jak zbudować .Spec Plik, który zawiera wszystkie potrzebne instrukcje dotyczące procesu budowy. Podaliśmy również faktyczny przykład, budynek i opakowanie Feh, Prosty przeglądarka obrazu wiersza poleceń. Proponuję skonsultować się z oficjalnym przewodnikiem opakowań Red Hat w celu dalszego rozszerzenia pojęć wymienionych w tym samouczku.
Powiązane samouczki Linux:
- Wprowadzenie do automatyzacji, narzędzi i technik Linuksa
- Rzeczy do zainstalowania na Ubuntu 20.04
- Mastering Bash Script Loops
- Mint 20: Lepsze niż Ubuntu i Microsoft Windows?
- Rzeczy do zrobienia po zainstalowaniu Ubuntu 20.04 Focal Fossa Linux
- Jak aktualizować centos
- Pobierz Linux
- Ubuntu 20.04 Przewodnik
- Jak migrować z Centos do Almalinux
- Linux Pliki konfiguracyjne: Top 30 Najważniejsze