Vlákno názorů k článku
Budoucnost distribuce software pro Linux
od vain - ..by bylo fakt super, ne jen ze by...
-
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.
ČLÁNKY DO MAILU