Správce balíčků RPM - RPM Package Manager - Wikipedia

Správce balíků RPM (RPM)
Logo RPM.svg
Původní autořiErik Troan, Marc Ewing,[1] červená čepice
VývojářiKomunita & červená čepice[2][3]
První vydání1997; Před 23 lety (1997)[1]
Stabilní uvolnění
4.16.0 / 30. září 2020; před 2 měsíci (2020-09-30)
Náhled verze
4.16.0 RC1 / 31. srpna 2020; před 3 měsíci (2020-08-31)
Úložiště
Upravte to na Wikidata
NapsánoC, Perl[4]
Operační systémLinux, Unixový
TypSystém správy balíků
LicenceGPL
webová stránkaot / min.org

Správce balíčků RPM (RPM) (původně Správce balíčků Red Hat, nyní a rekurzivní zkratka ) je zdarma a open-source systém správy balíčků.[5] Název RPM odkazuje ot./min formát souboru a samotný program správce balíčků. RPM bylo určeno primárně pro Linuxové distribuce; formát souboru je základní balíček formátu Linux Standard Base.

Ačkoli byl vytvořen pro použití v Red Hat Linux, RPM se nyní používá v mnoha Linuxové distribuce jako Fedora, CentOS, OpenSUSE, OpenMandriva a Oracle Linux. Bylo také přeneseno na jiné operační systémy, jako Novell NetWare (od verze 6.5 SP3), IBM AIX (od verze 4),[6] IBM i,[7] a ArcaOS.[8]

Balíček RPM může obsahovat libovolnou sadu souborů. Většina souborů RPM jsou „binární RPM“ (nebo BRPM) obsahující kompilovanou verzi nějakého softwaru. Existují také „zdrojové RPM“ (nebo SRPM) obsahující zdrojový kód slouží k vytvoření binárního balíčku. Ty mají v záhlaví souboru příslušnou značku, která je odlišuje od běžných (B) RPM, což způsobí jejich extrahování do / usr / src při instalaci. SRPM obvykle nesou příponu souboru „.src.rpm“ (.spm v souborových systémech omezených na 3 znaky rozšíření, např. Starý DOS TLUSTÝ ).

Dějiny

RPM původně napsali v roce 1997 Erik Troan a Marc Ewing,[1] na základě pms, rpp, a odpoledne zkušenosti.

odpoledne byl napsán Rikem Faithem a Dougem Hoffmanem v květnu 1995 pro Red Hat Software, jeho design a implementace byly velmi ovlivněny pms, systém správy balíčků Faith a Kevin Martin na podzim roku 1993 pro Bogus Linux Distribution. odpoledne zachovává „Nedotčené zdroje + patche "paradigma pms, zatímco přidává funkce a eliminuje libovolná omezení přítomná v implementaci. odpoledne poskytuje výrazně vylepšenou podporu databáze pro sledování a ověřování nainstalovaných balíčků[4][9][10]

Funkce

Pro správce systému Při provádění a údržbě softwaru má použití správy balíků namísto manuálního vytváření výhody, jako je jednoduchost, konzistence a schopnost automatizace a neinteraktivity těchto procesů. rpm použití Berkeley DB jako backendová databáze, i když od 4.15 v roce 2019 podporuje vytváření balíků rpm bez Berkeley DB (–Disable-bdb).

Mezi funkce RPM patří:

  • Balíčky RPM lze kryptograficky ověřit pomocí GPG a MD5
  • Původní zdrojové archivy (např. .tar.gz, .tar.bz2) jsou součástí SRPM, což usnadňuje ověřování
  • Aktualizace Delta: PatchRPM a DeltaRPM, ekvivalent RPM a náplast soubor, může postupně aktualizovat software nainstalovaný pomocí RPM
  • Automatické vyhodnocení závislosti na sestavení.

Místní operace

Balíčky mohou pocházet z konkrétní distribuce (například Red Hat Enterprise Linux ) nebo jej za něj mohou postavit jiné strany (například RPM Fusion pro Fedoru).[11] Kruhové závislosti mezi vzájemně závislými RPM (tzv.závislost peklo ") může být problematický;[12] v takových případech musí jediný instalační příkaz specifikovat všechny příslušné balíčky.

Úložiště

RPM se často shromažďují centrálně v jednom nebo více úložiště na internetu. Web často má svá vlastní úložiště RPM, která mohou fungovat jako lokální zrcadla takových internetových úložišť, nebo být lokálně udržovanými sbírkami užitečných RPM.

Přední konce

Několik přední části RPM usnadňují proces získávání a instalace RPM z úložišť a pomáhají při řešení jejich závislostí. Tyto zahrnují:

Místní instalační databáze RPM

V zákulisí správce balíčků pracuje databáze RPM uložená v / var / lib / rpm. Využívá to Berkeley DB jako jeho zadní část. Skládá se z jedné databáze (Balíčky) obsahující všechny meta informace nainstalovaných RPM. Vytváří se více databází pro účely indexování a replikace dat k urychlení dotazů. Databáze se používá ke sledování všech souborů, které jsou změněny a vytvořeny, když uživatel (pomocí RPM) nainstaluje balíček, což uživateli (prostřednictvím RPM) umožní vrátit změny a balíček později odebrat. Pokud dojde k poškození databáze (což je možné, pokud je klient RPM zabit ) lze indexové databáze znovu vytvořit pomocí rpm --rebuilddb příkaz.[15]

Popis

Zatímco formát RPM je stejný napříč různými Linuxové distribuce, podrobné konvence a pokyny se mohou mezi nimi lišit.

Název balíčku a štítek

RPM se dodává v jediném souboru, obvykle s názvem souboru ve formátu:

- - .src.rpm pro zdrojové balíčky nebo
- - . .rpm pro binární soubory.

Například v názvu souboru balíčku libgnomeuimm-2.0-2.0.0-3. i386.rpm, <name> je libgnomeuimm, <version> je 2.0, <release> je 2.0.0-3a <architecture> je i386Přidružený zdrojový balíček bude pojmenován libgnomeuimm-2.0-2.0.0-3.src.rpm

RPM s noarch.rpm rozšíření nezávisí na konkrétní architektuře CPU. Například tyto RPM mohou obsahovat grafiku a text pro použití v jiných programech. Mohou také obsahovat shell skripty nebo programy napsané v jiných interpretovaných programovacích jazycích, jako např Krajta.

Obsah RPM také zahrnuje a označení obalu, který obsahuje následující informace:

  • název softwaru
  • verze softwaru (verze převzatá z originálu) proti proudu zdroj softwaru)
  • vydání balíčku (kolikrát byl balíček znovu vytvořen pomocí stejné verze softwaru). Toto pole se také často používá k označení konkrétní distribuce, pro kterou je balíček určen, připojením řetězců jako „mdv“ (dříve „mdk“) (Mandriva Linux ), „mga“ (Mageia ), „fc4“ (Fedora Core 4), "rhl9" (Red Hat Linux 9), "suse100" (SUSE Linux 10.0) atd.
  • architektura, pro kterou byl balíček vytvořen (i386, i686, x86_64, ppc atd.)

Pole popisek balíčku se nemusí shodovat s názvem souboru.

Balení knihovny

Knihovny jsou distribuovány ve dvou samostatných balíčcích pro každou verzi. Jeden obsahuje předkompilovaný kód pro použití za běhu, zatímco druhý obsahuje související vývojové soubory, jako jsou záhlaví atd. Tyto balíčky mají k jejich poli názvu připojeno "-devel". Správce systému by měl zajistit shodu verzí binárního a vývojového balíčku.

Binární formát

Formát je binární a skládá se ze čtyř částí:[5]

  • Potenciální zákazník, který identifikuje soubor jako soubor RPM a obsahuje několik zastaralých záhlaví.
  • Podpis, který lze použít k zajištění integrity a / nebo autenticity.
  • Záhlaví, které obsahuje metadata včetně názvu balíčku, verze, architektury, seznamu souborů atd.
  • Archiv souborů ( užitečné zatížení ), který je obvykle v cpio formát komprimovaný pomocí gzip. The rpm2cpio nástroj umožňuje načtení souboru cpio bez nutnosti instalace balíčku RPM.[16]
    • Linux Standard Base vyžaduje použití gzip, ale balíčky Fedory 30 ano xz -komprimované a balíčky Fedory 31 mohou být zstd -stlačený.[17] Lze použít i nejnovější verze RPM bzip2, lzip,[18] nebo lzma komprese.
    • Formát RPM 5.0 podporuje použití xar pro archivaci.

SPEC soubor

„Recept“ pro vytvoření balíčku RPM je soubor spec. Soubory Spec končí příponou „.spec“ a obsahují název balíčku, verzi, číslo revize RPM, kroky k sestavení, instalaci a vyčištění balíčku a seznam změn. V případě potřeby lze z jednoho souboru se specifikací RPM vytvořit více balíčků. Balíčky RPM se vytvářejí ze specifikačních souborů RPM pomocí nástroje rpmbuild.

Soubory Spec jsou obvykle distribuovány v souborech SRPM, které obsahují soubor spec zabalený spolu se zdrojovým kódem.

SRPM

Typickým RPM je předkompilovaný software připravený k přímé instalaci. Rovněž lze distribuovat odpovídající zdrojový kód. To se provádí v SRPM, který také obsahuje soubor „SPEC“ popisující software a jeho konstrukci. SRPM také umožňuje uživateli sestavit a případně upravit samotný kód.

Softwarový balíček může obsahovat pouze skripty nezávislé na platformě. V takovém případě může vývojář poskytnout pouze SRPM, což je stále instalovatelné RPM.

NOSRC

Toto je speciální verze SRPM. Obsahuje soubor „SPEC“ a volitelně patche, ale nezahrnuje zdroje (obvykle kvůli licenci).[19]

Vidlice

Od června 2010, vyvíjejí se dvě verze RPM: jedna vedená projektem Fedora a Red Hat a druhá samostatnou skupinou vedenou předchozí správce RPM, bývalý zaměstnanec Red Hat.

RPM.org

The rpm.org první hlavní revize kódu komunity byla v červenci 2007; verze 4.8 byla vydána v lednu 2010, verze 4.9 v březnu 2011, 4,10 v květnu 2012, 4,11 v lednu 2013, 4,12 v září 2014 a 4,13 v červenci 2015.

Tuto verzi používají distribuce jako Fedora, Red Hat Enterprise Linux a deriváty, openSUSE, SUSE Linux Enterprise, Unity Linux, Mageia,[20] OpenEmbedded, Tizen a OpenMandriva Lx (dříve Mandriva ).

RPM v5

Jeff Johnson, správce RPM od roku 1999, pokračoval ve vývoji společně s účastníky z několika dalších distribucí. RPM verze 5 byla vydána v květnu 2007.

Tuto verzi používají distribuce jako Wind River Linux (do Wind River Linux 10), Rosa Linux a OpenMandriva Lx (bývalý Mandriva Linux který v roce 2011 přešel na otáčky za minutu[21]) a také OpenPKG projekt, který poskytuje balíčky pro další běžné platformy UNIX.

OpenMandriva Lx se přepne zpět na rpm.org[22] pro verzi 4.0.[potřebuje aktualizaci ]

OpenEmbedded, poslední hlavní uživatel RPM5, přešel zpět na rpm.org kvůli problémům v RPM5.[23][24]

Viz také

Reference

  1. ^ A b C „RPM timeline“. rpm.org. Citováno 2020-06-25.
  2. ^ „RPM - plány, cíle atd.“. Max Spevack. Citováno 2011-01-20.
  3. ^ „RPM.org FAQ“. Archivovány od originál dne 2016-11-05. Citováno 2013-08-25.
  4. ^ A b Bailey, Edward C. (2000). „Kapitola 1: Úvod do správy balíčků“. Maximální RPM: Dostanete Red Hat Package Manager na maximum. Red Hat, Inc. str. 22–25. ISBN  978-1888172782. Archivovány od originál dne 10. 9. 2016. Citováno 2013-08-13.
  5. ^ A b Bailey, Edward C. (2000). "Příloha A: Formát souboru RPM". Maximální RPM: Dostanete Red Hat Package Manager na maximum. Red Hat, Inc. str. 325–336. ISBN  978-1888172782. Archivovány od originál dne 2016-04-21. Citováno 2010-11-22.
  6. ^ "Konfigurace YUM a vytváření lokálních úložišť na IBM AIX". 2018-10-24.
  7. ^ „RPM a Yum jsou pro IBM i velkým problémem. Zde je důvod, proč“. 2018-07-18.
  8. ^ „Správce balíčků“. Citováno 2020-09-04.
  9. ^ „RPM Guide-RPM - Design Goals“. Citováno 2014-04-14.
  10. ^ „BOGUS Announce“. Citováno 2014-04-14.
  11. ^ „RPM Fusion“. rpmfusion.org. Citováno 2010-11-22.
  12. ^ „Analýza posunu platnosti RPM“ (PDF). Sdružení USENIX. Citováno 2011-03-15.
  13. ^ „Zypper - MeeGo wiki“. Archivovány od originál dne 25. 09. 2013. Citováno 2014-04-14.
  14. ^ „Časté dotazy: O projektech“. Ark Linux oficiální stránky. Archivovány od originál dne 11.02.2012. Citováno 2014-04-14.
  15. ^ „Bezpečně opravte databázi RPM“. Citováno 2011-11-11.
  16. ^ „Doplňkový balicí software“. Projekt Fedora. Citováno 2011-11-11.
  17. ^ "Přepnout otáčky na kompresi zstd". Projekt Fedora (Wiki). Citováno 2019-06-02.
  18. ^ „[PATCH] Přidat podporu lzip“. Archivovány od originál dne 04.03.2016. Citováno 2013-10-24.
  19. ^ „Jak zabalit proprietární software“. Citováno 2018-07-02.
  20. ^ „Poznámky k verzi Mageia 3: Správa balíčků“. mageia.org. 2013-05-19. Citováno 2014-04-14.
  21. ^ Bodnar, Ladislav & Smith, Jesse (22.11.2010). „DistroWatch Weekly“. DistroWatch. Citováno 2010-11-22.
  22. ^ „Fórum: Přechod na RPMv4“. Citováno 2018-03-03.
  23. ^ „YP Core - Pyro 2.3“. Yocto Project. 2017-05-12. Citováno 2017-12-04.(archivováno )
  24. ^ „[Openembedded-architecture] Změny, které způsobí přechod z inteligentního na dnf“. Yocto Project. 2017-02-14. Citováno 2018-11-04.

externí odkazy