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.
Es hany van ezek kozul, amelyik nincs verziozva? (Lasd a masodik opciot arra, hogy miert nem no egyes libek so-versionje: symbol versioning)
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.
Ez igy van. De tekints el a disztrotol - a librarykat disztrokon kivul is hasznaljak, nem azert van verziozva hogy a disztroknak jo legyen. Az csak egy mellektermek. A libraryknak disztro nelkul, csomagkezelo nelkul is mukodniuk kell, upgradelhetok kell hogy legyenek. Ha nem azok, az sulyos hiba.
A belegondolasra valasz:
A: Lehet, hogy a kereskedelmi disztribek ugy mukodnek - de legtobbjuk vagy nem ad ki ket verzio kozt csomagot, es akkor upgradenal egyszeruen kurvasokmindent frissitesz egyszerre, vagy szopas az upgrade (vagy azert, mert nehez, vagy azert, mert baromi sokminden ujrafordult, feleslegesen). Jobb helyeken a usert nem kenyszeritik ra, hogy csomo mindent letoltson egyszerre, hanem szepen lassan hagyjak hogy elevuljon a regi library (ezt hivjak evolucionak, ami egy marhajo dolog, szerintem).
B: Lasd Debian, mi ezt az utat jarjuk a legtobb esetben. A megoldas annyi, hogy csak a legujabb headerjei vannak fent, a regebbie nincs - igy az szepen eltunik majd, ha semmi nem hasznalja. Valoban nemi plusz munka, ha security update van, de nem veszes (foleg ha csak i386 vagy, akkor rohelyesen egyszeru). Viszont a user, aki esetleg unstablet hasznal, vagy valami hasonlot, jol jar, mert lepesenkent tolti le a programokat, nem egyszerre sokat. Osszessegeben igy lehet, hogy tobb savot eszik meg tole, meg tobbet foglal a vinyojan, de egy atlag usert ez baromira nem erdekli. Ot az erdekli hogy egyszerre minnel kevesebbet kelljen upgradelni, inkabb lepcsozetesen teszi azt. Amikor bevasarolni mesz, akkor sem 1 honapra elore vasarolsz be, hanem csak 1 hetre mondjuk.
Visszaterve a linkeles es includeok kontrollalasahoz: van fent libreadline.so.4, libreadline.so.5, readline 5.0 headerjei. readline 4.3 headerek nincsenek is a distribben, mert az obsolete, es upgradelunk epp 5.0-ra. Melyikhez fog linkelni? Megmondom! Ahhoz, amelyikre a libreadline.so symlink mutat! Csinalsz egy -dev csomagot, amiben van libreadline.so->libreadline.so.5 symlink, valamint a headerek, es kontrollalva van a linkeles meg az includeok. Evek ota bevalt es mukodo modszer Debianban.
Tulajdonkepp mindket modszer jo, attol fugg hogy melyik a jobb, hogy milyen tipusu disztrib vagy - ha nincs unstable, hanem csak releasekor vannak frissitesek (meg security updatekor), akkor nyilvan kisebb melo a mindent ujraforgato modszer, es a usereknek tokmindegy, ugyis csak 1 nagy upgradet kapnak. Ha van unstable, akkor kevesebb, jobban elosztott forgatassal jar (foleg, ha a forgatas automatizalva van, ami nem egy rossz otlet), es a userek is jobban fognak szeretni ha a lepcsozetes library upgradet valasztod. Ez ugyan security update eseten 1 keves plusz melo, de meg mindig kevesebb, mint amikor neked kell kitalalnod upstream helyett hogy a csomagok amik a libet hasznaljak, azoknak most eleg a regi verzio, vagy mindenkepp az uj kell (lasd az altalad emlitett problemat - ugyanaz a helyzet, nem nott a so-version amikor kellett volna).