DNF 1.0

Byla vydána verze 1.0 správce RPM balíčků DNF (Dandified Yum). Jedná se o nástupce správce balíčků Yum. Od Fedory 18 bylo možné DNF používat současně s výchozím Yumem. Ve Fedoře 22 bude výchozím správcem balíčků DNF. Více v článku Yum is dead, long live DNF.

12.5.2015 13:00 | Ladislav Hagara | Nová verze

Komentáře

[tyu]

DNF - to je to, co umí bez varování smazat aktuální kernel, ale už ho neumí nainstalovat zpět?

[sid]

Bez varovania myslite to, ze zadate yes na otazku? Ocakaval by som ze dnf primarne je urcene pre ludi co aspon letmo tusia co robia.

[ikar]

Někdo možná tuší, side, někdo možná netuší - do yumu se protection dodělávala poté, co se ukázalo, že tento typ incidentů je častější než bylo únosné. Kolikrát jsem viděl v návodech k yumu použití "-y". Kolikrát se objevil v závislostech k mazání dlouhatánský seznam, mezi který se krčily i kritické balíčky. Je to další soft, který dělali nadšenci bez zkušeností, zato přesvědčení o své pravdě. Kluci z Fedory by nepřekousli zypper, btw.

[Sid]

Ciastocne suhlasim, ale bral som to tak, ze snad coraz viac bude bezny uzivatel (odchovany nejakym mobilnym OS) pouzivat nieco ako Gnome Software pripadne ekvivalenty v inych prostrediach. Ale inac hej, pri odstranovani dependencies to moze by naozaj schopvane a tym padom pri 50 zavislostiach mimo pozornosti. Mozno by by si dnf mohlo drzat nejaky zoznam balickov kde by sa vyzadovalo explicitne potvrdenie aj ked zadas -y. Kludne cez nejaky plugin aby sa nezasral kod ako je to podla mna teraz v yum.

[MarSik]

No vzhledem k tomu, ze dnf pouziva libsolve stejne jako zypper… tak nevim jak je to s tim neprekousnutim. Spis slo o to, ze Fedora ma malinko jine pozadavky nez SuSE (nicmene neznam strukturu zavislosti a balickovaci guidelines v SuSE).

[pavlix]

No vzhledem k tomu, ze dnf pouziva libsolve stejne jako zypper… tak nevim jak je to s tim neprekousnutim.

Zjevně k tomu nepřekousnutí došlo, když se musel vyvinout samostatný projekt a ne třeba pár pluginů do zypperu.

Spis slo o to, ze Fedora ma malinko jine pozadavky nez SuSE (nicmene neznam strukturu zavislosti a balickovaci guidelines v SuSE).

Tak obojí jsou to binární RPM distribuce, takže z toho žádné zjevné rozdíly nevyplývají a tedy bez jejich konkrétního popisu nemá asi diskuze moc smysl. Ale i v případě zásadních rozdílů by bylo záhadno buď doložit nemožnost nebo neúspěšný pokus o přizpůsobení/pluginování zypperu nebo přiznat NIH syndrom. Fedora je komunitní distribuce a jako taková by měla být za všech okolností komunitě prezentována upřímně.

[Stevko]

Má DNF changelog plugin? Zobrazenie noviniek pred inštaláciou balíčkov.

[Jiří J.]

Ale prdlajs "Dandified" - Aleš mi několikrát zdůrazňoval, že "DNF" není akronym.

[pavlix]

Jsem jediný, komu přijde pitomé, že se ten příkaz nejmenuje normálně yum a pokud už se musejí podporovat dva různé systémy, není to řešeno jako v debian alternatives? Pracuju denně s různými verzemi distribucí, hlavně Fedory a RHELu, a prudí mě každý základní úkon, který musím řešit v distribucích různě, ať už je to způsobeno zavedením systemd, dnf nebo čehokoli jiného.

[Já]

Asi. Samo o sobě to vůbec pitomé není, protože až doposud nebyl dnf úplná náhrada, ne nutně všechny věci v dnf šly, a tak dál. Přepínat to ve stylu alternatives je dost špatný návrh. V F22 by to mělo fungovat tak, že yum řekne, že yum je zavržený a samo to pustí dnf se stejnými parametry, takže víceméně transparentně.

Základní úkony jde všude dělat víceméně stejně s packagekitem nebo něčím. Má i cli udělátko pkcon... Jinak je principiálně veleabsurdní chtít všechny věci ve všech verzích stejné, neboť to velmi definitivně popírá celý jejich smysl.

[pavlix]

Samo o sobě to vůbec pitomé není, protože až doposud nebyl dnf úplná náhrada, ne nutně všechny věci v dnf šly, a tak dál.

Taky jsem se mu do poslední chvíle vyhýbal, jenže teď už mi starý yum nefunguje, takže důvody zjevně pominuly.

Přepínat to ve stylu alternatives je dost špatný návrh.

Osobně to považuju za jednu z věcí na Debianu geniálních.

V F22 by to mělo fungovat tak, že yum řekne, že yum je zavržený a samo to pustí dnf se stejnými parametry, takže víceméně transparentně.

Víceméně. Ale vyblije to několik řádků informací, pak se to na chvíli kousne a pak teprve to pustí ten dnf, nebo jsem něco špatně pochopil? Transparentní by bylo, kdyby se F22 s novou verzí nástroje používala stejně jak F21 se starou verzí až na jednotlivé změněné nebo zavržené volby. Přecijenom se obě varianty vyvíjejí pod jednou střechou a bylo by logické udržovat různé názvy jen do doby, než se ujasní, zda je nový vývoj úspěšny a lze ho tedy použít jako náhradu.

Ještě neřeknu, kdyby měl nový nástroj inteligentní název a ne tři náhodná písmena, za kterými si vždy představím jenom „do not fuck (up)“.

Základní úkony jde všude dělat víceméně stejně s packagekitem nebo něčím. Má i cli udělátko pkcon...

Jestliže pkcon není ani ohlašovanou ani úplnou náhradou za yum, bylo by snad lepší ho do této diskuze ani nezatahovat.

Jinak je principiálně veleabsurdní chtít všechny věci ve všech verzích stejné, neboť to velmi definitivně popírá celý jejich smysl.

Prachsprostá manipulace.

[Ruža Becelin]

Hmm, kvuli tomuhle uz mam dlouhou dobu wrapper, co mi spousti spravny prikaz s argumenty v zavislosti na tom, jestli je v systemu yum/apt-get/zypper/emerge

[pavlix]

Já bych k tomu rád přidal ještě wrapper na vybrané systemd/non-systemd věci a možná by nebylo špatné to udržovat jako projekt co já vím třeba na githubu.

[Ruža Becelin]

Jo, to neni spatny napad, pokud se dokopu k tomu to trochu procistit, tak neco takoveho spacham...

[Já]

Říkají tomu ten packagekit ;)

[pavlix]

Nikoliv.

[Já]

No tak počkat, pokud chci používat distribuční nástroj, tak se asi smířím s tím, že se vyvíjí a mění s dalšíma verzema. Nikdo nikdy nikomu neslíbil, že yum bude navždy, že bude jediným nástrojem, nebo že se bude furt chovat stejně. V releaae notes je změna popsána, holt je třeba si to přečíst a chovat se podle toho. Pokud chci nástroj, který naopak změny skrývá a sjednocuje chování a interface i přes různé distribuce, tak použiju ten packagekit. Tam naopak příslib stability a trvalé stejnosti je.

Ostatně, podporují se víceméně jen dvě verze fedory a jen dost krátce, tak nikomu stejně nehrozí, že by měl pět různých systémů najednou. Red Hat je jiná distribuce. Taky mi ale trochu vadí, že tam dnf zatím, ani volitelně, není. Ale protože tam mě naopak zajímá hodně verzí, stejně se musím smířit s tím, že jsou jiné.

[pavlix]

No tak počkat, pokud chci používat distribuční nástroj, tak se asi smířím s tím, že se vyvíjí a mění s dalšíma verzema.

On tu někdo kritizoval změny v yumu mezi verzemi Fedory?

Nikdo nikdy nikomu neslíbil, že yum bude navždy, že bude jediným nástrojem, nebo že se bude furt chovat stejně. V releaae notes je změna popsána, holt je třeba si to přečíst a chovat se podle toho.

On tu někdo psal opak?

Ostatně, podporují se víceméně jen dvě verze fedory a jen dost krátce, tak nikomu stejně nehrozí, že by měl pět různých systémů najednou.

Rozdíl se projeví už u dvou instalací, více instalací poslouží jen dalšímu zmatení bez ohledu na to, zda jsou různé či nikoliv.

Red Hat je jiná distribuce.

RHEL a kompatibilní distribuce jsou sice teoreticky jiné distribuce, ale projekt Fedora pro ně z dist-gitu vydává balíčky, viz EPEL. Neuč orla lítat. :)

[little.owl]

Jsem jediný, komu přijde pitomé, že se ten příkaz nejmenuje normálně yum

Jediny asi ne, nicmene vzhledem k rozsahu prepracovani, kdy se jedna v podstate o novou aplikaci, to dava smysl.

[MarSik]

Jestli ono to nebude i kvůli licenci :) Nesmíš používat název projektu k propagaci svého projektu (tohle je pokud vím i v dvouřádkové BSD).

[pavlix]

Jestli ono to nebude i kvůli licenci :)

Nebylo by záhodno přestat mlžit? Je to kvůli licenci? Lze to doložit nějakým oficiálním zdrojem?

tohle je pokud vím i v dvouřádkové BSD

Je dost krátká na to, abysis to mohl nejprve ověřit.

[Rezza]

Proc se nejmenuje stejne? Trosku politika - nekdo by rekl kompromis, trosku to, ze se proste jako yum v nekterych pripadech nechova. Proc to nejsou alternativy? Protoze yum neni alternativa a nemel by ho nikdo pouzivat, pokud nema opravdu hodne dobry duvod. Ten deprecated yum se opravdu nechava jen pro ty veci, ktere se proste nestihly prepsat na DNF a cim driv zemre, tim lip. Vice na FESCo #1312 a Replace Yum With DNF Change.

Jinak odpovida to i na tvou otazku ohledne NIH a Zypperu. Kdyby byl YUM NIH, tak nepochazi z jine distribuce a proste ten rozdil uz se stal leta davno. A on boli switch z YUM na Dnf, jak by bylel na neco jineho? To neni jen tool pro blazny, co neradi pouzivaji GUI a PackageKit, ale je na to navazano milion veci. Takze je super, ze Zypper i DNF pouzivaji stejny spodek a jen vrch je prizpusoben dane distribuci.

[little.owl]

Richard Hughes to resil uz skoro pred rokem zde.

[čtenář]

Na závodech se DNF používá pro Did Not Finish... Doufám, že update přes DNF nebude ten případ.

[benitto]

DNF pochazi od disjunctive normal form a v tomhle kontextu jsou to formule, ktere zere SAT solver.

neco jako:

A pozadujeme instalaci baliku A

-A | B1 | B2 balik A vyzaduje zavislost poskytovane B1 nebo B2

-B pozadujeme odinstalaci

takto nejak vypadaji formule, ktere se predhodi SAT solveru a ten vyplivne reseni, coz je jedna z nejvetsich vyhod SATsolver based dep solveru, protoze pokud reseni existuje, solver ho najde, ne jako yum ci apt-get neschopny reagovat na dostupnost vyssi verze, ktera ovsem nevede k reseni.