Těchto 4 správce balíčků přežilo Linuxové distribuce, které je vytvořily

Linuxové distribuce jsou podivně smrtelné pro projekty, které věnují tolik času hlásání stability. Distribuce může ztratit firemní podporu, rozpadnout se na forky, změnit nadaci nebo vytratit se z průmyslové debaty, až přežije jen jako mlhavá vzpomínka na obrazovku instalátoru, kterou jste používali před lety. Správce balíčků, který přitom zavedla, často pokračuje bez většího zájmu, procházející historií Linuxu se zachovaným grafem závislostí a nezměněným účelem.

To je ta zábavná část správců balíčků. Nejsou to jen příkazy, které si kopírujete z fóra a doufáte, že váš systém nevypukne v plamenech. Jsou to infrastruktura, a infrastruktura často přežije branding. Distribuce může zmizet, zmenšit se nebo přejít do jiné role, ale pokud její nástroje řešily skutečný problém, tyto nástroje mají tendenci najít nový domov. Někdy se stanou základní vrstvou pro enterprise Linux. Někdy se stanou kompatibilní svalovou pamětí. Někdy nakonec končí skryté uvnitř build systému pro zařízení, která vůbec nevypadají jako distribuce, která je inspirovala.

otáčky za minutu

Formát balíčků Red Hat Linuxu se stal základem pro všechny

RPM je zjevně místo, kde začít, protože je pravděpodobně nejúspěšnějším příkladem balíčkovacího nástroje, který unikl ze svého původního kontextu distribuce. Stará řada Red Hat Linux skončila na začátku 2000. let, přičemž Fedora se stala komunitní větví a Red Hat Enterprise Linux stabilní, podporovanou verzí přátelskou k předplatnému, postavenou pro firmy, které si oblíbily fráze jako „certifikovaná platforma“. RPM mezitím nesbalil své makra a neodešel do důchodu.

Původně známý jako Red Hat Package Manager — později přijímající chytrý, rekurzivní akronym „RPM Package Manager“ — poskytl softwaru Linux disciplinovanější způsob, jak instalovat, dotazovat se, ověřovat, aktualizovat a odstraňovat. To nyní zní všedně, ale „všední“ je kompliment, když alternativou je ručně rozbalovat tarbally a zjistit, že váš systém se stal scénou závažného porušování závislostí.

Důležitá poznámka je, že Red Hat nezmizel. Stal se vlivnějším, ne méně. Co RPM přežilo, byl původní kontext Red Hat Linux, který mu dal jeho jméno. Dnes RPM zůstává základní vrstvou pro Fedora, RHEL, CentOS Stream, AlmaLinux, Rocky Linux, openSUSE, Mageia, OpenMandriva, Oracle Linux a mnoho podnikových softwarových distribucí. Většina uživatelů s ním každý den přímo nezachází, protože DNF, Zypper a další front-end nástroje stojí nad ním a spravují balíčky na Linuxových distribucích založených na RPM, ale to jen potvrzuje pointu. RPM se stalo instalatérskou soustavou a dobrá instalatérská soustava není něco, nad čím byste každé ráno přemýšleli. Rychle si toho všimnete, když přestane fungovat.

Mňam

Linie aktualizátoru Yellow Dog se stala svalovou pamětí Red Hatu

YUM má jedno z těch jmen Linuxu, která zní jako vtip, dokud si neuvědomíte, kolik serverové historie se v ní skrývá. Yellowdog Updater, Modified pochází z linie Yellow Dog Updater (yup), ale samotný nástroj byl vyvinut na Duke University, aby byla správa balíků založených na RPM méně bolestivá. Toto rozlišení je důležité, protože YUM nebyl jen správce balíků Yellow Dog Linuxu, který se toulal do území Red Hat. Bylo to přepsání a evoluce nápadu, který vyrostl daleko za svůj původní PowerPC-inspirovaný původ. Jeho úkol byl jednoduchý k vysvětlení a slavný v zážitku: přestat nutit lidi, aby ručně doháněli závislosti RPM.

Než se nástroje jako YUM staly běžnými, instalace softwaru na systému založeném na RPM mohla zahrnovat ponurý lov prostřednictvím vnořených závislostí. Chtěli jste jeden balíček, pak chtěl tři knihovny, potom tyto knihovny něco dalšího, a nakonec jste si kladli těžké otázky o svých víkendových plánech. YUM tento proces zjednodušil tím, že pracoval s repozitáři, řešil závislosti a stahoval potřebné balíčky.

Po dlouhou dobu byl YUM správcem balíčků, kterého jste očekávali používat na Fedora, CentOS, RHEL, Scientific Linux, Oracle Linux a dalších systémech založených na RPM. Pokud jste se v té době učili správu Linuxu, yum install pravděpodobně žije ve stejném šuplíku vaší paměti jako service httpd restart a mírný strach z poškozených úložišť.

Zábavný příběh o přežití zde není v tom, že YUM zůstává zářivou budoucností. Není tomu tak. Fedora přešla na DNF jako výchozí příkazový správce balíčků před několika lety a moderní RHEL používá technologii DNF pod kapotou. Nicméně Red Hat ponechal termín yum pro kontinuitu. Když se podíváte, jak se APT, DNF a YUM porovnávají, zjistíte, že na novějších systémech yum a dnf často fungují jako kompatibilní cesty do stejného moderního mechanismu.

APT-RPM

Frankensteinův monstru, který přežil brazilského průkopníka

APT-RPM je položka, kterou bych zahrnul pro čtenáře, kteří si rádi objevují skryté chodby v historii Linuxu. Koncem 90. let a začátkem 2000. let byl linuxový ekosystém rozdělen nejen podle desktopových prostředí a argumentů init, ale také podle filozofií správy balíčků. Na jedné straně Debian měl apt-get, který byl magický, protože dokázal automaticky vyřešit a stáhnout závislosti softwaru. Distribuce založené na RPM měly na druhé straně formát RPM, který byl výkonný a široce používaný. Nicméně každodenní zkušenost se stále mohla změnit v peklo závislostí, pokud jste spravovali balíčky ručně.

Conectiva se na ten problém podívala a zvolila chaos, ale užitečný druh. Brazilská distribuce Linuxu měla ráda balíčky RPM, ale zjevně si neužívala bolest, která často při jejich správě nastávala. Takže její vývojáři přizpůsobili Debianský nástroj Advanced Packaging Tool, aby fungoval s databázemi RPM místo Debianích .deb balíčků. APT-RPM poskytoval uživatelům RPM zážitek ve stylu apt ještě před tím, než se YUM a DNF staly samozřejmými řešeními. Dokázal instalovat, aktualizovat a odstraňovat software, zatímco automaticky řešil závislosti, což dávalo pocit, že někdo pašoval Debianí pohodlí do oblasti RPM. Pokud jste byli uprostřed starého rozdělení v správě balíčků, bylo to obrovské.

Conectiva sama o sobě nepřežila jako nezávislá distribuce. V roce 2005 získala Conectivu společnost Mandrakesoft a spojená firma se stala Mandrivou. Mandriva se později rozpadla a zmizela do historie Linuxu, zanechávaje za sebou projekty, forky a vzpomínky na dobu, kdy byl desktopový Linux přeplněným bazarem, kde každý křičel přes různé formáty balíčků. Mezitím APT-RPM pokračoval mnohem déle než samotné jméno Conectiva. Distribuce jako ALT Linux, Vine Linux a PCLinuxOS ho používaly jako vážný nástroj pro správu balíčků. PCLinuxOS konkrétně spojila APT-RPM se Synaptikem po mnoho let, čímž vytvořila fantasticky zvláštní zážitek správy balíčků RPM prostřednictvím nástrojů, které mnoho uživatelů spojovalo s Debian-style systémy.

Moderní upozornění je důležité: APT-RPM už není budoucnost. Jeho vývoj ochladl, širší svět RPM se konsolidoval kolem YUM a poté DNF a dokonce i PCLinuxOS se přibližuje k DNF, protože jeho starý stack APT/Synaptic už není dostatečně aktivně udržován pro dlouhodobé používání.

Přenášení

Gentoo nikdy nezemřel, ale Portage cestoval dál, než se očekávalo

Portage je zde nejobtížnějším vstupem, protože Gentoo nezaniklo. Je stále aktivní, stále hrdě Gentoo a stále čeká na ten správný typ člověka, který se rozhodne, že kompilace prohlížeče je cvičením charakteru. Takže příběh není o tom, že Portage přežilo Gentoo stejným způsobem, jakým RPM přežilo Red Hat Linux nebo APT-RPM přežilo Conectivu. Lepší příběh je, že Portage přerostlo hlavní záběr Gentoo.

Gentoo kdysi zaujímalo zvláštní místo v linuxové kultuře. Během raných a středních 2000. let jeho používání přinášelo určitý prestiž. Byla to distribuce pro lidi, kteří chtěli, aby každý balíček byl zkompilován speciálně pro jejich hardware, každá funkce byla kontrolována přes pečlivě nastavené USE flagy a každý kousek systému byl sestaven ze zdrojového kódu. Doby kompilace mohly být náročné, přesto práva na chlubení a hluboká přizpůsobitelnost často stály za to, aby lidé přešli na Gentoo Linux i přes bolest hlavy. Jak se Linux stal dostupnějším a distribuce jako Ubuntu zpřístupnila zážitek, který vyžadoval minimální úsilí, vliv Gentoo postupně ustupoval z hlavního proudu konverzace.

Portage se však nikdy nevydal stejnou cestou.

Portage je systém správy balíčků založený na zdrojových kódech, postavený kolem ebuildů, profilů, přetížení, logiky závislostí a USE flagů, které umožňují povolit nebo zakázat funkce při kompilaci a umožňují systém detailně upravit.

Tato úroveň flexibility je také důvodem, proč Portage našel nepravděpodobný druhý život při vývoji Chromium OS a Chrome OS. Vývojové prostředí Chromium OS společnosti Google používá Portage od Gentoo a emerge pro správu balíčků. V tomto kontextu Portage není používán proto, že by někdo chtěl desktop pro retro nadšence. Používá se proto, že jeho model ebuildů, překryvů (overlays), konfigurace pro jednotlivé desky, křížové kompilace a funkčních vlajek dobře odpovídá neuspořádané realitě vytváření obrazů operačního systému pro různá hardwarová cíle.

Odolnost je stále patrná v práci Googlu na migraci ChromeOS na Bazel. I když se ChromeOS přesouvá směrem k Bazelu, starý model konfigurace Portage je příliš hluboce zakořeněný, než aby ho bylo možné odstranit jedním hrdinským commitem. Návrh migrace diskutuje repozitáře ebuildů, overlaye, USE flagy a obtížnost přímého překladu expresivního konfiguračního modelu Portage do konceptů Bazel.

Distribuce umírají; dobré nástroje ne

Správci balíčků řeší problém, který nezmizí, když financování distribuce vyschne nebo se její cílové publikum přesune jinam. Dokud bude potřeba software na Linuxových systémech instalovat, aktualizovat a odstraňovat, jakýkoli nástroj, který tuto práci zvládá dobře, si najde nové uživatele.

Distribuce získávají snímky obrazovky a názvy vydání, ale správci balíčků se často stávají mechanismem, který Linux používá dlouho poté, co původní příběh pominul.