Názory k článku
Budoucnost distribuce software pro Linux
-
dvh (neregistrovaný)Ok, pozri sa na to takto:
- vies si predstavit ze debian a ubuntu zahodi dpkg a apt a zacne pouzivat nieco ine?
- vies si predstavit ze redhat, fedora, suse a mandriva zahodi rpm a bude pouzivat nieco ine?
- vies si predstavit ze debian a ubuntu zahodi dpkg a apt a zacne pouzivat rpm?
- vies si predstavit ze redhat, fedora, suse a mandriva zahodi rpm a bude pouzivat dpkg a apt?
-
anonymníNo, pozor. RPM je balickovaci system a zaroven nastroj na instalaci.
DEB je balickovaci system (format balicku), kdezto dpkg je nastroj na praci s timto formatem, a apt nebo aptitude (nevim ted, co je dselect, nejsem cistej profik debianista) jsou nadstavby nad dpkg (pokud se nepletu, debianiste me urcite doplni/opravi).
Videl jsem funkcni apt-get s RPM balickama (podobne jako se chova yum), na Fedore 1,2,3, ale bohuzel pro verzi 4 a vyse jsem uz apt-get nevidel. Byla to parada s tim pracovat.
Navic, ja bych si docela dokazal predstavit prechod od RPM na DEB (vcetne dpkg, apt utilit). Napsat debian/rules je podle me jednodussi (klasicky Makefile), nez napsat *.spec, zvlaste kdyz ti dh_make udelat zakladni sablonu, kterou uz pak jenom lehce pripadne doladis, ale u programu s klasickym ./configure; make; make install to snad upravovat ani nemusis.
Kdezto u RPM musis spec napsat, manual sice je, ale moc flexibilni ten jazyk neni.
Ovsem zahodit DEB+dpkg+apt by byla silenost!:) -
Ondrej 'SanTiago' Zajicek (neregistrovaný)Myslim, ze vymena apt za rpm (nebo naopak) je banalita oproti jinym problemum, ktere ma idea jednech balicku pro vsechny distribuce.
Kazda distribuce ma sadu konvenci, ktere zajistuji, ze balickovane programy dohromady dobre spolupracuji. Nektere tyto konvence jsou explicitni, jina implicitni. Obcas je treba takove konvence vytvaret za behu, aby resily nove vznikle situace.
Namatkou: jmena balicku (do zavislosti), navaznost na startovaci skripty, u interpretovanych programu navaznost na prislusne interprety, u programu spoustenych z inetd navaznost na konfigurak inetd.
Spousta techto veci by sice postupem casu slo standardizovat, nicmene nektere z nich ne (protoze existuji dobre duvody pro ruzne varianty reseni). Standardizacni proces by bud zaostaval za distribucemi, nebo by je zdrzoval.
Do toho jeste prijdou problemy z binarni kompatibilitou - velka cast free software vyvojaru se o binarni kompatibilitu prilis nestara, a asi jen minimum vyvojaru ji explicitne testuje. Proto je nejspolehlivejsi pouzivat ty verze knihoven, se kterymi byly programy zkompilovany (a v pripade bezpecnostni chyby v knihovne bugfix backportovat do puvodni verze a pouzivat opatchovanou puvodni verzi, nez instalovat novou). Pri soucasnem modelu to nezpusobuje problemy - programy v ramci jedne distribuce jsou kompilovane konzistentne.
Vysledkem by s velkou pravdepodobnosti byly balicky, ktere by sice na prvni pohled vypadaly ze je mozne je nainstalovat do libovolne distribuce, ale v praxi by pak spolehlive fungovaly jen v te distribuci, ve ktere je jejich maintainer vytvarel. Coz by cely proces shaneni balicku jeste vic zatemnilo, nebot pozadavek na spravny puvod baliku by se z explicitniho pozadavku stal pozadavkem implicitnim.
Myslim, ze maintaineri ruznych distribuci si tohle vicemene uvedomuji, proto zde zadne valne snahy o sjednoceni nejsou. -
anonymníObavam se, ze tak jednoduche to nebude.
Jednak clanek hovori o reseni CRN (Click-and-Run). Sice jsem to jeste nevidel v akci, ale nezda se mi to jako super vec. Bud to bude opravdu univerzalni, pak si to s sebou bude nosit vsechny potrebny knihovny a bude z toho preplacanej system, nebo bude muset byt pro kazdou distribuci a kazdou verzi knihovny jinej balik, coz bude jeste vetsi bordel nez ted. Pro uzivatele to mozna vypada super, ale co admini. A pokud to nebude tak pritulny jako apt-get/aptitude s moznosti prace z konzole, tak to admini moc pouzivat nebudou. Osobne si myslim, ze nejlepsi binarni balickovac je DEB a s apt-getem/aptitude se nic neresi. RedHati RPM sice neni spatny, ale *.spec ma vlastni slaby jazyk, oproti DEB rules (coz je Makefile) a taky yum je o hodne pomalejsi nez apt-get. Pro kompilovani je zase super Portage (ikdyz nemuzu mluvit za ostatni napr. SourceMage). Emerge dotaha zavislosti, vsechno prelozi, nainstaluje a zapamtuje si instalovane soubory, takze zadny problem s odinstalovanim. Navic "CNR Service FREE" a "CNR Gold Service $49.95/yr." me trosku desi, co se stane, az se CNR rozsiri. Zustane porad Free nebo zacne byt cenena? Navic nikde nevidim Download, to me taky desi. Myslim si, ze DEB ma taky podporu v KDE/Gnome, takze staci kliknout a uz se instaluje, pripadne GUI k apt-getu.
Za druhe se ve clanku hovori o standardizaci verze knihoven pouzit v "major distros". To je sice hezke, takze budeme mit vsechny distribuce se stejnyma knihovnama a pro ne budou standardni balicky. A kdyz budu chtit novejsi balicek (jakoze uzivatele budou chtit vsechno NEW), tak jsme zase tam, kde jsme byli. Novy balicek potrebuje novou knihovnu.
Osobne bych preferoval, kdyby vsechny distra presly na DEB, prinejmensim na apt-get pro RPM, krome slacku a Gentoo&spol samorejme:) -
anonymníaha, ted jsem na to kouknul. *.pkg.tar.gz, cili ala Slackware. Jojo, psal jsem, ze slackware se svyho tar.gz vzdat urcite nebude chtit:) Takze Arch taky:) A tady je zase videt, ze balicek je tar.gz a instalacni nastroj muze byt bud manualni tar xz , nebo installpkg (nebo co maji slackwariste nativniho), nebo pacman:) urcite by sel pacman pouzit i ve slacku, kdyby se udelaly spravny repository:)
BTW: kdyz to ale tak vezmu, urcite se pacman chova stejne jako apt-get, yum a emerge - zjisti zavislosti, dotaha je a nainstaluje kompletne vsechno. -
Petr Ježek (neregistrovaný)Omyl, pacman a archovské balíčky (a ostatně i celý Arch) byly vytvořeny právě proto, že stav na Slacku nevyhovoval. Jde především o konvence pro závislosti a informace pro pacmana - tohle je v Archu systémová věc a velká výhoda. Závislosti jsou řešeny jako nezbytné, takže žádné "dependency hell". Ostatně soudím, že by si linuxový svět měl z Archu v tomto (nejen) vzít příklad, kombinace pkg.tar.gz a pacmana je neuvěřitelně silná a perspektivní...
-
anonymníHmmm, to me zajima. Zkus mi trosku popsat, co myslis tim
'Závislosti jsou řešeny jako nezbytné, takže žádné "dependency hell"'
Pod pojmem "nezbytny" si predstavuji nutny, takze pokud jsou zavislosti nutne, tak naopak vznika dependency hell v pripade, ze chces novou verzi balicku, ten chce novou verzi dalsich X knihoven, ktery chteji zase novy verze dalsich knihoven. Navic jeste kdyz pak mas na systemu programy, ktery naopak vyzadujou ty stary knihovny.
Automaticky reseni zavislosti je v aptu, yumu i emerge, takze to by problem byt nemusel, peklo na RH7 bylo, kdyz si clovek stahnul RPM balicek, pomoci rpm -i ho chtel instalovat, ale ten chtel dalsi balicky-to pak bylo peklo rpm & download.
Zalezi na tom, co pacman umi specialniho. Emerge taky resi zavislosti, binarni balicky ma taky v tar.bz2.
Dulezite je, aby balickovaci system/program umel:
- resit zavislosti
- automaticky stahovat a instalovat zavislosti
- odinstalovat balicek a dobre je, kdyz odinstaluje i nepotrebne balicky, ktere se nainstalovali jako zavisle a uz je jiny balicek nepouziva
Emerge tohle umi, aptitude taky. Nevim jak yum, apt-get neumi odinstalovat nepotrebne balicky, pokud vim. -
Ono je totiz rozdiel medzi "dependency hell" a "neriesitelne dependency hell". Len taky maly priklad do plena. Na zamyslenie. V systeme mam nainstalovane libncurses 4.3.0 a ziadne mc ani dialog:
# ls /usr/lib/libncurses* /usr/lib/libncurses.so.4 --> libncurses.so.4.3 /usr/lib/libncurses.so.4.3 --> libncurses.so.4.3.0 /usr/lib/libncurses.so.4.3.0
Chcem pouzivat napr mc-5.5.0 ktory vyzaduje libncurses.so.4.3.2 a popritom program dialog-1.2.3 ktory vyzaduje libncurses.so.4.3.1.
Po instalacii (bez riesenia zavyslosti):
# ldd `which mc` | grep ncurses libncurses.so.4 in /usr/lib/libncurses.so.4 --> /usr/lib/libncurses.so.4.3.0 # ldd `which dialog` | grep ncurses libncurses.so.4 in /usr/lib/libncurses.so.4 --> /usr/lib/libncurses.so.4.3.0 # mc Segmentation fault # dialog Segmentation fault
Ok takze potrebujem novu kniznicu. Je tu ale jeden problem! Binarky mc a dialog nehovoria ktoru presne verziu chcu ale tu s ktorou boli skompilovane. V sucasnych distrach su vacsinou simlinky na libncurses.so.4 co je simlinka na libncurses.so.4.3 co je linka na skutocnu kniznicu (v mojom pripade libncurses.so.4.3.0). Takto skompilovana binarka "si mysli" ze potrebuje 4 ale v skutocnosti chce 4.3.1 resp. 4.3.2.
Ak doinstalujem libncurses-4.3.1 aj libncurses-4.3.1 stav bude takyto:
# ls /usr/lib/libncurses* /usr/lib/libncurses.so.4 --> libncurses.so.4.3 /usr/lib/libncurses.so.4.3 --> libncurses.so.4.3.0 [*] /usr/lib/libncurses.so.4.3.0 /usr/lib/libncurses.so.4.3.1 /usr/lib/libncurses.so.4.3.2
[*] Tato simlinka moze ukazovat na 4.3.0, 4.3.1 alebo 4.3.2, zalezi to na sposobe akym instalujem, kazdopadne len na jeden z nich. Cize ak mi pojde mc, nepojde mi dialog a naopak.
Toto vsetko za predpokladu ze 4.3.1 a 4.3.2 niesu vzajomne kompatibilne. Cize tento problem nastane vtedy, ak sa v distribuciach pouzivaju symlinky ktore zahrnuju kniznice ktore niesu vzajomne kompatibilne. Inak povedane ak symlinka 4.3 bude pokryvat vsetky verzie 4.3.x a tieto verzie 4.3.x budu vzajomne kompatibilne tak nieje problem.
Moja skusenost je ale taka ze pomerne casto sa najdu rovnake kniznice verzie A.B.C a A.B.D pouzivajuce spolocnu symlinku A.B ale .C a .D niesu vzajomne kompatibilne. Takto vznikaju "neriesitelne dependency hell". Ide o to ze neexistuje taky "guru" ktory by povedal ktore verzie kniznic mozno zastresit spolocnou symlinkou. Mozete to otestovat ale zabudnete pretestovat nejaku polozku v menu v MC a s nespravnou kniznicou to potom u uzivatela hodi segfault.
No a to sa da vyriesit jedine tak ze sa nebudu pouzivat symlinky kniznic ale programy sa budu kompilovat oproti skutocnej kniznici, nie symlinke. Problem je ten ze ked chcete upgradovat jeden program tak musite upgradovat vsetky, alebo si tento program musi so sebou priniest svoje verzie kniznic.
Ocakavam vase podnety, nazory, pripomienky, mozno som totiz prehliadol nejake jednoduche, elegantne a priamociare riesenie tohoto problemu.
-
anonymníNo, to co jsi popsal ale neni pouze RPM dependency hell, to je obecna vlastnost vsech distribuci, pokud si zacnes kompilovat sam.
Osobne jsem za dependency hell povazoval to, kdyz jsem musel doinstalovavat (rozumej stahovat) dalsich X balicku, pripadne, kdyz jsem opravdu chtel novy balicek v RPM, ktery zacal vyzadovat dalsi a dalsi jine balicky, ktere pak samozrejme vyzadovaly novejsi verze, ale stare balicky v systemu pozadovali stare.
Problem s ldd PRG -> /usr/lib/libXXX.so.3 je opravdu chybou bud tvurcu programu, kterej se nedokaze smirit s verzi libXXX.so.3.1.5 a nutne potrebuje verzi libXXX.so.3.1.3, ale pokud symlinky delaji autori knihoven, tak samozrejme je to problem i autoru knihoven, ze ty symlinky delaji stejne pro knihovny, ktere maji ruzne API a ruzne se chovaji. -
Keson (neregistrovaný)"neriesitelne dependency hell" - každý technický problém se dá vyřešit, je-li dostatek času a peněz *)
Problém je v tom, že knihovny libxxx-A.B.C a libxxx-A.B.D by měly být kompatibilní; (nekompatibilní změny se označují změnou čisla "B", případně "A"). No, ne vždy se zadaří :-(, může to být chyba tvůrců knihovny, nebo chyba aplikace, která využívá/zneužívá nějakou chybu knihovny, a po její opravě přestává ta aplikace fungovat.
Co s tím?
Pokud si program kompilujete, můžete ho slinkovat proti libxxx-A.B.C. Nevýhoda tohoto přístupu je v tom, že až vznikne bezpečnostní update knihovny na libxxx-A.B.D, tak budete muset všechny takové programy překompilovat (anebo "lhát" o verzi knihovny symlink ABC->ABD).Pokud máte 2 aplikace vyžadující (podle jména) stejnou knihovnu, ale ve skutečnosti běhá každá jen se "svou" konkrétní verzí, můžete poprosit dyn. linker, aby nahrál "tu správnou" knihovnu pro tu správnou aplikaci. Ve vašem příkladu:
(nejnovější standardně instalovaná)
/usr/lib/libncurses.so.4.3 --> libncurses.so.4.3.2(starši pro dialog)
/usr/lib/oldncurses/libncurses.so.4.3 --> ../libncurses.so.4.3.1a dialog spouštět (např. skriptem)
*) dostatek času a peněz není nikdy
LD_LIBRARY_PATH=/usr/lib/oldncurses dialog -
Jirka Wolny (neregistrovaný)No, já bych si představoval následující řešení:
1) Základ by tvořil nějaký jednotný depozitář balíčků, který by obsahoval jen zdrojové kódy programů (+ závislosti + skript na kompilaci + konfigurační soubory + ...).
2) Nad tím by si každá distribuce mohla udělat svůj vlastní depozitář binárních balíčků (něco jako je dnes deb nebo rpm).
3) Pak by existoval depozitář software, ke kterému nebyly zveřejněné zdrojové kódy. Každý balíček by obsahoval binární software včetně všech potřebných knihoven (něco jako je dnes klik). Některý software by před spuštěním mohl vyžadovat placenou registraci.
Uživatel by si NAPROSTOU většinu software nainstaloval z depozitáře číslo 2. Pokud by daná distribuce neobsahovala potřebný balíček, pak by si jej mohl (relativně) pohodlně nainstalovat z depozitáře číslo 1. Na svém počítači by měl dva, maximálně tak tři balíčky z depozitáře číslo 3. -
anonymníVechny tri body splnuje Gentoo:
1) distfiles+ebuild (nekdy dokonce jsou zdrojove balicky tahane z homepages, nekdy z mirroru SF.net)
2) quickpkg nebo emerge -b vytvari binarni balicky
3) ebuildem samozrejme muzes instalovat take prg sirene v binarni podobe, pouze se preskoci kompilacni cast. Napr. takhle existuje v Gentoo v portage binarni a zdrojove ebuildy pro OpenOffice (openoffice a openffice-bin), Firefox (mozilla-firefox a mozilla-firefox-bin) a dalsi.
Krome toho jeste pomoci ebuildu muzes instalovat SVN/CVS verze, ktere se proste pri kompilaci natahnout primo z originalnich CVS/SVN serveru.
Takze prechazime kompletne na Portage?:) -
Archlinux a Pacman:
1) PKGBUILD - jednoduchý, snadno sestavitelný skript který z internetu stáhne zdrojové kódy, zkompiluje program a vytvoří binární balíček. Dají se samozřejmě psát PKGBUILDy pro komerční/uzavřený software.
2) v oficiálních repositářích jsou už předkompilované binární balíčky jako primární způsob instalace, což ale uživateli nebrání stáhnout si místo balíčku samotný PKGBUILD a zkompilovat si balíček sám.
Pak je ještě AUR - databáze PKGBUILDů které se nedostaly do oficiálních repositářů a do které může přispívat kdokoliv z uživatelů.
3) viz 1., například pro instalaci cedegy je v AURu PKGBUILD kterému stačí aby byla daná verze cedegy ve stejném adresáři a nakonec je z toho výborná buchta... err... balíček.
nebo VMware server - nainstaluje se celý a hned spustí konfiguraci a zeptá se na registrační klíč. -
To vypada rozumne ;)
Pokud by to dokazalo resit i automaticke zavislosti a potahat si samo potrebne veci (samozrejme opet volba, jestli zdrojaky, nebo binarku by byla na uzivateli), tak proc ne. Myslim, ze lze z vetsiny balickovacich a instalacnich systemu vzit to nejlepsi a rozumne s tim nalozit. Nepopiram, ze maximalni funkcnost veci z portage by se mi libila ;)) -
martyone (neregistrovaný)Zase ty blbosti!?
...pro nováčky to znamená nepřekonatelný problém.
Nováček - obyčejný uživatel - je především na větvi z toho, kolik různého SW má už jen po instalaci systému z CD, natožpak z toho, kolik si může několika kliky nainstalovat z repozitářů distribuce (to nemluvím o automatických aktualizacích..). Obyčejný uživatel se prakticky nedostane do situace, že by musel cokoliv instalovat jinak, než pomocí prostředků té, či oné distribuce. Stejně tak početná skupina uživatelů - těch, jež se s počítačem potýkají v práci - je zajištěna i pro případy nutnosti instalovat SW, který by nebyl v repozitáři distribuce: veškerá instalace je v péči administrátora. A pro ty ostatní jsme tady přece my, ne? ;-) Tak co pořád řešit!? -
brambor (neregistrovaný)zdar lidi takže dnes sem si nainstaloval os.linux ubnut,celou dobu před tim sem použival win.xp,a ted nevim co dál chtěl sem nainstalovat icq,codeci,winamp nbo jine a nevim si stim rady,asi se vas dost pobavilo ale fakt nevim co jak mam dělat prostě sem nováček a nejde mi nic nainstalovat tak vam děkuji za připadne odpovědi
