Vlákno názorů k článku Životní cyklus kontra úspěšnost od M. Prýmek - Velmi zajímavé téma! Myslím, že problematika vývojového cyklu...
-
Velmi zajímavé téma! Myslím, že problematika vývojového cyklu je jeden ze základních kamenů úspěšnosti Linuxu. Stálo by to za trochu detailnějšní analýzu, nejspíš od někoho, kdo tomu fakt rozumí (tvůrce distra, zaměstnanec zodpovědný za nějaký balík?)
Mně osobně by se líbilo něco na způsob mixu mezi vydánímí a rolling updates v tomhle stylu:
1. předpokládám, že účelem distra je sladit jednotlivé komponenty. Chyby v jednotlivých balíčcích by se měly řešit spíš v upstreamu, jinak je to zbytečné tříštění sil.
2. rozdělil bych distro na jakési "sféry", kde uvnitř sféry jsou balíčky, které spolu interagují. Interakce mezi sférami jsou minimální či málo-se-měnící, rozhodně ale jasně definované a strojově testovatelné.
3. jednotlivé sféry bych vydával stylem RU (jako celek - zaráz všechny balíky!) v době, kdy jsou interakce uvnitř sféry dobře otestované.
Tím by se zamezilo tomu, že chyba v nějaké části systému (např. OpenOffice :) zdržuje uvolnění nových verzí věci, které s tím vůbec nesouvisí (třeba Samba) - myslím, že tohle je třeba dost neblahá vlastnost Debianu, vzhledem k obrovskému množství balíků. Ubuntu se to snaží jakžtakž řešit oddělením base a zbytku.
Zároveň by nové aplikace byly k dispozici hned, jakmile v distru bezchybně fungují.
Něco podobného de facto funguje u komerčních OS (Windows, MacOS), což ve článku asi mělo zaznít, když byly tyto OS zmíněny.
U komerčních OS totiž firma spravuje samotný OS (tj. základní "sféra", "base"), který vydá, jakmile funguje (doufejme :), a jednotlivé aplikace updatují sami výrobci, včetně všeho, co daná aplikace potřebuje (v principu) - takže jedotlivé části se vzájemně nebrzdí, což je rozdíl oproti Linuxu, kde jedna organizace plánuje updaty vlastně všeho...
Reakce, korekce a Vaše zkušenosti uvítám, téma mě docela zajímá. -
> Nachapu "...stylem RU (...zaraz vsechny...)" - zaraz vsechny preci neni RU.
Zaráz všechny balíky z dané "sféry". Proto jsem to nazval mixem mezi RU a vydáními: sféra sama je vydávána zaráz, ale "mezi sférami" funguje RU - protože tam nehrozí chyba v interakci, klasické slabina RU.
Asi jsem se nevyjádřil příliš jasně, sorry.
> A jak se vyporadat se sdilenymi knihovnami? A jak se zavislostmi? Tohle taky maji resit dodavatele softwaru?
U komerčních aplikací se používají buď pouze knihovny OS, nebo se potřebné závislosti přibalí. U OSS by to řešila "sféra".
P.S. tak mě napadá, že místo "sféra" by bylo asi lepší slovo "modul" :) -
Jirka (neregistrovaný)Jenze ty moduly, ktere se na prvni pohled zdaji samostatne, se prave v dost knihovnach prolinaji. Ve vysledku bys mel jeden nebo nekolik malo molochu a pak par nezavislych pidimodulu. Takovy system by moc vyhodny nebyl.
RU je dobry napad, zvlast v dobe, kdy spouste lidi na nejakem tom stazenem gigabytu moc nezalezi. Jen to zatim nikdo nedotahl do dokonalosti, ve ktere se osetri vsechny zavislosti vcetne zpetnych, blokujici balicky, konfigurovatelnost, moznost mit v systemu vicero moznosti reseni nejakeho problemu (nejen sloty, ale i virtualni balicky apod.) -
> Jenze ty moduly, ktere se na prvni pohled zdaji samostatne, se prave v dost knihovnach prolinaji.
To je možná pravda, ale to je potom docela systémový problém, nemyslíš? Jak by mohl takhle propletený systém dobře udržovatelný?
V praxi to ale asi tak strašné nebude, balíčků, které závisí jen na pár základních věcech ("base") bude asi spousta.
Nicméně např. Gnome + všechny jeho aplikace by asi byly jeden modul, to je fakt. Proč ne? -
Mám taky pocit, že spousta problémů by se obešla tím, kdyby balíčkovací systém umožňoval jednoduchým způsobem nainstalovat více verzí stejné knihovny - bez toho, aby na to musel myslet "balíčkář" tím, že vytvoří dvě větve - třeba gtk1 a gtk2.
Přestože většina knihoven jako takových to umožňuje, neznám žádný balíčkovač v Linuxu, který by to uměl.
Např. v MacOS:
[/System/Library/Frameworks/Python.framework/Versions]$ ls -l
total 8
drwxr-xr-x 7 root wheel 238 14 lis 2007 2.3
drwxr-xr-x 12 root wheel 408 19 úno 2008 2.5
lrwxr-xr-x 1 root wheel 3 14 lis 2007 Current -> 2.5 -
Jirka (neregistrovaný)Gentoosky portage umi sloty.
Ale hlavni problem podle me neni v balickovaci, ten by to zvladnul, ale v tom, ze kdyz pak budes mit verze knihovny treba 1.1 a 1.4, tak minimalne na jednu z nich vicemene musis udelat link z nazvu bez verze. A kterou ted vybrat, kdyz kazda z tech aplikaci na tomhle jmenu predpoklada tu svou? -
Jan Pechanec (neregistrovaný)funguje to trochu jinak. Více verzí knihoven je v systému proto, že existující aplikace byly proti nim přeloženy. Pokud existuje více verzí stejné knihovny, jejich SONAME je rozdílné (např. libcrypto.so.0.9.7 a libcrypto.0.9.8). String z SONAME se pak dá do NEEDED v dynamické sekci programu.
link ve tvaru libxxx.so na jednu z existujících verzí (třeba libxxx.so.3) je jen pro překlad. Ale do NEEDED se opět dá to, co knihovna, na kterou daný link ukazuje, má v SONAME. Tj. překládáš s libcrypto.so protože v makefilu je "-lcrypto", ale aplikace pak ví, která z verzí to přesně byla a tu hledá (libcrypto.0.9.8, třeba), a pokud na systému není, skončí to při spuštění na úrovni dynamického linkeru (dynamický linker je ld.so.1 apod., podle konkrétního systému).
podívej se na elfdump(1); konkrétně "-d" vypíše dynamickou sekci ELF objektu. -
Já jsem si říkal, že to bylo nějaký složitější, ale jasně a stručně napsaný jsem to nikde nenašel, takže dík!
Nicméně nechápu, jak si mám vyložit tohle:
$ ldd /usr/bin/mc
linux-gate.so.1 => (0xffffe000)
libgmodule-2.0.so.0 => /opt/gnome/lib/libgmodule-2.0.so.0 (0xb7ee3000)
libdl.so.2 => /lib/libdl.so.2 (0xb7edf000)
libglib-2.0.so.0 => /opt/gnome/lib/libglib-2.0.so.0 (0xb7e59000)
libext2fs.so.2 => /lib/libext2fs.so.2 (0xb7e40000)
libcom_err.so.2 => /lib/libcom_err.so.2 (0xb7e3c000)
libgpm.so.1 => /usr/lib/libgpm.so.1 (0xb7e36000)
Znamená to, že se hledá např. libgpm.so.1 a NE např. libgpm.so.1.19.0? Čili že v hlavičce je jenom major verze? To by bylo docela blbý, ne?
Díky za info :) -
Jan Pechanec (neregistrovaný)mas zmeny kompatibilni, a zmeny nekompatibilni. Zmena retezce v SONAME by mela nastat jen tehdy, kdy jde o nekompatibilni zmenu. readelf(1) ukazuje, ze libgpm.so.1 ma SONAME libgpm.so.1, takze predpokladam, ze ty posledni 2 cisla ABI (ne API) nemeni. BTW elfdump zmineny v predchozi odpovedi asi neni GNU, spravne melo byt "readelf". Staci ho pustit s "-a" na /lib/libgpm.so.1 a najit SONAME.
co se tyce verzi tak naopak, ty nechces, aby v SONAME bylo libgpm.so.1.19.0, pokud minor cislo nemeni kompatibilitu - to bys pak neustale a zbytecne prekladal stary aplikace po kazdym upgradu systemu. Je to podobny jako OpenSSL, mas verze 0.9.8a-8i, ale v SONAME je pouze 0.9.8, protoze pismeno neni o binarni kompatibilite. Stava se, ze i do minor verze se prida napriklad nova funkce a aplikace, ktera tu funkci pouziva, uz se starsi knihovnou nepobezi, i kdyby SONAME bylo stejny. Tohle resi neco cemu se rika "library versioning" - kazdy symbol ma svoji verzi podle toho, kdy byl pridan. Pri hledani symbolu ktery v knihovne neni ti pak dynamicky linker napise, ze nemas prislusnou verzi knihovny, coz je lepsi nez hlaska jako "xxx symbol not found; process killed". Verzovani knihoven jak je popsany nahore GNU linker umi, ale nevim jestli se to bezne pouziva. Napriklad na Solarisu je to standardni vec. Diky tomu treba libc.so stale ukazuje na libc.so.1, i kdyz posledni verze je 1.23.
tady to je celkem podrobne, strany 32-36:
http://www.devnull.cz/mff/pvu/common/slides/programovani_v_unixu.pdf -
Jirka (neregistrovaný)To ano, ale jak muzes videt treba ze strace, tak pri hledani knihoven se proleza kde co a dost casto se na tu spravnou narazi az na nekolikaty pokus po te, co se vyzkousely vsechny mozne cesty. V SONAME nemusi byt presna cesta k pouzite knihovne, a casto take neni. Je pravda, ze tohle muze zalezet na systemu (a pouzitem linkeru), ale pro nejednoznacnosti je zde stale mista vic nez dost. Verim, ze pri peclivem sestavovani baliku se to da ukocirovat.
-
Jan Pechanec (neregistrovaný)v SONAME neni cesta (respektive nikdy jsem to nevidel, a nevim jestli by to standardni nastroje vubec umoznily), ale jmeno souboru. Cesta se bere z toho, co system defaultne pouziva (typicky /lib/, /usr/lib, ...), a da se to rozsirit pomoci promenny LD_LIBRARY_PATH. To co je v SONAME ale musi byt jmeno existujiciho souboru v jednom z tech adresaru, ktery dynamicky linker prochazi, jinak se knihovna nenajde.
opet, dost informaci je v tom PDF okazovany nahore. Nemusis pouzivat strace, staci LD_DEBUG ktery se pouziva pro vypis debug hlasek dynamickyho linkeru, napr. "LD_DEBUG=libs date" ukaze, co se vsechno prohledava:
$ LD_DEBUG=libs date
19841: find library=librt.so.1 [0]; searching
19841: search path=/afs/ms/@sys/sw/lib/tls/i686/sse2:/afs/ms/@sys/sw/lib/tls/i686:/afs/ms/@sys/sw/lib/tls/sse2:/afs/ms/@sys/sw/lib/tls:/afs/ms/@sys/sw/lib/i686/sse2:/afs/ms/@sys/sw/lib/i686:/afs/ms/@sys/sw/lib/sse2:/afs/ms/@sys/sw/lib:/afs/ms/@sys/lib/tls/i686/sse2:/afs/ms/@sys/lib/tls/i686:/afs/ms/@sys/lib/tls/sse2:/afs/ms/@sys/lib/tls:/afs/ms/@sys/lib/i686/sse2:/afs/ms/@sys/lib/i686:/afs/ms/@sys/lib/sse2:/afs/ms/@sys/lib (LD_LIBRARY_PATH)
19841: trying file=/afs/ms/@sys/sw/lib/tls/i686/sse2/librt.so.1
19841: trying file=/afs/ms/@sys/sw/lib/tls/i686/librt.so.1
19841: trying file=/afs/ms/@sys/sw/lib/tls/sse2/librt.so.1
19841: trying file=/afs/ms/@sys/sw/lib/tls/librt.so.1
...
... -
Jirka (neregistrovaný)Muze tam byt i cesta, ale obvykle je skutecne to vyhledavani s pomoci LD_LIBRARY_PATH (a nejen s jeho pomoci). Jmeno souboru tam byt muze take. Problem je, ze je to casto jmeno softlinku na nejakou konkretni verzi knihovny. A o tenhle link se stara balickovaci system distribuce. A jsme zase u slabosti distribuce. I kdyby dynamicke linkovani se korektne staralo o verzi, stejne to spousta distribuci umlati svymi linky.
-
Alt Gr (neregistrovaný)Hm, sfery - to zni skoro jako filozoficky traktat.
Vyvojovy model openSUSE jste videl? Jednou za 6 az 8 mesicu se vydava nova distribuce. Aplikace, jejichz posledni verze by mohly byt pro uzivatele zajimave (OpenOffice.org, Firefox, ...) jsou dostupne pro VSECHNY podporovane verze (11.0, 10.3, 10.2, SLED_10) na http://download.opensuse.org/repositories/. Jak stabilni tak i vyvojove vetve. Uzivatelum starsich a odzkousenych verzi (napriklad openSUSE 10.3) to umoznuje automaticky stahnout (YaSTem) nejnovejsi verzi OO.o, Firefoxu, ... Me osobne to prijde jako velmi dobra vlastnost a tipuji, ze rada jinych distribuci to driv nebo pozdeji zavede take.
Jak ty baliky pro jednotlive verze delaji nevim, tipuji, ze je to cele postavene na openSUSE Build Service.
