Menedżer pakietów RPM - RPM Package Manager
Pierwotny autor (autorzy) | Erik Troan, Marc Ewing , Czerwony Kapelusz |
---|---|
Deweloper(zy) | Społeczność i czerwony kapelusz |
Pierwsze wydanie | 1997 |
Wersja stabilna | 4.16.1.3 / 22 marca 2021 r
|
Wersja zapoznawcza | 4.17.0 alfa / 26 kwietnia 2021
|
Magazyn | |
Napisane w | C , Perl |
System operacyjny | Linux , uniksowy |
Rodzaj | System zarządzania pakietami |
Licencja | GPL |
Stronie internetowej | rpm |
RPM Package Manager ( RPM ) (pierwotnie Red Hat Package Manager , obecnie rekurencyjny akronim ) to darmowy system zarządzania pakietami o otwartym kodzie źródłowym . Nazwa RPM odnosi się do .rpm
formatu pliku i samego programu do zarządzania pakietami. RPM był przeznaczony głównie dla dystrybucji Linuksa ; format pliku jest podstawowym formatem pakietu Linux Standard Base .
Chociaż został stworzony do użytku w Red Hat Linux , RPM jest obecnie używany w wielu dystrybucjach Linuksa , takich jak Fedora , CentOS , openSUSE , OpenMandriva i Oracle Linux . Został również przeniesiony do niektórych innych systemów operacyjnych , takich jak Novell NetWare (od wersji 6.5 SP3), IBM AIX (od wersji 4), IBM i oraz ArcaOS .
Pakiet RPM może zawierać dowolny zestaw plików. Większość plików RPM to „binarne pliki RPM” (lub BRPM) zawierające skompilowaną wersję niektórych programów. Istnieją również „źródłowe RPM” (lub SRPM) zawierające kod źródłowy użyty do zbudowania pakietu binarnego. Mają one odpowiedni znacznik w nagłówku pliku, który odróżnia je od normalnych (B)RPM-ów, powodując ich rozpakowanie do /usr/src podczas instalacji. SRPM zwykle mają rozszerzenie pliku „.src.rpm” (.spm w systemach plików ograniczonych do 3 znaków rozszerzenia, np. stary DOS FAT ).
Historia
RPM został pierwotnie w 1997 roku Erik Troan i Marc Ewing napisane na podstawie pms
, rpp
oraz pm
doświadczenia.
pm
został napisany przez Rika Faith i Douga Hoffmana w maju 1995 roku dla Red Hat Software, na jego projekt i implementacje duży wpływ pms
miał system zarządzania pakietami stworzony przez Faith i Kevina Martina jesienią 1993 roku dla fałszywej dystrybucji Linuksa. pm
zachowuje paradygmat " Pristine Sources + patches" z pms
, dodając funkcje i eliminując arbitralne ograniczenia obecne w implementacji. pm
zapewnia znacznie ulepszoną obsługę bazy danych do śledzenia i weryfikacji zainstalowanych pakietów
Cechy
Dla administratora systemu wykonującego instalację i konserwację oprogramowania korzystanie z zarządzania pakietami zamiast ręcznego budowania ma zalety, takie jak prostota, spójność i możliwość zautomatyzowania tych procesów i braku interakcji. rpm używa Berkeley DB jako bazy danych zaplecza, chociaż od 4.15 w 2019 r. obsługuje budowanie pakietów rpm bez Berkeley DB ( –disable-bdb
).
Funkcje RPM obejmują:
- Pakiety RPM można zweryfikować kryptograficznie za pomocą GPG i MD5
- Oryginalne archiwa źródłowe (np.
.tar.gz
,.tar.bz2
) są zawarte w SRPM-ach, co ułatwia weryfikację - Aktualizacja Delta : PatchRPMs i DeltaRPMs, odpowiedniki RPM pliku poprawki , mogą przyrostowo aktualizować oprogramowanie zainstalowane w RPM
- Automatyczna ocena zależności w czasie kompilacji.
Operacje lokalne
Pakiety mogą pochodzić z konkretnej dystrybucji (na przykład Red Hat Enterprise Linux ) lub być zbudowane dla niej przez inne strony (na przykład RPM Fusion dla Fedory). Zależności kołowe między wzajemnie zależnymi RPM (tzw. „ piekło zależności ”) mogą być problematyczne; w takich przypadkach pojedyncze polecenie instalacji musi określić wszystkie odpowiednie pakiety.
Repozytoria
RPM są często gromadzone centralnie w jednym lub kilku repozytoriach w Internecie. Witryna często ma własne repozytoria RPM, które mogą działać jako lokalne kopie lustrzane takich repozytoriów internetowych lub być lokalnie utrzymywanymi zbiorami przydatnych RPM.
Początek końca
Kilka front-endów do RPM ułatwia proces uzyskiwania i instalowania RPM z repozytoriów i pomaga w rozwiązywaniu ich zależności. Obejmują one:
- mniam używany w Fedorze , CentOS 5 i nowszych, Red Hat Enterprise Linux 5 i nowszych, Scientific Linux , Yellow Dog Linux i Oracle Linux
- DNF , wprowadzony w Fedorze 18 (domyślnie od 22 ), Red Hat Enterprise Linux 8 i CentOS Linux 8.
- up2date używane w Red Hat Enterprise Linux , CentOS 3 i 4 oraz Oracle Linux
- Zypper używany w Mer (a tym samym Sailfish OS), MeeGo , openSUSE i SUSE Linux Enterprise
- urpmi używane w Mandriva Linux , ROSA Linux i Mageia
- apt-rpm , port Debiana Advanced Packaging Tool (APT) używany w Ark Linux, PCLinuxOS i ALT Linux
- Smart Package Manager , używany w Unity Linux, dostępny dla wielu dystrybucji, w tym Fedory .
-
rpmquery
, narzędzie wiersza polecenia dostępne (na przykład) w systemie Red Hat Enterprise Linux
Lokalna baza danych instalacji RPM
Za kulisami menedżera pakietów pracuje baza danych RPM, przechowywana w /var/lib/rpm
. Używa Berkeley DB jako swojego zaplecza. Składa się z jednej bazy danych ( Packages
) zawierającej wszystkie metainformacje o zainstalowanych pakietach RPM. W celu indeksowania tworzonych jest wiele baz danych, które replikują dane w celu przyspieszenia zapytań. Baza danych służy do śledzenia wszystkich plików, które są zmieniane i tworzone, gdy użytkownik (za pomocą RPM) instaluje pakiet, umożliwiając w ten sposób użytkownikowi (za pośrednictwem RPM) odwrócenie zmian i późniejsze usunięcie pakietu. Jeśli baza danych zostanie uszkodzona (co jest możliwe, jeśli klient RPM zostanie zabity ), indeksowe bazy danych można odtworzyć za pomocą rpm --rebuilddb
polecenia.
Opis
Chociaż format RPM jest taki sam w różnych dystrybucjach Linuksa , szczegółowe konwencje i wytyczne mogą się w nich różnić.
Nazwa pliku i etykieta pakietu
RPM jest dostarczany w jednym pliku, zwykle o nazwie pliku w formacie:
-
<name>-<version>-<release>.src.rpm
dla pakietów źródłowych, lub -
<name>-<version>-<release>.<architecture>.rpm
dla plików binarnych.
Na przykład, w pliku pakietu libgnomeuimm-2.0-2.0.0_3.i386.rpm
The <name>
jest libgnomeuimm
The <version>
jest 2.0
The <release>
jest 2.0.0_3
i <architecture>
to i386
. Powiązany pakiet źródłowy miałby nazwęlibgnomeuimm-2.0-2.0.0_3.src.rpm
RPM z noarch.rpm
rozszerzeniem nie zależą od konkretnej architektury procesora. Na przykład te RPM mogą zawierać grafikę i tekst do wykorzystania przez inne programy. Mogą również zawierać skrypty powłoki lub programy napisane w innych interpretowanych językach programowania, takich jak Python .
Zawartość RPM zawiera również etykietę opakowania , która zawiera następujące informacje:
- nazwa oprogramowania
- Wersja oprogramowania (wersja pochodzi z oryginalnego górnego źródła oprogramowania)
- wydanie pakietu (liczba przebudowy pakietu przy użyciu tej samej wersji oprogramowania). To pole jest również często używane do wskazania konkretnej dystrybucji, dla której pakiet jest przeznaczony, przez dołączenie ciągów takich jak „mdv” (dawniej „mdk”) ( Mandriva Linux ), „mga” ( Mageia ), „fc4” ( Fedora Core 4) , „rhl9” (Red Hat Linux 9), „suse100” ( SUSE Linux 10.0) itd.
- architektura, dla której zbudowano pakiet (i386, i686, x86_64, ppc itp.)
Pola etykiety pakietu nie muszą odpowiadać nazwie pliku.
Opakowania biblioteczne
Biblioteki są dystrybuowane w dwóch oddzielnych pakietach dla każdej wersji. Jeden zawiera prekompilowany kod do użycia w czasie wykonywania, podczas gdy drugi zawiera powiązane pliki programistyczne, takie jak nagłówki itp. Te pakiety mają dodany "-devel" do pola nazwy. Administrator systemu powinien upewnić się, że wersje pakietu binarnego i rozwojowego są zgodne.
Format binarny
Format jest binarny i składa się z czterech sekcji:
- Lead, który identyfikuje plik jako plik RPM i zawiera przestarzałe nagłówki.
- Podpis, którego można użyć do zapewnienia integralności i/lub autentyczności.
- Nagłówek, który zawiera metadane, w tym nazwę pakietu, wersję, architekturę, listę plików itp.
- Archiwum plików ( payload ), które zwykle jest w formacie cpio , skompresowane za pomocą gzip .
rpm2cpio
Narzędzie umożliwia pobieranie pliku cpio bez konieczności instalowania pakietu RPM.- Linux Standard Base wymaga użycia gzip, ale pakiety Fedory 30 są skompresowane xz, a pakiety Fedory 31 mogą być skompresowane zstd . Najnowsze wersje RPM mogą również używać kompresji bzip2 , lzip lub lzma .
- Format RPM 5.0 obsługuje używanie xar do archiwizacji.
Plik SPEC
„Przepisem” na tworzenie pakietu RPM jest plik spec. Pliki specyfikacji kończą się sufiksem „.spec” i zawierają nazwę pakietu, wersję, numer wersji RPM, kroki budowania, instalowania i czyszczenia pakietu oraz dziennik zmian. W razie potrzeby z jednego pliku specyfikacji RPM można zbudować wiele pakietów. Pakiety RPM są tworzone z plików specyfikacji RPM za pomocą narzędzia rpmbuild.
Pliki spec są zwykle dystrybuowane w plikach SRPM, które zawierają plik spec spakowany wraz z kodem źródłowym.
SRPM
Typowy RPM to wstępnie skompilowane oprogramowanie gotowe do bezpośredniej instalacji. Można również rozpowszechniać odpowiedni kod źródłowy. Odbywa się to w SRPM, który zawiera również plik „SPEC” opisujący oprogramowanie i sposób jego budowy. SRPM pozwala również użytkownikowi skompilować i być może modyfikować sam kod.
Pakiet oprogramowania może zawierać tylko skrypty niezależne od platformy. W takim przypadku programista może dostarczyć tylko SRPM, który nadal jest instalowalnym RPM.
NOSRC
To jest specjalna wersja SRPM. Zawiera plik "SPEC" i opcjonalnie poprawki, ale nie zawiera źródeł (zwykle z powodu licencji).
Widelce
Od czerwca 2010 są w fazie rozwoju dwie wersje RPM: jedna kierowana przez Projekt Fedora i Red Hat, a druga przez oddzielną grupę kierowaną przez poprzedniego opiekuna RPM, byłego pracownika Red Hata.
RPM.org
W rpm.org pierwszy poważny przegląd wspólnotowego kodeksu była w lipcu 2007 roku; wersja 4.8 została wydana w styczniu 2010, wersja 4.9 w marcu 2011, 4.10 w maju 2012, 4.11 w styczniu 2013, 4.12 we wrześniu 2014 i 4.13 w lipcu 2015.
Ta wersja jest używana przez dystrybucjach takich jak Fedora , Red Hat Enterprise Linux i pochodnych , openSUSE , SUSE Linux Enterprise , Unity Linux , Mageia , OpenEmbedded , Tizen i OpenMandriva Lx (dawniej Mandriva ).
RPM v5
Jeff Johnson, opiekun RPM od 1999 roku, kontynuował prace nad rozwojem wraz z uczestnikami z kilku innych dystrybucji. RPM w wersji 5 został wydany w maju 2007 roku.
Ta wersja jest używana przez takie dystrybucje, jak Wind River Linux (do Wind River Linux 10), Rosa Linux i OpenMandriva Lx (dawny Mandriva Linux, który przełączył się na rpm5 w 2011 roku), a także przez projekt OpenPKG , który dostarcza pakiety dla innych popularnych systemów UNIX- platformy.
OpenMandriva Lx zamierza wrócić do rpm.org w wersji 4.0.
OpenEmbedded , ostatni główny użytkownik RPM5, przełączył się z powrotem na rpm.org z powodu problemów w RPM5.
Zobacz też
- Autopackage — „komplementarny” system zarządzania pakietami
- Delta ISO — obraz ISO zawierający pliki RPM Package Manager
- dpkg — system zarządzania pakietami używany przez Debiana i jego pochodne
- Lista dystrybucji Linuksa opartych na RPM
- pkg-config — odpytuje biblioteki w celu skompilowania oprogramowania z jego kodu źródłowego
Bibliografia
- Schroeder, Jeff (2008-01-30). „Zaawansowane ciągi zapytań RPM” . www.cyfroweprognozy.com . Zarchiwizowane od oryginału w dniu 2011-08-09 . Pobrano 2018-03-28 .
Linki zewnętrzne
- Strona główna projektu RPM.org
- Opis poleceń RPM i DPKG
- Historia RPM autorstwa Matta Frye'a w Red Hat Magazine zarchiwizowana 2007-09-29 w Wayback Machine
- Jak stworzyć pakiet RPM
- Samouczki wideo dotyczące budowania i łatania RPM
- Notatki RPM — łatwe budowanie RPM
- Oprogramowanie do pakowania z RPM, Część 1: Budowanie i dystrybucja pakietów
- Dowiedz się Linux, 101: zarządzanie pakietami RPM i YUM