Debian a Fedora se snaží vyřešit problém se závislostmi

Distribuce Linuxu čelí problému zvyšování závislostí projektů počet závislostí pro Python, Perl a Ruby kód je zachován Projekty JavaScriptu v rozumných mezích procvičují dělení na velmi malé knihovny, často provádějící jednoduchou funkci.

Repozitář NPM již má přes milion balíčků a typické aplikace odkaz na stovky závislostí, které zase mají své vlastní závislosti, takže je obtížné udržovat a distribuovat tradiční balíčky s aplikacemi JavaScriptu v distribucích Linuxu.

Kvůli těsnému propletení závislostí knihoven JavaScriptu aktualizace jakéhokoli balíčku s takovými knihovnami v distribuci může rozbít další balíčky.

Vazby verzí zhoršují problém: Jedna knihovna může ke stabilnímu spuštění vyžadovat jednu verzi závislosti a jiná může vyžadovat jinou.

Mnoho projektů vyžaduje, aby nejnovější verze knihoven fungovaly, které ne vždy splňují požadavky na stabilitu distribuce (neustálý vývoj se procvičuje v ekosystému Node.js pomocí nejnovějších verzí frameworků a distribuce vyžaduje podporu několik let).

Pokusy o opravu verzí balíků pouze v distribuci vést ke zvýšení zastaralých verzí v úložišti, které nebyly roky aktualizovány. Narušení údržby jednoho balíčku nepříznivě ovlivní mnoho dalších balíčků a způsobí ještě více problémů.

Dále, lkřížové závislosti vést k tomu, že mnoho knihoven Node.js bude nemožné odinstalovat ze systémucož vám zase zabrání odinstalovat další programy Node.js.

Za tímto účelem projekt Fedora nedávno schválil plán zastavení výchozího vytváření samostatných balíčků s knihovnami používanými v projektech založených na Node.js.

Rozhodl se, počínaje Fedorou 34, dodávat pouze základní balíčky pro Node.js s tlumočníkem, hlavičkami, primárními knihovnami, binárními soubory a základními nástroji pro správu balíků (NPM, yarn).

V aplikacích úložiště Fedory, které používají Node.js, je povoleno vložit všechny existující závislosti do balíčku bez dělení a oddělování knihoven použitých v samostatných balíčcích.

Vkládáním knihoven se zbavíte nepořádku malých balíčků, zjednodušíte údržbu balíčků (dříve správce udržoval více času prohlížením a testováním stovek balíčků s knihovnami než v hlavním balíčku s programem), ušetří infrastrukturu před konflikty knihoven a vyřešit problémy s propojením na verze knihoven (správci do balíčku zahrnou testované a produkčně testované verze).

Nevýhodou integrace bude komplikace procesu podávání oprav zranitelnosti v knihovnách, což bude vyžadovat koordinovanou práci správců všech balíčků, které obsahují zranitelnou knihovnu. Existuje nebezpečí, že balíček zapomene aktualizovat zranitelnou integrovanou knihovnu a balíček zůstane bez povšimnutí.

Vývojáři Debian také diskutuje o přechodu na podobný model integrace závislostí balíčku. Kromě Node.js se diskuse dotkne vytváření balíčků pro platformu Kubernetes a projektů v jazycích PHP a Go, u nichž existuje tendence dělit se na malé závislosti. Dosud nebylo učiněno žádné rozhodnutí, ale doufá se, že se problém časem jen zhorší a dříve či později bude projekt donucen něco udělat.

Webové rozhraní gsa (Greenbone Security Assistant) pro bezpečnostní skener gvm (Greenbone Vulnerability Management) je uváděno jako příklad problémů, které mají správci balíčků.

Ukázalo se, že verze gsa dodávaná v Debianu je nekompatibilní s novějšími verzemi gvm, ale nebylo možné aktualizovat gsa na aktuální verzi, protože obsahuje významné změny a ke stažení potřebných knihoven Node.js používá npm.

Požadovaných knihoven je příliš mnoho a vyžadují vytvoření nových balíků v Debianu, aby je někdo udržoval, protože pravidla Debianu zakazují načítání externích komponent během procesu sestavování.

zdroj: https://lwn.net/