Hlavní navigace

Apt pinning: namíchejte si vlastní Debian

Petr Krčmář 14. 1. 2014

Apt pinning je metoda, kterou je možné zásadně ovlivňovat chování balíčkovacího systému v Debianu a z něj vycházejících distribucí. Umožňuje udržovat balíčky v konkrétních verzích nebo pohodlně míchat různé distribuční větve či repozitáře třetích stran. Pokud pinning zvládnete, stanete se pánem balíčků.

Balíčkovací systém v Debianu funguje poměrně přímočaře. Prochází seznam zdrojů v souboru /etc/apt/sources.list a adresáři /etc/apt/sources.list.d/ z jednotlivých serverů načítá databázi balíčků, kterou si lokálně uloží. Pracuje pak s nejnovějšími verzemi balíčků, které na různých serverech najde. Ty porovná s nainstalovanými verzemi a dokáže nabídnout jejich aktualizaci.

Pokud jsme uživateli nejjednoduššího scénáře a máme v systému repozitář jedné větve Debianu, pak to funguje krásně. Ne vždy ale chceme sáhnout po nejnovější verzi všech balíčků a vyhovoval by nám jiný model. Typické je to třeba u míchání různých větví Debianu.

Pokud byste jednoduše vložili mezi zdroje repozitáře větví testing a unstable, balíčkovací systém by si všiml, že v některých repozitářích (těch s unstable) jsou novější verze a navrhl by vám aktualizaci celého systému. Pokud ale chcete z unstable jen některé balíčky (třeba novější verzi web serveru), musíte postupovat jinak.

Důležitá poznámka: Velmi často se setkávám s terminologickým problémem ohledně názvů větví stable (stabilní) a unstable (nestabilní). Tato slova neoznačují stabilitu ve smyslu dlouhého běhu Debianu bez havárie, ale ve smyslu změn verzí balíčků. Ve větvi stable se balíčky nemění (verze jsou stabilní) a naopak. Jednoznačnější pojmenování by tedy mohlo znít „statická“ a „pohyblivá“.

Volíme větev

Pokud chcete začít s mícháním větví, budete potřebovat balíčkovacímu systému sdělit, kterou větev si přejete preferovat a dát jejím balíčkům vyšší prioritu. To provedete tak, že vytvoříte soubor /etc/apt/apt.conf.d/00release a do něj zapíšete například:

APT::Default-Release "testing";

Můžete použít větev (stable, testing, unstable) nebo její současné jméno (wheezy, jessie, sid). Pamatujte ovšem na to, že jména se mění a posouvají (kromě sid), kdežto názvy větví zůstávají stejné.

Pokud jste takto zvolili preferovaný repozitář, můžete si do sources.list přidat další repozitáře. Protože jsme neudělali nic dalšího, balíčkovací systém bude o nových balících vědět, ale bude je vesele ignorovat, protože mají nižší prioritu než ty ze zvolené větve. Na první pohled se tedy nebude nic dít.

Důležitá poznámka: Při míchání větví postupujte velmi opatrně a sledujte, co po vás balíčkovací systém chce. Může se vám totiž stát, že vám přes závislosti doporučí aktualizovat polovinu distribuce, což nemusí být to, co chcete. Nedoporučuje se míchat stable a unstable, tyhle repozitáře jsou už od sebe hodně daleko. Nejčastější je naopak míchání testingu s unstable, případně experimental. To není plnohodnotná větev, jen doplňkový repositář k unstable. Pamatujte na to.

O prioritách

Abyste pochopili pinning, musíme se zastavit u systému priorit a popsat si ho detailně. Už jsme zmínili, že volbou výchozí (preferované) větve zvýšíme prioritu konkrétním balíčkům v oné větvi. To je nejjednodušší případ, ale máme mnohem více možností, jak prioritu ovlivňovat a tím měnit chování balíčkovacího systému.

Výchozí hodnoty priority jsou následující:

100
všechny nainstalované balíčky
500
nenainstalované balíky patřící do jiné než výchozí větve
990
nenainstalované balíky, které patří do výchozí větve

Pokud jsme tedy nastavili větve testing a unstable a jako výchozí jsme zvolili testing, pak všechny balíčky v testingu mají prioritu 990, kdežto balíčky v unstable mají prioritu 500 a proto nejsou při instalaci upřednostňovány. To můžeme dočasně změnit pomocí parametru  -t.

# aptitude -t unstable install nginx

Pokud tento příkaz spustíme, získají dočasně balíčky v unstable prioritu 990 a ty v testingu pak 500. Po ukončení příkazu se vše vrátí do původního stavu. Takto tedy můžeme nejjednodušším způsobem zamíchat novější balíčky z vyšší větve do stávajícího systému. Samozřejmě budou dodrženy i všechny požadované závislostí, zejména verze knihoven.

Poznámka: V příkladech používám Aptitude, protože je to v mnoha ohledech lepší a také doporučovaná varianta. Pokud jste ale stále zvyklí na apt-get a odmítáte ho opustit, vězte, že to bude fungovat stejně i s ním.

Pomocí pinningu ale budeme mít za chvíli možnost poměry změnit. K tomu ale bude potřeba o prioritách vědět ještě jednu věc. Platí logické pravidlo, že vyšší priorita přebíjí nižší prioritu, ale zároveň mají některé rozsahy hodnot speciální vliv na instalaci. Balíčkovací systém interpretuje priority takto:

méně než 0
lze jít i do záporných čísel, způsobí úplný zákaz instalace balíčku
0 až 99
nainstaluje balíček jen v případě, že žádná jiná verze nainstalovaná není
100 až 499
nainstaluje balíček, pokud neexistuje jeho novější verze v libovolném repozitáři
500 až 989
nainstaluje balíček, pokud neexistuje jeho novější verze ve výchozí větvi
990 až 999
nainstaluje balíček, i když pochází z jiné než výchozí větve
1000 a více
nainstaluje balíček, i kdyby to mělo znamenat snížení jeho verze (downgrade)

Výchozí větví míníme tu, kterou jsme zvolili dříve. Všimněte si, že žádná běžná priorita (100, 500 a 990) nedovoluje snižování verze balíčků (downgrade). Současné nastavení priorit pro jednotlivé repozitáře zjistíte pomocí výpisu příkazu:

$ apt-cache policy

Sledování větve

Z výše uvedeného plyne chování celého balíčkovacího systému, které ale nemusí být na první pohled úplně zřejmé. Zkusíme si popsat základní scénář. Řekněme, že jsme přidali repozitáře testing a unstable a jako výchozí jsme zvolili testing. Budeme chtít nainstalovat balíček, který je v obou větvích, ale má různé verze. Situace na začátku vypadá takto:

  • nainstalovaná: žádná
  • testing: 1.0
  • unstable: 2.0

Při klasickém aptitude install balíček se upřednostní balíček z testingu, protože má prioritu 990. Balíček z unstable se bude ignorovat – přestože je v novější verzi, má prioritu 500.

Pokud dočasně změníme výchozí repozitář příkazem aptitude -t unstable install balíček, priority větví se prohodí a balíčkovací systém upřednostní novější balíček z unstable a nainstaluje ho. Protože nemůže dojít k downgrade, systém si bude i do budoucna držet novější verzi z unstable.

Časem se může stát, že se v unstable objeví verze 2.1 a situace bude tedy vypadat takto:

  • nainstalovaná: 2.0
  • testing: 1.0
  • unstable: 2.1

Nejvyšší prioritu (990) bude mít samozřejmě verze 1.0, ale ta je nižší než v současnosti nainstalovaná verze 2.0 a bude se tedy ignorovat. Další nejvyšší prioritu (500) má nová verze 2.1 z unstable, která je navíc vyšší než současná nainstalovaná verze. Dojde tedy k aktualizaci.

Zapamatujte si, že systém tímto způsobem sleduje verzi balíčku z dočasně zvolené větve, dokud se ve výchozí větvi neobjeví stejná verze, jaká je právě nainstalovaná. K tomu dříve nebo později pravděpodobně dojde, když novější verze propadne z unstable do testingu. Řekněme, že se do unstable zároveň dostane ještě novější verze. Situace:

  • nainstalovaná: 2.1
  • testing: 2.1
  • unstable: 3.0

Protože nejnovější verze 3.0 má nižší prioritu (500) než verze v testingu (990), bude se systém nadále držet nainstalované verze a v budoucnu už bude sledovat jen novinky v testingu a novinky v unstable bude ignorovat. Přesně tak, jak tomu bylo na začátku.

Tři a víc repozitářů

Tohle funguje moc pěkně, pokud používáme dva repozitáře. Pokud ale nastavíme tři a více, situace se nám zkomplikuje. Repozitáře budou mít stejnou prioritu (kromě výchozího), a tak se nám může stát, že sice zvolíme ručně instalaci z některého z nich, ale při příští aktualizaci bude automaticky námi nainstalovaná verze balíčku přebita novější verzí z úplně jiného repozitáře.

  • nainstalovaná: 1.0
  • výchozí: 1.0
  • repo A: 2.0
  • repo B: 2.1 beta

Pokud jako výchozí dočasně zvolíme repozitář A, správně se nám nainstaluje verze 2.0. Jakmile ale necháme systém aktualizovat, budou mít repozitáře A i B shodně prioritu 500 a aktualizace nám nabídne novější verzi balíčku. To samozřejmě může být to, co chceme (ber odkudkoliv, ale chci to nejnovější), ale obvyklejší schéma je takové, že chceme většinu balíků z jednoho hlavního repozitáře (větve) a ostatní odjinud. Tady právě nastupuje pinning, který nám umožní věci detailně konfigurovat.

Pinning

Poznámka: Pokud chcete míchat repozitáře kvůli novější verzi některého z balíku pro stable, podívejte se nejdříve, jestli není v repozitáři backports. Tam se dostávají novější verze, kompilované pro stable. Pokud tam svůj balíček najdete a použijete, vyhnete se použitím backports řadě problémů, například příliš rozsáhlých aktualizací systému kvůli jednomu balíčku.

Pinning je obecný název pro ruční nastavení priorit jednotlivým balíčkům nebo celým repozitářům. Doslova si tak „připíchnete“ některý zdroj nad ostatní a on získá vyšší prioritu. Vše se provádí v adresáři /etc/apt/preferences.d/, ve kterém si můžete vytvářet konfigurační soubory. Ty se pak načítají podle abecedy.

Formát se skládá ze tří za sebou jdoucích řádků, za kterými následuje jeden řádek prázdný. Trojice vypadá vždy takto:

Package:
Pin:
Pin-Priority:

První položka určuje název balíčku a je možné v ní používat hvězdičku jako žolík. Snadno tak vybereme všechny balíčky nebo balíčky s podobným názvem. Nejčastější je volba všech balíčků v daném repozitáři, takže prostá hvězdička.

Pin specifikuje, odkud námi označovaný balíček pochází. Můžeme vybírat mezi verzí ( version), původem ( origin) nebo vydáním ( release). Verzi zvolíme jednoduše:

Package: nginx
Pin: version 1.2.3
Pin-Priority: 1001

Tím říkáme, že chceme konkrétní verzi, i kdyby na ni měl systém downgradovat. Druhou variantou je původ, kde volíme název serveru, na kterém leží repozitář.

Package: *
Pin: origin "ftp.mojerepo.cz"
Pin-Priority: 990

Nastavujeme prioritu pro všechny balíčky ve svém repozitáři tak, že budou mít stejnou váhu jako balíčky ve výchozí větvi. Rozhodovat pak bude jen vyšší verze toho kterého balíčku. Buď se nainstaluje z našeho FTP nebo z výchozího repozitáře.

Poslední variantou je vydání (release), kde je možné specifikovat konkrétní variantu balíčku. K tomu slouží další parametry, kterými je možné zvolit konkrétní archiv ( a=), jméno větve ( n=), verzi Debianu ( v=), oblast ( c=) a některé další méně podstatné (jsou popsané v man apt_preferences). Tyto položky je možné kombinovat, oddělte je čárkou. Například:

Package: *
Pin: release a=stable, c=main, v=7*
Pin-Priority: 1001

Poznámka: V mnoha položkách je možné využít hvězdičku. To se hodí, pokud chceme balíčky verze 1.2.3, ale zároveň neodmítáme opravné verze, které Debian označuje číslem za pomlčkou. Pokud tedy chceme verzi 1.2.3–1 a nebráníme se následující aktualizaci na 1.2.3–2, použijeme označení 1.2.3*.

Tímto způsobem je možné si nastavit různé priority pro různé repozitáře, případně třeba zablokovat aktualizaci konkrétních balíčků. Můžeme docela dobře míchat různé repozitáře, různé balíčky i různé větve distribuce.

Při nesprávném použití pinningu se ovšem můžete dostat rychle do úzkých nebo můžete dostat systém do stavu, v jakém ho nechcete mít. Často už pak neexistuje cesta zpět, protože downgrade balíčků přináší mnoho problémů. Dávejte tedy vždy dobrý pozor na to, co vám vypisuje požadavek na aktualizaci a zda se s balíčky chystáte udělat přesně to, co jste zamýšleli.

Použité zdroje

Našli jste v článku chybu?

14. 1. 2014 12:56

Věřím tomu, že informace uvedené v odkazovaném článku "Je lepší aptitude" jsou zastaralé a minimálně dve verze Debianu už je naopak doporučováno používat apt-get místo aptitude, které zastaralo (nebylo udržováno). Apt-get nyní prý lépe než aptitude řeší závislosti a různé situace, které mohou při práci s balíčky nastat.

14. 1. 2014 12:21

orm (neregistrovaný)

Rád bych přidal své zkušenosti s mícháním balíčků v Debianu, třeba se někomu budou hodit.

1, Použití balíčků z backports

Pokud použijete balíček z backports, tak se může stát, že při upgradu na nový stable dojde k chybě, protože verze z nového stable počítá při upgradu s verzí, která je ve starém stable a ne s mezi verzí, kterou jste si tam nahráli z backports. Moje poslední zkušenost např. Roundcube.

2, Použití balíčků z testingu a zároveň automatický upgrade pomocí cron-apt

Pokud si…

Lupa.cz: Avast po spojení s AVG propustí 700 lidí

Avast po spojení s AVG propustí 700 lidí

Root.cz: 250 Mbit/s po telefonní lince, když máte štěstí

250 Mbit/s po telefonní lince, když máte štěstí

Podnikatel.cz: Přehledná titulka, průvodci, responzivita

Přehledná titulka, průvodci, responzivita

Lupa.cz: Seznam mění vedení. Pavel Zima v čele končí

Seznam mění vedení. Pavel Zima v čele končí

Měšec.cz: Kdy vám stát dá na stěhování 50 000 Kč?

Kdy vám stát dá na stěhování 50 000 Kč?

Podnikatel.cz: Podnikatelům dorazí varování od BSA

Podnikatelům dorazí varování od BSA

Podnikatel.cz: Babiše přesvědčila 89letá podnikatelka?!

Babiše přesvědčila 89letá podnikatelka?!

Podnikatel.cz: EET: Totálně nezvládli metodologii projektu

EET: Totálně nezvládli metodologii projektu

DigiZone.cz: Sony KD-55XD8005 s Android 6.0

Sony KD-55XD8005 s Android 6.0

Vitalia.cz: Dáte si jahody s plísní?

Dáte si jahody s plísní?

Měšec.cz: Jak vymáhat výživné zadarmo?

Jak vymáhat výživné zadarmo?

Vitalia.cz: Láska na vozíku: Přitažliví jsme pro tzv. pečovatelky

Láska na vozíku: Přitažliví jsme pro tzv. pečovatelky

Lupa.cz: Insolvenční řízení kvůli cookies? Vítejte v ČR

Insolvenční řízení kvůli cookies? Vítejte v ČR

Vitalia.cz: Znáte „černý detox“? Ani to nezkoušejte

Znáte „černý detox“? Ani to nezkoušejte

Vitalia.cz: Jsou čajové sáčky toxické?

Jsou čajové sáčky toxické?

Lupa.cz: Co se dá měřit přes Internet věcí

Co se dá měřit přes Internet věcí

Vitalia.cz: Mondelez stahuje rizikovou čokoládu Milka

Mondelez stahuje rizikovou čokoládu Milka

Vitalia.cz: Často čůrá a má žízeň? Příznaky dětské cukrovky

Často čůrá a má žízeň? Příznaky dětské cukrovky

Vitalia.cz: Baletky propagují zdravotní superpostel

Baletky propagují zdravotní superpostel

Root.cz: Certifikáty zadarmo jsou horší než za peníze?

Certifikáty zadarmo jsou horší než za peníze?