> A glibc azert tart kettonel, mert: 1) reg nem kerult bele uj symbol
Soroljam a symbolokat, amik a 2-es lib sorozatban jelentek meg? Küldjek két nm közti diffet? Csak amit fejből tudok: a teljes *_l() (locale-specifikus függvények) és a hozzájuk tartozó newlocale() és társai a 2.3-asban jelentek meg.
Fordítsak readline 4.0-t és küldjek nm diffet a 4.3-hoz képest? Nem csináltam meg. Nem vagyok benne biztos, hogy van új függvény azóta, szóval lehet hogy bebukom. De akkor keresek más libet szívesen.
> A csomagkezelot felejtsd el, a sonamehoz annak semmi koze. Az ad egy keretet, kiegeszitest, amivel konnyebben kezelhetove teszi a dolgokat.
Technikai oldalról nincs köze hozzá, de tudod, amikor egy disztribet vagy akármilyen komplett rendszert raksz össze, akkor nem szemlélheted az egyes komponenseit külön-külön, hiszen minden mindennel összefügg. Szerintem rengeteg disztribben, de az UHU-ban mindenképp például a soname fentiekben tárgyalt hiányosságait pont (többek közt) a csomagok depends mezeje küszöböli ki.
> nem mindig egy egesz szamot, de a minor version szepen szokott noni amikor kell
Én csak és kizárólag a soname-ről beszélek, ami jólnevelt libek esetén a major verziószám, nem a minor. "objdump -p libraryneve | grep SONAME" -- na ebből a számérték. Ehhez linkelnek a progik, vagyis amit egy libhez fordítasz le (és linkelés során tipikusan a verziószámozás nélküli .so szimlinket használja a C-fordító), az futáskor ezen a néven (vagyis soname-en, tehát általában major verziószámon) fogja keresni a libet. A minor verzió növekedéséről én nem beszéltem, normális fejlesztő minden egyes kiadásban növeli ezt az értéket.
> Vegezetul, gondolj csak bele, hogy mi lenne akkor, ha csak akkor none egy library sonameja, ha az inkompatibilis lefele! Kezelhetetlen lenne a rendszer.
Belegondoltam. Íme:
A eset. Két lehetőséged van, speciel például az UHU-Linuxban mindkettőt használjuk, de külön-külön is elegendőek volnának. Egyik lehetőség: a hiányosságot pótolod a csomagkezelőben, vagyis berakod, hogy a library kellően új verzióját igényelje. Másik lehetőség: nem "rakd össze magadnak" típusú disztribúciót nyújtasz a felhasználó számára, hanem olyan disztribet, ahol a dolgok egyféleképpen össze vannak rakva. Vedd észre, hogy minden kereskedelmi disztrib ezt követi. Semelyik nem támogatja azt, hogy keverd két szomszédos kiadásának a csomagjait. Ez a megközelítés rengeteg disztribúcióban működik.
B eset. Az általad vázoltakból arra a következtetésre jutok, hogy a rendszeren totál fölöslegesen kell minden egyes libet jópár verzióban eltárolni. Persze mindegyik pontosan tudja azt, amit mindegyik nála régebbi tud, de mégsem azt használjuk, mert de tök jó, hogy a nagyágyú mellett van egy vizipisztolyunk is. Fölöslegesen nagy a disztrib helyfoglalása. Biztonsági javítás esetén ugyanannak a libnek több verzióját kell a disztrib készítőjének legyártania, és nekem többet kell fölöslegesen letölteni. Ha progit fordítok, baromi nehezen kontrollálható, hogy melyiknek az include fájljait használja, melyikhez linkeljen. A librarykban oly gyakran jelennek meg új feature-ök (sokszor teljesen jelképes apróságok), hogy ez az út szerintem járhatatlan.
Eléggé off, de egy kis nyalánkság a Gnome csapattól: libwnck 2.6.2-ről 2.6.2.1-re az egyik publikusan elérhető függvénynek hirtelen eggyel több argumentuma lett, emiatt például az acme nem fordul vele. Hehehe. Na ezt már szerintem sem így kéne.