Když jsou tak odhodláni používat dynamické knihovny a zakazují statické, tak by mě zajímalo, kdo kontroluje, že ty knihovny mezi jednotlivými vydáními Fedory (a mezi Fedorou a jinými distribucemi) nezměnily ABI. Nikdo? – tak ať se pak komunita nediví, že pro ostatní vývojáře je těžké dělat programy pro Linux.
No rekl bych ze stabilitu balicku si ma hlidat ten co balickuje, t.j. pokud balicek pro fedoru dela nekdo zvenci, tak je pak na nem aby projekt prekompiloval+zbalil pro novejsi verzi Fedory kde se ABI zmenilo. Kdyz pripravuje balicky upstream, tak by si to mel hlidat upstream.
Ne ze bych schvaloval jak byl dotycny sprostej, ale jako vyvojar ma pravo se sam rozhodnout ktere distribuce podporuje, a ty zbyle bud at si vytvori balicky samy (a pripadne to opatchuji aby to vyhovovalo jejich politice balicku) nebo maji smulu. Tady mam podezreni ze *buntu/debian ma podobnou politiku a pravdepodobne jeho aplikace to porusuje i tam, takze jeho argumentace Debian > Fedora mi prijde hodne mimo.
Já mám na myslí právě tu situaci, kdy software pro Linux dělá (nebo chce dělat) někdo jiný – např. někdo chce udělat hru pro Linux a nemá zájem na tom, aby ta hra byla v nějaké distribuci, prostě chce, aby se to dalo na jakýkoli Linux instalovat a pustit.
Základní knihovny (libc, gtk) mezi distribucemi kompatibilní jsou, ale všechny knihovny zdaleka ne. Takhle mi třeba v Debianu přestalo fungovat gpm – po upgradu Debiana na Lenny to instalovalo novou dynamickou knihovnu libgpm, která byla nekompatibilní s tou starou, programy z distribuce to upgradovalo taky (takže ty chodily), ale programy, co jsem si zkompiloval sám po upgradu fungovat přestaly.
Co jsem měl na mysli je to, že když linuxová komunita kňourá, že firmy málo nedělají software pro Linux (hry, profesionální programy typu photoshop, apod.), tak by se jim to právě měla snažit ulehčit, a nevyrábět takováto pravidla (to s vynucením, že všechny knihovny musí být dynamické), která vedou k tomu, že se programy instalované mimo distribuci se v budoucích verzích distribuce rozbíjejí.
„tak si ten balíček samozřejmě může udělat jak chce.“
A jak? Udělat balíček, který by šel instalovat na libovolnou distribuci je nedosažitelný sen… :-( Asi tak .tar.gz zbývá.
„A knihovny většinou neřeší vůbec a kompilují staticky.“
Ne všecko jde kompilovat staticky, třeba ovladače grafických karet si instalují vlastní opengl, tak by ho asi nebylo dobré staticky kompilovat.
Navíc rozhraní mezi knihovnami a systémem se taky mění. Zde je příklad, jak přibalená knihovna vede k pádu a knihovna z distribuce nikoli: http://forum.ubuntu.cz/index.php?…
Takže kdyby SDL bylo slinkováno staticky, tak by to ten uživatel nemohl rozchodit vůbec, takhle se mu to aspoň podařilo po dotazu v diskuzi.
"tak si ten balíček samozřejmě může udělat jak chce.“
A jak? Udělat balíček, který by šel instalovat na libovolnou distribuci
je nedosažitelný sen… :-( Asi tak .tar.gz zbývá.
Autopackager ( http://www.autopackage.org/ )? Loki instalator ( http://icculus.org/loki_setup/ )? Install Jammer? ( http://www.installjammer.com/ )?
Možností jsou – používají se – nevidím problém,…
Nejsem expert na debian, fyzicky mi tu bezi jen jeden, ale debian ma tu peknou vlastnost, ze nekompatibilni verze teze knihovny se odlisuji jiz v nazvu. Konkretne po upgradu etch->lenny mam naistalovane tyto knihovny:
libgpm2 obsahujici libgpm.so.2
libgpmg1 obsahujici libgpm.so.1.19.6 a simlink libgpm.so.1
(Ne, fakt netusim, proc je tam to „g“ nevic)
Ech…
Pokud je „linux jedna z podporovanych platforem“, tak asi nekdo za ten program plati. Potom naklad na vytvoreni balicku pro tu jednu distribuci urcite neni velky naklad (odhadem jeden clovekoden). No a pokud mate vice zakazniku s vice distribucemi, tak mate zase i vice prijmu a opet vytvoreni balicku je naklad nula nula nic.
Pokud mate jenom jednoho zakaznika s jednou distribuci tak nevidim duvod ve snaze vytvaret univerzalni binaku pro vsechny distribuce.
No a pokud za ten program nikdo neplati, tak nevidim duvod proc ho udrzovat closed source a nenechat starosti s balickovanim na nekom jinem.
Jeden člověkoden je dost podhodnocená představa – jestli ten program prodáváš, tak ho taky musíš testovat a to bude podstatně víc než člověkoden. Nezapomeň, že i když to někde nebude chodit třeba kvůli tomu, že dotyčná distribuce má bug v kompilátoru, stejně vina za to bude přisuzována tobě jako vývojáři toho programu.
ja bych zustal u toho, ze spousta vyvojaru se chova jako banda linejch, egocentrickejch a neprispusobivejch hovad, ktery se v zivote nedohodnou ani na velikosti fontu (a uz vubec ne na moznosti si velikost vybrat).
v linuxu chybi jednotny system instalace a nikdo se na nem v zivote nedohodne. pritom by stacilo vymyslet zpusob, kterym se predaji verze systemovych knihoven a cesty k nim uz zkompilovane binarce. take by bylo vhodne udelat system, ktery by umoznil z jednoho binarniho balicku instalovat stejne binarky na ruzna mista (podle zvyklosti distribuce).
o co, ze za 50 let se nic nezmeni? vsadim svy nejoblibenejsi boty.
„pritom by stacilo vymyslet zpusob, kterym se predaji verze systemovych knihoven a cesty k nim uz zkompilovane binarce.“
Cesty nepotřebuješ předávat (v binárce totiž většinou nejsou, hledá je linker). A předávání verzí ti nepomůže, protože když je do toho programu zakompilované jedno ABI, tak ti nic nepomůže, ten program s novou verzí prostě chodit nebude.
Základní problém je v tom, že programátor udělá knihovnu s funkcí třeba int moje_funkce(int a, int b, char *c);
za půl roku ho napadne, že by ten jeho program mohl mít ještě nějakou novou cool funkci a změní to na: int moje_funkce(int a, int b, char *c, char *d);
Většina vývojářů knihoven si na tuto situaci dává pozor a nedělá ji. Ale ne všichni. A když mají distribuce takové podmínky, že „všecko musí být linkováno dynamicky, statické knihovny se dokonce v distribuci nesmí ani vyskytovat“, tak pak není snadné udělat binárku co chodí na více distribucích.
Správně by distribuce měla rozdělit knihovny na ty, co mají stabilní rozhraní (a ty dodávat jako dynamické), a na ty, co nemají (dodávat jako statické).
no tak pokud jde o ty prenositelny binarky, tak sem vzdycky myslel, ze staci pustit gcc s argumentem -static a prakticky vsechny knihovny se do binarky nalinkuji natvrdo. existuji prece programy (napr sash – standalone shell), ktery funguje i bez glibc a je tedy zavisly jenom na kernelu (kde neni problem s kompatibilitou).
Nejak tomu nerozumim :-(
Co vlastne chcete? Protlacit ten svuj program do [vsech] distribuci nebo ho dodavat extra? Pokud extra, co vam brani se z vysoka vykaslat na pravidla distribuce? A pokud ho chcete protlacit do distribuci, tak holt musite prijmout jejich podminky …
BTW: Dovoluji si silne pochybovat, ze by v nejake distribuci meli extremni zajem o closed source program – pokud se tedy nejedna o ovladac k nejakemu zelezu …
http://people.redhat.com/…dsohowto.pdf
http://people.redhat.com/…linking.html
„nemyslim, ze existuje mezi lidma co delaji distribude poptavka po podpore binarek chodici na vice distribucich bez rebuildu.“
Existuje poptávka, lidi např. hodně fňukají, že se pro Linux nedělají hry nebo specializované profesionální programy. V těchto případech vývojář musí vyrobit binárku, co chodí na více distribucích bez rebuildu.
„takova knihovna ma byt opravena“
To je Sysifofská práce: tři špatné knihovny opravíš a další tři nové špatné se ti do distribuce dostanou. Tento proces nikdy neskončí. Existence nekompatibilních knihovnen se nezbavíš, můžeš se zbavit leda důsledků, a to např. tím, že nespolehlivé knihovny linkuješ staticky, že je dáš do speciálního adresáře /usr/lib/only-for-fedora-9 a zajistíš, že se s nimi nebude linkovat nic jiného než programy z distribuce „Fedora 9“ nebo že ty knihovny budeš přibalovat rovnou ke každému programu. A když ty zmiňované „Guidelines“ všechna tato řešení zakazují, tak pak máme takovou situaci, že binárka zkompilovaná na jedné distribuci nechodí na jiných distribucích.
„moznost verzovani ABI, SONAME apod.“
Což vede leda k tomu, že místo pádu v případě nekompatibilních rozhraní se ti program nespustí – je to lepší než segfault, ale podstatu problému to neřeší.
V těchto případech vývojář musí vyrobit binárku, co chodí na více distribucích bez rebuildu.
Jaktože musí? Proč?
Koukni se na příklad Zimbry [1]. To je sice open source, ale nikdo ji do žádné distribuce nedá, takže si to balíčkují sami. Udělali 10 různých balíčků a hotovo. Kdyby tam nebyl ke stažení ten zdrojový kód tak by to klidně mohl být proprietární systém.
A sysifofská práce to není. Holt vynecháš rychle se měnící distribuce (Fedora) a budeš podporovat jenom ty dlouhodobé (RHEL/Centos, Debian, Ubuntu LTS). Když vzpomínáš herní tituly… Tam se dělá PC, XBOX, Nintendo, Playstation. A to jsou jiné platformy, jiný hardware, jiné architektury. Oproti tomu přebalit rpm balíček z CentOSu na OpenSUSE je procházka růžový sadem se zanedbatelnými náklady.
„Holt vynecháš rychle se měnící distribuce (Fedora) a budeš podporovat jenom ty dlouhodobé (RHEL/Centos, Debian, Ubuntu LTS)“
RHEL instalované mám, a že by to bylo nějak víc kompatibilní než ostatní distribuce, bych netvrdil.
Příklad: chtěl jsem instalovat Wine. V neoficiálním repozitáři pro RHEL je jen verze 1.0.1. Takže BFU může skončit u této verze a novou si tam nenainstaluje, protože balíček neexistuje.
Já jsem se rozhodl kompilovat. S plnou podporou všech možností se to stejně nezkompilovalo, protože autoři Wine mají novější verze knihoven (např. gnutls) než jsou v RHEL. Nějak se to nakonec zkompilovalo (bez hal, šifrování, scanneru, gphoto a nevím čeho ještě; tvrdilo to, že s OpenGL) a 3D grafika nefungovala stejně. Po několikadenním zkoumání a doinstalaci více -devel balíčků a nové kompilaci 3D fungovalo (který balíček tomu pomohl opravdu nevím, protože výstup ./configure byl v obou případech stejný).
A co má dělat BFU, co neumí kompilovat, když chce jeden nový program, třeba to Wine? Smazat RHEL a nainstalovat si tam novou Fedoru nebo Ubuntu, pro které nový balíček s Wine existuje? – jenže tím si tam zavede spoustu dalších bugů v kernelu i v userspace (a napíše na spoustu internetových fór, jak ten Linux padá) a po roce ztratí na svou distribuci bezpečnostní updaty.
„Existuje poptávka, lidi např. hodně fňukají, že se pro Linux nedělají hry nebo specializované profesionální programy. V těchto případech vývojář musí vyrobit binárku, co chodí na více distribucích bez rebuildu.“
„Sorry, ale todle je blbost. Udelas SW, ale uz nemas cas/penize udelat balicek pro distribuce?“
Když si vezmeš, kolik jich je, a že nová verze té samé distribuce nepouští binárky pro starou verzi – pak ano, je to problém. Programy se buď distribuují v .tar.gz, nebo v .rpm, které není pro tu distribuci, kterou mám, takže je třeba ho ručně rozbalit (takhle jsem instaloval třeba Intel C
cesty, ale prostý BFU takhle nic nenainstaluje).
Proč se ty distribuce nemůžou domluvit na společném formátu balíčku a na seznamu knihoven, které vývojář může používat (a všechny distribuce pak garantují, že dodají knihovnu binárně kompatibilní s knihovnami z toho seznamu)?
Já u svých programů balíčky pro distribuce taky nedělám. Kdyby existoval jeden formát balíčku, tak bych dělal.