
Ekosystem RPM, pakowanie oprogramowania i plik spec – zbuduj swój pierwszy pakiet

W tym poradniku pokażemy, w jaki sposób przygotowywane są pakiety dla wiodących w sektorze biznesowym systemów z rodziny Enterprise Linux. Należą do nich m.in. Red Hat Enterprise Linux, Oracle Linux oraz CentOS. Omówimy, jak wygląda od wewnątrz struktura tych pakietów i jak w prosty sposób można przygotować dla nich specyfikację.
W tym poradniku pokażemy, w jaki sposób przygotowywane są pakiety dla wiodących w sektorze biznesowym systemów z rodziny Enterprise Linux. Należą do nich m.in. Red Hat Enterprise Linux, Oracle Linux oraz CentOS. Omówimy, jak wygląda od wewnątrz struktura tych pakietów i jak w prosty sposób można przygotować dla nich specyfikację.
Wraz z rozwojem przedsiębiorstwa i zatrudnianiem coraz większej liczby pracowników, wzrasta też potrzeba standaryzacji i posiadania scentralizowanego źródła prawdy. Jest to cyfrowy system przechowywania dóbr niezbędnych dla ujednoliconego środowiska używanego przez pracowników. Źródło to w praktyce może się różnić w zależności od stanowiska. Niemniej, koncepcja jest identyczna:
- arkusz kalkulacyjny dostępny z poziomu przeglądarki, w którym dział księgowości współpracuje w czasie rzeczywistym nad dokumentem
- organizer śledzenia zadań i poświęconego na nie czasu dostępny dla menedżera
- źródło dostarczania oprogramowania używanego na stacjach roboczych pracowników.
Wart dalszego omówienia jest ostatni punkt. Jako że stanowiska pracy mogą się różnić pod kątem konfiguracji, niezbędny jest ekosystem gwarantujący poprawną instalację i działanie tego oprogramowania. Omówimy dziś ten używany przez systemy Enterprise Linux – RPM.
Dlaczego RPM?
RPM został zaprojektowany z myślą o rozwiązaniu współczesnych wyzwań zarządzania oprogramowaniem w skali systemowej. Mowa zarówno o wyzwaniach dla użytkowników końcowych, jak i inżynierów zajmujących się budową oprogramowania i dostarczaniem go w postaci pakietów. W efekcie otrzymujemy ekosystem składający się z poniższych kluczowych zalet.
Aktualizacje
RPM umożliwia zautomatyzowaną aktualizację pełnego systemu operacyjnego lub indywidualnych pakietów z oprogramowaniem, nie wymagając przy tym przerywania działania uruchomionych już programów. Niestandardowe ustawienia wykonane przez użytkownika zostają zachowane dla nowych wydań oprogramowania po aktualizacji.
Bogaty język zapytań
RPM eksponuje parametry pozwalające na: odnalezienie pakietów, dostarczanych przez nie indywidualnych plików oraz zależności pakietów w swojej bazie danych. W przypadku wątpliwości można w prosty i szybki sposób zlokalizować potrzebne informacje i rozwiązać wątpliwość.
Źródła bazowe
Jednym z ważniejszych aspektów dla inżynierów oprogramowania jest fakt, że pakiety RPM składają się ze źródeł przygotowanych przez oryginalnych autorów programu. Inżynier ma możliwość dodania specyfikacji budowania paczki oraz własnych łatek w oddzielnych plikach i dostarczenia gotowego produktu w takiej spakowanej formie.
Jak zbudować swój własny pakiet?
Pokażemy, jak własnoręcznie przygotować swój własny binarny pakiet RPM na podstawie źródeł, które oferuje firma EuroLinux.
Glosariusz
- RPM – ekosystem obejmujący szerokie spektrum dostarczania i budowania oprogramowania dla rodziny systemów Enterprise Linux
- Pakiet RPM – plik zawierający inne pliki oraz metadane umożliwiające m.in. śledzenie zależności, wersji czy lokalizacji instalacji.
Wyróżniamy następujący podział:
- źródłowy pakiet RPM – pakiet ze źródłami od oryginalnego autora oprogramowania wraz ze specyfikacją i łatkami dostarczonymi przez inżyniera
- binarny pakiet RPM – pakiet przygotowany dla użytkownika końcowego już ze zbudowanym oprogramowaniem
- plik .spec – plik zawierający specyfikację, jak zbudować oprogramowanie i spakować do postaci binarnego pakietu RPM
- makro RPM – tekst zapisany w pliku .spec, który zostanie podmieniony w procesie budowania na inny tekst na podstawie uprzedniej jego definicji.
Przykładowo, EuroLinux 8 definiuje makro %{dist}
jako .el8
, a EuroLinux 7 jako .el7
. W zależności od docelowego wydania systemu, makro zostanie rozwinięte, by finalny tekst uwzględniał cyfrę wydania.
Konfiguracja środowiska pracy
1. Zainstalujmy narzędzia programistyczne niezbędne do zbudowania binarnego pakietu RPM ze źródłowego.
[vagrant@EuroLinux8 ~]$ sudo dnf groupinstall -y "Development Tools"
[vagrant@EuroLinux8 ~]$ sudo dnf install -y rpmdevtools
2. Przygotujmy katalogi używane przez ekosystem RPM jako środowisko pracy inżyniera.
[vagrant@EuroLinux8 ~]$ rpmdev-setuptree
Niektóre pakiety będą wymagać dodatkowych nagłówków w ramach budowy. Ich instalacja została omówiona poniżej na pewnym przykładzie.
Zbudowanie pakietu
W ramach tego przykładu przebudujemy pakiet RPM z programem o nazwie mc. Dodamy redefinicję wspomnianego wcześniej makra %{dist}
, zbudujemy i zainstalujemy pakiet binarny i wykonamy zapytanie do systemowej bazy danych. To pozwoli nam się przekonać, że pakiet z nową nazwą został zainstalowany w systemie.
1. Pobieramy źródłowy pakiet RPM i wypakowujemy jego zawartość.
[vagrant@EuroLinux8 ~]$ wget https://vault.cdn.euro-linux.com/sources/eurolinux/8/appstream/x86_64/Packages/m/mc-4.8.19-9.el8.src.rpm
[vagrant@EuroLinux8 ~]$ rpm2cpio mc-4.8.19-9.el8.src.rpm | cpio -idmv -D ~/rpmbuild/SOURCES
2. Edytujemy plik *.spec
, aby zawrzeć w nim nasze nowe makro.
[vagrant@EuroLinux8 ~]$ vim ~/rpmbuild/SOURCES/*.spec
[vagrant@EuroLinux8 ~]$ grep --line-number -H '.moje_nowe_makro' ~/rpmbuild/SOURCES/*.spec
/home/vagrant/rpmbuild/SOURCES/mc.spec:1:%define dist .moje_nowe_makro
3. Budujemy pakiet binarny.
[vagrant@EuroLinux8 ~]$ sudo dnf install -y yum-utils
[vagrant@EuroLinux8 ~]$ cd ~/rpmbuild/SOURCES/
[vagrant@EuroLinux8 SOURCES]$ sudo yum-builddep *.spec
[vagrant@EuroLinux8 SOURCES]$ rpmbuild -ba *.spec
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.3WFDye
...
Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.WybFHi
...
Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.9pLeii
...
Executing(%doc): /bin/sh -e /var/tmp/rpm-tmp.CQKTkg
...
Executing(%license): /bin/sh -e /var/tmp/rpm-tmp.txVO3h
...
Wrote: /home/vagrant/rpmbuild/SRPMS/mc-4.8.19-9.moje_nowe_makro.src.rpm
Wrote: /home/vagrant/rpmbuild/RPMS/x86_64/mc-4.8.19-9.moje_nowe_makro.x86_64.rpm
Wrote: /home/vagrant/rpmbuild/RPMS/x86_64/mc-debugsource-4.8.19-9.moje_nowe_makro.x86_64.rpm
Wrote: /home/vagrant/rpmbuild/RPMS/x86_64/mc-debuginfo-4.8.19-9.moje_nowe_makro.x86_64.rpm
Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.eNphog
+ umask 022
+ cd /home/vagrant/rpmbuild/BUILD
+ cd mc-4.8.19
+ /usr/bin/rm -rf /home/vagrant/rpmbuild/BUILDROOT/mc-4.8.19-9.moje_nowe_makro.x86_64
+ exit 0
4. Widzimy, że zapisane zostały zarówno pakiety źródłowe RPM (katalog /home/vagrant/rpmbuild/SRPMS), jak i binarne (katalog /home/vagrant/rpmbuild/RPMS). Zainstalujmy nasz przebudowany pakiet binarny.
[vagrant@EuroLinux8 ~]$ sudo rpm --install /home/vagrant/rpmbuild/RPMS/x86_64/mc-4.8.19-9.moje_nowe_makro.x86_64.rpm
5. Wykonajmy zapytanie do systemowej bazy danych RPM.
[vagrant@EuroLinux8 ~]$ rpm -qa mc
mc-4.8.19-9.moje_nowe_makro.x86_64
6. W ramach ciekawostki zobaczmy, że nasze makro zostało zaszyte w samym pliku binarnym programu mc.
[vagrant@EuroLinux8 ~]$ strings $(which mc) | grep -A3 -B3 moje_nowe_makro
GA+GLIBCXX_ASSERTIONS
GA*FORTIFY
GA+GLIBCXX_ASSERTIONS
mc-4.8.19-9.moje_nowe_makro.x86_64.debug
7zXZ
t0jf
8,Gu
Podsumowanie
W powyższym przykładzie pokazaliśmy, jak proste jest przygotowanie środowiska pracy inżyniera odpowiedzialnego za zbudowanie i dostarczanie pakietu dla ekosystemu RPM. W rezultacie ów pakiet jest już gotowy do wdrożenia do firmowego centralnego źródła prawdy i instalacji przez innych pracowników. W ten sposób firma może tworzyć własne modyfikacje oprogramowania, które po zakończonej powyższej procedurze zostaną zaaplikowane na stanowiskach pracy.