Vlákno názorů k článku Ubuntu končí s Unity a vrací se ke Gnome, ruší se i Mir a telefony od Michal - Kéž by stejným způsobem i RedHat prozřel, že...
-
qwertz (neregistrovaný)
Jenže RedHat si skutečně platí hromadu vývojářů a má tak sílu něco změnit. Většina ostatních pak raději akceptuje řešení od RedHatu, protože pro samostatný vývoj opačným směrem nemají lidi ani peníze.
Jediný, kdo RedHatu trošku konkuruje je SUSE - viz třeba libzypp, který je kompatibilní s YUM repozitáři, a který nakonec RedHat převzal. A i tady to udělali napůl, perfektní zypper ignorovali, a místo toho si uplácali vlastní DNF (opět v pythonu?), nějaké smysluplné vysvětlení k tomu asi nebylo zveřejněno....
-
"a místo toho si uplácali vlastní DNF (opět v pythonu?), nějaké smysluplné vysvětlení k tomu asi nebylo zveřejněno...."
To vysvětlení tam samozřejmě bylo. Problém Yumu nebyl v jeho UI, ale v jádru, které už bylo prostě neudržovatelné. Tak se nahradilo libsolvem od SUSE. UI ale zůstalo prakticky identické, takže kdo byl zvyklý na Yum, neměl s přechodem na DNF problém. Původní plán byl dokonce s ostrou verzí přejmenovat DNF na Yum, ale vzhledem k tomu, že se to chová a ovládá jen hodně podobně a ne 100% stejně, tak se rozhodlo, že bude lepší, když to bude mít jiný název. Zypper může být perfektní, ale IMHO přechod na něj by přinesl víc problémů než užitku.
-
qwertz (neregistrovaný)
Kromě potenciálně rozdílné systaxe některých příkazů (install, upgrade, update apod.) v čem je to tak hrozný problém? Volání z externích aplikací typu instalátor snad není takový problém změnit, zypper umí YUM repozitáře, takže ty snad mohly zůstat stejné, rozhodně mi to nepřijde tolik práce jako vývoj nového nástroje. Kdyby zypper nebyl YUM compatible a nepoužíval tak jako tak RPM, tak dejme tomu. Ale takhle?
-
MarSik (neregistrovaný)
RH libzypp nepřevzal. DNF totiž nepoužívá libzypp, ale libsolv, což je obecný SAT solver napsaný pro účely řešení závislostí balíků (taky od SUSE). DNF je napsaný v Pythonu, což je vhodný jazyk pro vysokoúrovňové lepidlo logiky. Výpočetně náročné je právě řešení závislostí a to se řeší v libsolv. Yum měl v Pythonu i tu výpočetní část a ty heuristiky tam nebyly moc dobré.
Rozumné vysvětlení je tudíž jednoduché: SUSE a RH nemají 100% kompatibilní přístup k řešení závislostí a struktuře repozitářů. Rozdíly jsou třeba v souborových závislostech, java balíčcích - Provides: mvn(group:artifact:jar) - a podobně. Proto stejný přístup, ale vlastní software. Ona ani ta verze používaného RPM asi nebude úplně stejná.
Krom toho, admini a firmy znají Yum a je docela dobrý nápad udržet příkazovou řádku alespoň trošku kompatibilní.
-
qwertz (neregistrovaný)
libzypp ve Fedoře se řešil od začátku, a evidentně je o něj stále zájem:
https://bugzilla.redhat.com/show_bug.cgi?id=1427182taky bychom se mohli bavit o tom, zda závislost package manageru na pythonu je úplně rozumná.
-
MarSik (neregistrovaný)
A je potřeba rozlišovat dvě vrstvy: Yum/DNF - v Pythonu, umí stahovat balíky, automaticky řešit závislosti a RPM - v C, stará se o samotnou databázi balíků a instalace. Pro recovery stačí RPM.
Nicméně Python je ve Fedoře hodně zakořeněn a patří mezi critical path balíky, stejně jako třeba libc nebo NetworkManager. https://fedoraproject.org/wiki/Critical_path_package
Celé tohle je teoretické, při opravdu velkém průšvihu je možnost nabootovat z recovery media a tam ten Python fungovat bude.
