Menedżer pakietów RPM - RPM Package Manager

Menedżer pakietów RPM (RPM)
RPM Logo.svg
Pierwotny autor (autorzy) Erik Troan, Marc Ewing , Czerwony Kapelusz
Deweloper(zy) Społeczność i czerwony kapelusz
Pierwsze wydanie 1997 ; 24 lata temu ( 1997 )
Wersja stabilna
4.16.1.3 / 22 marca 2021 r .; 4 miesiące temu ( 2021-03-22 )
Wersja zapoznawcza
4.17.0 alfa / 26 kwietnia 2021 ; 3 miesiące temu ( 2021-04-26 )
Magazyn Edytuj to na Wikidata
Napisane w C , Perl
System operacyjny Linux , uniksowy
Rodzaj System zarządzania pakietami
Licencja GPL
Stronie internetowej rpm .org

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, rpporaz pmdoświadczenia.

pmzostał napisany przez Rika Faith i Douga Hoffmana w maju 1995 roku dla Red Hat Software, na jego projekt i implementacje duży wpływ pmsmiał system zarządzania pakietami stworzony przez Faith i Kevina Martina jesienią 1993 roku dla fałszywej dystrybucji Linuksa. pmzachowuje paradygmat " Pristine Sources + patches" z pms, dodając funkcje i eliminując arbitralne ograniczenia obecne w implementacji. pmzapewnia 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:

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 --rebuilddbpolecenia.

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.rpmThe <name>jest libgnomeuimmThe <version>jest 2.0The <release>jest 2.0.0_3i <architecture>to i386. Powiązany pakiet źródłowy miałby nazwęlibgnomeuimm-2.0-2.0.0_3.src.rpm

RPM z noarch.rpmrozszerzeniem 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 . rpm2cpioNarzę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ż

Bibliografia

Linki zewnętrzne