Slasti a strasti balíčkovacího systému (diskuse)

[Vin]

Zkus si nainstalovat apt

[extender]

apt4rpm je příšernost sama. Navíc neumí reverzní závislosti, pokud vím. Co se týče RPM tak nic lepšího než zypper snad ani neexistuje.

[David Šmíd]

Nám (uživatelům PCLinuxOSu) se celkem osvědčil. Ještě můžeš zkusit Smart.

---

[extender]

Mě seosvědčil zypper. Ale budu muset dělat "body obnovení" kvůli odinstalacím. A propos- nevíte někdo jak to udělat jinak než v Yastu pomocí ukládání xml souborů? Nějaká automatika? syntaxe pro zypper?

[David Šmíd]

Co starý dobrý RPM rollback ?

---

[David Šmíd]

Jediné, co je třeba, aby to fungovalo, je řádka "%_repackage_all_erasures 1" v souboru /etc/rpm/macros.

---

[mamlas]

zkus si nainstalovat gentoo :)

[AsciiWolf]

+1

[Grunt]

A proč ne Arch?

[Ladislav Hagara]

nebo Source Mage

[slayn]

chvilemi se mi zda ze jsme tu jen dva co SM povazuji za nejlepsi system ze vsech:D

[stanger]

Tohle je nejvetsi problem suse a snad krome fedory uz je podobne vyspelej nastroj jako apt nebo jeste schopnejsi snad vsude.

[Kyosuke]

ZYPP by měl být "ještě schopnější než apt". Jen jsou ty schopnosti zaměřené někam trošku jinak. Nicméně si pánové kolem Red Carpetu možná měli rozmyslet, jestli nemají příliš velké ambice a jestli by se neměli zaměřit na přízemnější věci. Každopádně je ale velká pravděpodobnost, že pisatel blogpostu zažívá obyčejný PEBKAC. (Dostatečně pokročilé balíčkovací systémy jsou nerozlišitelné od černé magie? )

[stanger]

Co vsechno zypp umi nebo neumi skutecne nevim, ale tyhle podle me zakladni veci tam chybi.

Dovedu predstavit, ze dostat se do podobny situace neni pro jen trochu zvidavejsi uzivatele problem :)

[Kyosuke]

Nebylo by produktivnější napsat do susího mailing listu?

[anicka]

Ona stará dobrá bugzilla by asi bohatě stačila

Jo, nejlepší jsou ti, co dostanou Linux zadarmo a nestojí jim ani za hlášení bugů - jasně, přeinstalovat na jiné distro, kde se ta konkrétní buga neprojevuje a čekat na další je asi rychlejší než dočkat se opravy... ale jistě je zřejmé, co víc pomůže ostatním

[Kyosuke]

Ona by taky možná neškodila trošku lepší dokumentace SW managementu. ;/ Od RPM přes zypp/zypper/YaST až třeba po KIWI.

Nicméně koukám, že něco opravdu je asi shnilého: Když dám zypper if -t pattern gnome, napíše mi to Nainstalováno: Ano, ale když dám zypper rm -t pattern gnome, tak dostanu jen Závislost 'gnome' není nainstalována. WTF?

[extender]

jojo. Když jsem si naposled stěžoval nějakému SUSÁkovi, proč jste proboha změnili v 10.3 amaroK-xine na amaroK-yauap, byl jsem odkázán ať to někam napíšu, že nadávat umí každý. A protože na tohle nadává skutečně každý a každý vymění yauap za xine okamžitě po instalaci, očekával jsem, že se něco změní a napsal jsem. A co se změnilo? v 11 jste pro jistotu amarok-xine vyhodili uplně. (už není ani na instalčním médiu). To si snad děláte prdel ne?

[Käyttäjä 11133]

A není to třeba s tím, že amarok-yauap umí přehrávat MP3 prostřednictvím fluendo kodeků, které jsou přímo v distribuci? Jak vyhodili? Je snad v internetovém repu, ne? Jestli je na DVD to nevím, stahovat ho kvůli tomu nebudu.

[extender]

A ty znáš někoho, kdo používá fluendo-codecy? Já neznám a přiznám se, že kvalita reprodukce skrze amarok-yauap je naprosto příšerná. Lepší už fakt gramofon s deskou poškrábanou hřebíkem.

[Käyttäjä 11133]

A nebude to možná tím, že existuje i Americký trh, kde uživatelům asi ani nic jiného nezbývá? openSUSE je globální distribucí.

[extender]

je zajímavé, že to X let nikomu nevadilo a nyní vadí. Mimo to, kvůli 1% USA uživatel se všichni ostatní musí přizpůsobit? Je přece normální, když si 1% USA uživatel doinstaluje yauap než 99% zbytku xine.

[Käyttäjä 11133]

MOžná si nepochopil, že takhle MP3 fungují po instalaci, kdyby byl použit amarok-xine tak by MP3 po instalaci jít nemohli, protože openSUSE je sponsorováno Novellem což je americká společnost a tak podléhá americkým zákonům, včetně tech patentových. Takže je to situace amarok-yauap s funkčními MP3 vs. amarok-xine bez funkčních MP3. K tomu aby si v amarok-xine měl funkční MP3 (WMA,..) potřebuješ nainstalovat amarok-xine z Packmana.

A 1%? To se mi nezdá.

[extender]

Ano. To je problém US corporate dister.

[Mark]

No ja neviem. Ja vidím amarok-xine vo viacerých repozitároch (Main OSS, Backports).

[extender]

ja viem. instaloval jsem ho z OSS. Ale ten šok, kdy při konfiguraci instalace první co tradičně dělám je vyhození yauap, a ejhle, xine nikde.

[extender]

Milá Aničko. Když asi po 150 napíšu někam do Novellu/SUSE, že by možná nebylo od věci, kdyby Yast uměl reverzní závislosti, myslíš, že po 151 se dočkám?

[Kyosuke]

Yast umí reverzní závislosti. Teda ono to závisí na definici slova "umět". Třeba fraktální wallpapery z nich počítat neumí, zato s nimi může snáze zaručit, že systém zůstane při změnách ve funkčním stavu. Ale rozhodně to pro YaST není cizí slovo. Nemůže být problém v tom, že svůj problém nedostatečně specifikuješ?

[Käyttäjä 11133]

Ad to co asi myslíš jako reverzní závislosti:

marekstopka@gmail.com  - 13:22:25
myslíš, že v 11.1 bude možnost odstranit nepotřebné závislosti?
mám dát enhancement report do bugzilly?
Jano Kupec  - 13:23:49
nemusis, uz to mame vo fate, ale ci to bude v 11.1, to este nevieme povedat
ja o chvilu zacnem robit na historii instalacie, to je prvy krok k cisteniu nepotrebnych balickov :O)

[Kyosuke]

Já jsem vypostřehnul, že spousta lidí říká "Proč neumí SUSE reverzní závislosti jako Debian?", a přitom ve skutečnosti chtějí říct "Proč nedělá zypper rm v SUSE to, co aptitude remove v Debianu?", ačkoliv z toho mála, co o balíčkovacích systémech vím, mi přijde, že to jsou de facto ortogonální fíčury.

[extender]

Ano přesně to myslím. Nasinatluju balíček A. Ten sebou vezme 15 dalších. Ale když chci balíček A odistanlovat, tech 150 mi tam zustane. Akdyz je zacnu odebirat rucne, vznikne z toho presne to co popisuju v blogu.

[Kyosuke]

To ale nemá s reverzními závislostmi příliš mnoho společného. Reverzní závislost sama o sobě je přesně to, co jsem linkoval výše.

[extender]

pojmenuj to jak chceš, budu pak ten termín používat

[Kyosuke]

Ale pak se nediv, že to v SUSE ještě není, když si říkáš o něco, co tam už dávno je.

[extender]

Dobře. Vysvětli mi, idiotovi, jak odstraním balíček A včetně 150 balíčků, které přišly s ním?

[Käyttäjä 11133]

No fuj, něco takového bych nechtěl! Když si představím situaci, že nainstaluju program A, který požaduje libA, pak nainstaluju program B, který vyžaduje libB a libA. Potom najednou z ničeho nic chci odinstalovat A a ono mi to odstraní i libA... Hmm nepříjemná situace.

[extender]

Ne. On se podívá, pro A jsem instaloval libA, libC a libD... lib A potřebují ještě jiné programy tak ho ponechám, libC a libD nepotřebují tak nabídnu jejích smazání.

PS: u lib je to jedno, ale když má člověk na nic půlku gnome je to na hovno.

[Käyttäjä 11133]

Ale to si nenapsal :D

[extender]

Někdy mám tady pocit, že mluvím s idiotem. Slovíčkař klidně dál

[Käyttäjä 11133]

To spíš já mám pocit, že mluvím s idiotem, který neumí říct co chce.

[extender]

To je klidně možné. Mám plné právo být idiotem. Nakonec si na to stejně musím přijít sám. V Yastu je menu "soubor" - "importovat + exportovat" a dá se archivovat stav balíčků kdykoli chci. Bohužel, nefunguje to automatcky, stejně jako jsem nepřišel na to jak rozchodit "rpm --rollback"

[Kyosuke]

"pro A jsem instaloval"

To už ale nezní jako reverzní závislosti. To už zní spíš jako historie instalací. Co když nainstaluju program A, který se dá normálně používat jako aplikace, pak nainstaluju program B, který ho používá, a pak odinstaluju program B, protože se mi nelíbí? Jak to pozná, že A ještě chci?

[Käyttäjä 11133]

Přesně tak, jedná se o historie instalací.

[petr_p]

Jednoduše. U každého nainstalovného balíčku je poznačeno, zda byl nainstalován automaticky nebo explicitně uživatelem.

V apt se tomu říká „manually installed“, v portage „je ve world“.

Tedy v tomto případě se A neodinstaluje.

[Kyosuke]

No vida, a máme tu hned něco mimozávislostního. Já to věděl!

[petr_p]

Přičemž lze na databázi ručně instalovných balíků pohlížet jako na (meta/virtuální) balík, jehož závislosti jsou všechny ručně instalované balíky. Jediný rozdíl je, že tyto závislosti se mohou měnit při každém použití správce balíků.

Takže celý problém se redukuje na řešení závislostí :)

[Michal Vyskočil]

No ale zajisté to půjde převést na SAT problém a ten řešit v libzyppu snad nebude takový problém, no ne?

[Zdenek]

Presne k tomu slouzi u rpm transkace. Pak staci jen rict, ze chci system jako pred hodinou nez jsem ho zacal rozbijet

[extender]

můžete mě nakopnout?

[Zdenek]

rpm -Uvh --rollback '1 hour ago'

[extender]

bohužel opensuse 11 nefunguje. Buď nemám zaplé checkpointy, takže to nemá kam se vracet, nebo tahle feature není zprovozněná vůbec.

[slayn]

pacman -Rcs balicek

[anicka]

Milá Aničko. Když asi po 150 napíšu někam do Novellu/SUSE, že by možná nebylo od věci, kdyby Yast uměl reverzní závislosti, myslíš, že po 151 se dočkám?

Hrušky s jabkama. Totiž bugy s featurama.

Pokud se s balíkem jako závislost instaluje něco, čeho je milion a evidentně to s ním nemá nic společného, je to zřejmě bug, jako bug by měl být nahlášen a opraven. Stává se to dost běžně a někdy je to poněkud absurdní - vzpomínám živě třeba na komplikované odstraňování závislosti muttu na kde3. Smutné je, že takovéhle bugy obvykle hlásí skoro jenom lidi ze SUSE, ostatní si snad myslí, že je to nutné zlo nebo co...

Pokud balíkovači chybí nějaká featura, je dobré o ni jednou poprosit dejme tomu na souvisejícím mailing listu a dál už neprudit - pokud o ni bude zájem, jistě ji dříve či později někdo naimplementuje.

Že opravování bugů je samozřejmé a implementace featur ne, co má větší prioritu, a co dá víc práce, už je asi jasné.

Ale ano, po Debianech jsme další, co se snaží řešit NP-úplné problémy, takže se i té své vysněné featury nejspíš už dost brzo dočkáš

[Cubic]

Pokud je tohle normalni chovani a ne, jak bylo zmineno, PEBKAC, tak se chuti pomodlim k USE flagum. Amen

[extender]

Problém je v tom, že libzypp místo aby nabídl vyhození všeho GNOME-cosi, tak urputně nabízí jen možnosti, jak toho zachovat co nejvíce a tak všechn co bych chtěl vyhodit nahrazuje jinými verzemi, což sebou nese další závislosti... Přitom je to tak jednoduché a ručně jsem to vyřešil za kratší dobu, než jakou to řešil stroj.

[prOm3TheuS]

Co k tomu jiného říct, než zatracenej dependency hell Kdybys měl vole Linux From Scratch, tak se sice ukompiluješ k smrti, ale instaluješ jen to, co chceš...

[tomolc]

Hlavný problém je podla mňa v tom - ako si ddal záležať správca balíku pri kompilovaní a príprave do distra.

Je vela programov "závislích" na Gnome. Avšak pri správnej volbe parametrov kompilácie sa dá tejto závyslosti vo vela prípadoch zbaviť alebo ju aspoň minimalizovať... Samozrejme sa môže stať že prídeme o funkcionalitu ale večšinov sú to nepodstatné blbosti.

Používam Slax. Jednou z výhod je že možem presne kontrolovať aké knižnice a "dodatočný" soft sa mi inštaluje do systému. Možem to dať do blacklistu. Prípadne si danú aplikáciu vykompilujem bez daných závislostí a podobne...

tomolc

[extender]

Slax už jde dneska hodit na disk? Dlouho jsem ho neviděl.

[tomolc]

Slax je velmi pokrokové distro. Ja ho využívam ako normálny desktop linux so špeciálnimi vlastnostami.

Na stránke ldt.linuxos.sk a v mojom blogu je o tom viac.

tomolc

[Käyttäjä 11133]

Jasně, od toho existuje věc jménem /usr/bin/build. Taky si to můžeš zkompilovat bez různých feature.

[Grunt]

Takový DepHell mě jednou potkal na OpenSuSE 10.2 hned po instalaci…od té doby radši nic na SuSE nemažu(stejně to mítso na disku nijak nevyužiju).

Balíků gnome-něco mám ovšem v systému jak nasráno, aplikace se mi až tak nezamlouvají, ale co s tím.

A ono je něco na gnome-common + závislostech něco špatného?(Snad zas za to nemůže GTK dialog)

Ohohoooooo. Tak tohle to překonává vše. X-tý pokus o odstranění gnome-keyring ústí v pokus o odstranění digiKamu (+ asi 80 balíků). Ano vidíte správně nedělám si prdel. Co mám sakra na tohle říct?

Že je lepší mít v systému 150 nepoužívaných balíčků.

[extender]

co do kB nic. Ale v principu mě to začíná jebat. Protože pak je výhoda balíčkovacího systému ta-tam. Nemám v systému co chci, ale to co jsem jednou instaloval

[petr_p]

Třeba bezpečnost. Každý nainstalovaný balík se musí hlídat a aktualizovat. Čím je toho méně, tím lépe.

[menphis]

uz vidim, jak se ti ty knihovny pro gnome nakonec podari odstanit a zitra tu bude zapisek, ve kterym budes posilat suse do prdele, protoze ti nejede pulka aplikaci :D

[extender]

uz jsou pryc par hodin...

[Kyosuke]

Takže už nemáš gnome-keyring, a přesto sis zachoval GIMP, který je na něm závislý?

[extender]

Ne. Gnome-keyring jsem kvůli GIMPu zachoval. On totiž s gnome-keyring chtěl odinstalovat digiKam, který na něm závislý být nemůže. a to už jsem dostal strach. Ručně jsem vyházel ty knihovny, které nepotřebuji k žádnému programu.

[ʚĭɞ 🍉]

Proč je GIMP závislý na gnome-keyring? Proč závisí Inkscape na knihovnách z Gnome?

[Käyttäjä 11133]

Na to se zeptej vývojářů GIMPu a Inkscape.

[Kyosuke]

Takže odpověď nevíme, ale zato jsme pochopili, proč nepoužíváme Gnome.

[extender]

A proč asi přestanem používat GIMP a Inkscape

[Grunt]

Protože jsou to programy do tohoto prostředí integrované a také na něm závislé. Ještě můžeš používat všelijaké multi-platformní na ničem nezávislé programy jako je FireFox.

[ʚĭɞ 🍉]

Jak jsou integrované? Povídej... Jsou to obyčejné GTK aplikace. Tak se ukaž s těmi nezávislými grafickými editory pod GNU/Linuxem. A FF není nezávislý --- vyžaduje GTK. ^_^

[petr_p]

U mě (na Gentoo) GIMP gnome-keyring nepotřebuje, protože nemám pambase přeložený s podporou gnome-keyring. A proč GIMP potřebuje pambase? Protože pambase je závislost pamu a ten je třeba pro CUPS, jehož klientské knihovny vyžaduje tiskový subsystém GIMPu.

Tady vidím chybu na straně baliče CUPSu, který nedokázal oddělit server od klienta.

Ostatně dependency hell je většinou chyba distributora, který nedokáže rozdělit funkcionalitu balíku tak, aby se neinstalovaly nepotřebné části.

[Cubic]

let`s spread the word of portage
jestli jeste nekdo kdo zmini gentoo, tak bych se nedivil, kdyby uz byl poslan do mist kde slunce nesviti :)

[Kyosuke]

To vaše Portage na tom možná taky nebude (pro uživatele) až tak dobře , navíc tam vidím, že i libgnomeui má záviset na gnome-keyring (i když je možné, že nevím o USE flagu, co to vypne), a jelikož GIMP, pokud vím, taky používá libgnomeui, tak to asi tak snadný s odstraněním závislosti nebude. Nebo se u GIMPu dá vypnout závislost na libgnomeui? To už by ale asi bylo hodně drsný. To už by asi chtělo balík gimp-nognomeatall

[ʚĭɞ 🍉]

To už by asi chtělo balík gimp-nognomeatall

Bingo!

[petr_p]

Ano, libgnomeui vyžaduje gnome-keyring a vůbec si mi to nelibí. Nevím, zda toto je chyba baliče nebo vývojářů Gnome. (Gnome je tímhle prolezlé, vše závisí na všem, ale rozděleno to je, pro pohodlnější správu a aktualizace.)

Ovšem GIMP libgnomeui nepotřebuje. Alespoň emerge --tree --emptytree -vp gimp tuhle knihovnu nezmiňuje, ldd taky ne a qdepends -Q libgnomeui taky ukazuje věci mimo působnost GIMPu.

[Kyosuke]

Ostatně dependency hell je většinou chyba distributora, který nedokáže rozdělit funkcionalitu balíku tak, aby se neinstalovaly nepotřebné části.

Mno tyhle věci u SUSE zrovna nebývají moc zvykem, koneckonců spousta balíků se tam seká na části a ke spoustě z nich se ještě samostatně dělá -doc, -devel, -debuginfo a -debugsource. Ale stát se to občas asi může. Do detailů nevidím, tyhle věci musí nahlásit do bugzilly někdo, komu to hodně vadí a nemůže bez odinstalace gnome-keyring žít.

[Dr.Watson]

... ehm, autore, možná byste mel zacit tim, ze ponekud upravite slovnik ... Nic mi po tom neni, ale myslim, ze "nemecke zatacky" a podobne vzrusi leda pubescenta... Mne to v globalu pomerne znechutilo cely dojem z clanku. Myslim, ze dulezita je nejen "odbornost" ale i forma sdeleni :)

[extender]

omlouvám se, opraveno