Bash 3.0

Szerszám

Megjelent a Bash (GNU Bourne-Again SHell) névre hallgató népszerű shell implementáció harmadik nagy kiadása. Az anyag letölthető innen. A dokumentációja elérhető itt.A bash-2.05b verziója készült patch letölthető innen. A bejelentés itt. A bash honlapja itt (link a GNU oldalról).

( egmont | 2004. 07. 29., cs – 18:58 )

A korrektség kedvéért az igazi honlap itt van [cnswww.cns.cwru.edu], nem a gnu oldalon:

A bash-sel szoros kapcsolatban lévő, immár 5.0-s verziójú readline oldala pedig itt [cnswww.cns.cwru.edu].

Tegnap-ma frissítettem az UHU-ban, szívtam rendesen. Nagyon nem tetszik, ahogy a fejlesztés halad.

A changelog vagy news vagy ilyesmi fájlok alapján volt beta1, rc1 kiadás. Hogy mikor, az már nem derül ki. Arról fingom nincs, hogy honnan lehetett volna leszedni. 1-2 hónapja tuti megnéztem a honlapot, semmi infó nem volt 2.05b-nél újabb kiadásról.

A readline changelogja nem nyilatkozik arról, hogy az API illetve az ABI megváltozott-e, de mivel csak néhány új fv-t említ meg, így valószínűsíthető, hogy nem. A nemleges választ tovább valószínűsíti, hogy az UHU összes csomagja kapásból változtatás nélkül lefordult az új readline-nal, illetve még a régi readline binárissal is jól működött. Csak ugye .so.4 helyett most már .so.5 a fájlnév, így egy buta install után a readline-t használó progik el sem indulnak. Sebaj, az UHU csomagba beraktam .so.4 -> .so.5 szimlinkeket. Undorító, tudom. A fejlesztőnek meg ejnye-bejnye, mert szivatja a népet azzal, hogy indokolatlanul növeli a library soname-jét.

Az, hogy az ősrégi readline UTF-8 kezelése *****, nem túlzottan érdekelt. De az, hogy az új verzió UTF-8 kezelése is *****, miután a szerző a changelog szerint kifejezetten foglalkozott a témával, és nyilván Fedoráék is megpatchelték ezerrel, szerintem nagyon szomorú.

A bash changelogot elolvasva sehol nem találkoztam vele, de a ${valtozo/mit/mire} típusú cserénél az előzőekhez képest másmilyen mértékben kell a mit-beli spéci karaktereket (*, ?, ~ stb.) escape-elni. Hejj de jó.

sh-ként meghívva a "trap 0" parancs hibával elszáll, így a gcc és a mawk nem fordult elsőre, patchelnünk kellett. A dokumentáció szerint ennek nem így kéne lennie.

A visszajelzési rendszerük szánalmas. Adott egy e-mail cím a readline-hoz és egy a bash-hoz. Ezek állítólag levlisták. A bash-hez webes archívum is van. A readline-hoz vajon miért nincs? Feliratkozni vajon miért nem lehet egyikre sem? Vagy lehet, csak találd ki, hogy hogyan? Miért van az, hogy a tegnap küldött két levelem sok-sok óra késéssel megjelent a webes archívumban, de amit ma küldtem be, az hibával visszapattant? Hol van bugtracker? Hol van publikus verziókezelő rendszer? Miért nem lehet egy nap elteltével sem letölteni az ftp.gnu.org-ról, ha egyszer egy GNU projekt, miért csak a hivatalos (szinte senki által nem ismert) honlapról érhető el?

Mindemellett megjegyezném, hogy az új readline és bash messze nem tartalmaz annyi változást a régihez képest, ami egy ilyen drasztikus verizónövelést indokolt volna. Jó, hogy két éve nem volt release, de úgy fest, hogy munka sem nagyon a csomagokkal. Mondjuk readline 4.4 és bash 2.1 vagy 2.2 korrektebb verziószám lett volna, jobban tükrözte volna, hogy mire kell számítani, és a library soname-mel sem kéne szívni.

Hjajj.

( pete | 2004. 07. 29., cs – 19:21 )

Ajjajj, remélem nem lesz szívás az új uhuval emiatt ...


A readline changelogja nem nyilatkozik arról, hogy az API illetve az ABI megváltozott-e, de mivel csak néhány új fv-t említ meg, így valószínűsíthető, hogy nem.

...

A fejlesztőnek meg ejnye-bejnye, mert szivatja a népet azzal, hogy indokolatlanul növeli a library soname-jét.

Egy fenet indokolatlan! Az, hogy visszafele binarisan kompatibilis, az csak annyit jelent hogy a regi symbolok nem valtoztak. De ha uj kerult bele, akkor illik novelni a soversiont, kulonben ha valami azt hasznalja, akkor linkelodne ugye .so.4-hez. Nomarmost, valakinek van egy regi readline 4.3-ja, akkor az a binarist nem tudja hasznalni, mert az uj symbol hianyzik. Ergo novelik a soversiont. Ilyen egyszeru a dolog.

Erre a szituaciora az a megoldas, hogy libreadline4 es libreadline5 csomagok - tokeletesen megfernek egymas mellett. Ha meg mar semmi nem hasznalja libreadline4-et, akkor annak bucsut int az ember.


Mondjuk readline 4.4 és bash 2.1 vagy 2.2 korrektebb verziószám lett volna, jobban tükrözte volna, hogy mire kell számítani, és a library soname-mel sem kéne szívni.

A verzioszamozassal egyetertek, de megjegyzem, hogy ha 4.3 lett volna a readline, a soversion akkor is 5-re nott volna (lasd fentebb).

Abszolút nincs igazad, soversion-t visszafelé inkompatibilis változáskor szokás növelni. Szerinted ha új feature-ök, új függvények megjelenésekor növelnék, akkor a readline most 5-nél tartani, a libstdc++ 5-nél, a glibc 6-nál, a glibc legtöbb kiegészítő libje 2-nél, az ncurses 5-nél, a zlib és libbz2 1-nél stb... tartana? Szerintem párszáz körül járnának mind.

Az általad említett problémára a megoldást általában az nyújtja, hogy a csomagkezelő, amikor mondjuk readline 4.3-hoz fordítasz és linkelsz valamit, akkor beteszi a csomagba, hogy legalább 4.3-as readline kell neki; ha 4.2-es mellé felerőszakolod, akkor kétesélyes, vagy menni fog, vagy nem. Ha pedig 4.2-höz akarod fordítani, és neki tényleg 4.3 kellene, akkor a fordítás már a header fájlokon el fog hasalni.

Rosszul hiszed, igazam van, olvass el barmilyen library versioningrol szolo irast (ha szepen megkersz, adok par linket :) A Unixok egy jelentos reszen (lasd BSDk) nincsen csomagkezelo, sot, Linuxok kozott is van olyan, ahol egy darab ilyen nincsen. A libraryk verziozasat meg nem csak csomagkezelos OSeknek talaltak ki (elvegre zlib van peldaul BSDken is).

A glibc azert tart kettonel, mert: 1) reg nem kerult bele uj symbol 2) belsoleg verziozva vannak a symbolok. Ez tobb mas libraryra is igaz (peldaul libtstdc++-re is, iirc, bar az epp most ugrott 6-ra ha jol emlekszem). ncursesbe szinten ezer eve nem kerult semmi uj, zlibbe es libbz2-be sem nagyon. Emlits inkabb olyan libeket, melyek nem egy szabvany implementalnak (libc, libstdc++), es eleg aktiv a fejlesztesuk. Azoknak a soversionjei bizony nonek szepen (nem mindig egy egesz szamot, de a minor version szepen szokott noni amikor kell).

Ha jo peldat akarsz latni arra, hogy uj function, symbol versioning nelkul hogyan mukodik, nezd meg NetBSD libcjet, ami mar 40 korul jarhat, ha jol emlekszem. Vagy valamelyik GNOME-os lib volt ami ket eve ugy 17-nel jart, hasonlo okokbol. Visszafele teljesen kompatibilis volt sokszor, csakhat az uj featureok...

A csomagkezelot felejtsd el, a sonamehoz annak semmi koze. Az ad egy keretet, kiegeszitest, amivel konnyebben kezelhetove teszi a dolgokat.

Ha meg ugy adodott, hogy uj soversion lett egy libbol, akkor ket dolgot lehet tenni egy disztribben:

1) ujraforgatni mindent ami hasznalja (barbar, de gyors megoldas)

2) csinalni egy oldlibs/libreadline4 csomagot, meg egy libreadline5, es libreadline-dev csomagot (-dev mindig a legfrissebb verzio headerjet, stb tartalmazza), es szepen fokozatosan atallni. Aztan ha semmi nem hasznalja a regit, akkor az bye-bye.


Vegezetul, gondolj csak bele, hogy mi lenne akkor, ha csak akkor none egy library sonameja, ha az inkompatibilis lefele! Kezelhetetlen lenne a rendszer. Jon egy uj verzio, teljesen kompatibilis visszafele, de van benne par uj feature. Ez egy minor verzio egyebkent.. Hurra! Bekerul distribbe, nem kell semmit ujrapergetni. Jon egy programbol uj verzio, ami hasznalja ezt az uj funkciot. Leforgatod uj libbel, feltoltod, user letolti, de a libet nem frissiti, mert minek, a dependencybol nem latszik. Hianyzik a symbol, user unhappy. Ez az A eset.

A B eset az, hogy minden egyes lib updatenal atnezed hogy van-e uj funkcio, es ha igen, akkor minden ami azt hasznalja, ujraforgatando, es a dependency beallitando. Ez eleg huzos munka, hidd el. A barbar megoldas az, hogy minden lib upgradenal mindent ujraforgatsz - de akkor mar hasznalhatnal static libeket is, minek shared, kb? Az ugy bazisok forgatas, teljesen feleslegesen.

Sokkal egyszerubb, ha upstream szepen noveli a soversiont amikor uj funkcio kerul bele, vagy inkompatibilis lesz, vagy amikor epp kell, es ezzel mindenkinek csomo munkat megsporol. Ezert lett ez igy kitalalva.

Fel nem fogom mi nem vilagos rajta, hogy oszinte legyek.

Szerintem Egmontnak ne emlegesd a libtool-t :-) Még nem néztem meg a csomagot, de gyébként, ha nincs doksi ami leírná és nincs is sok új és inkompatibilis feature, akkor nem volt értelme verziószámot növelni. Ez kb olyan, mint amikor a linux disztribek elkezdték növelni verziószámot és, hogy ne nézzék kőkorszakinek, hirtelen lett Slackware 7-es (vagy 8-as?). Vagy Solaris 8. Ami ugye majdnem tényleg az, csak 2.6 után ugrottak egy "kicsit". Mert ugye 2.8 lenne az is, bár azt hiszem talán 7-nél ugrották meg a nagy számozást. Van amikor a fejlesztőket elkapja a verziózási vágy.

> 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.

Te sem erted... A csomag verzioja es a so-version FUGGETLEN. Abban egyetertunk hogy felesleges volt readline 5.0-nak hivni, 4.4 ugyanolyan jo lett volna, sot, valoszinuleg jobb. DE!

Gondolj bele, olvasd at figyelmesen amit irtam: jon egy uj funkcio, forgatsz hozza valamit, ami hasznalja, es kirakod netre (mert te egy 3rd party emberke vagy, aki cegeknek arul binarist a programjabol peldaul, mert ilyen is van). Es akkor jon hozzad a user sirva hogy teee hulye pocs, nem mukodik a program, el sem induuul!!!1! Pedig tok nem a te hibad - upstream nem novelte a lib so-versionjet.

Itt nem arrol van szo, hogy fasza dolog verzioszamot noveli. So-version akkor jo ha nem no, glibc arra veri hogy regota nem nott, solaris meg arra hogy nala meg mindig minden .so.1. Szoval so-versiont akkor novelnek, ha elkerulhetetlen, akkor is nehez szivvel.

Ugyhogy kerlek teged, egmontot, meg mindenkit, olvassa vegig amit irtam, gondoljon arra, hogy letezik olyan is, hogy nincs csomagkezelo, vagy binary-only programot akar kiadni az ember (vagy egyszeruen egy havernak akarok adni 1 binarist es nem akarok belole debet, rpm-et csinalni mert macera, es 1 nyamvadt kis binaris az egesz), es utana mondjatok hogy hulyeseg verziot novelni, ha kerult bele uj funkcio.

(Sugok: readline 5.0-ba kerult)

A csomag és a library verziója általános esetben persze tök különböző is lehet, de sok fejlesztő választ azonos értéket, így például a readline esetén is megegyezik a kettő.

Algernon: egy valamit nagyon nem értek.

Tegyük fel, hogy valaki csinál egy új progit, ami igényli az 5-ös readline egy új szolgáltatását. És ezt valaki 4.3-as readline-nal akarja futtatni. Mit kap? Valami olyasmi hibaüzenetet, hogy nem találja a libreadline.so.5-öt.

Tegyük fel, hogy a mostani readline 4.4 lenne, vagyis változatlanul 4 lenne a soname, libreadline.so.4 lenne a fájlnév. Valaki ennek használatával, ehhez linkelve készít valami libet. Másvalaki megpróbálja 4.3-assal futtatni. Mit kap? Valami olyasmi hibaüzenetet, hogy feloldatlan szimbólumok.

Tehát mindkét esetben pontosan azonos módon hibát kapsz. A különbség csak annyi, hogy az egyik esetben picit egyértelműbb, picit beszédesebb a hibaüzenet. Azt tehát mindkét esetben le kell kommunikálnod a felhasználóval (bármilyen módon, legyen az csomag Depends mezeje, honlapon leírás, dobozos termék oldalán figyelmeztetés, akármi) hogy neki legalább 4.4 vagy 5.0 verziójú readline fog kelleni.

Akkor tehát miért is jobb az 5-ös soname-re váltás a 4-esnél maradásnál?

Mert epp ugy hozta a sors, hogy megeggyezzen. Lehet, hogy a so-version noveles besegitett a csomag verziojanak megvalasztasaba (de nem forditva!)

Igen, ha readline5-hoz fordit, es 4.3-al akarja futtatni, azt kapja hogy nincs libreadline.so.5. Igen, ha 4.4 lenne, azt kapja hogy feloldatlan szimbolumok. A hiba mindket esetben fellep, igen. Viszont utobbi esetben lehet, hogy a programbol maradt ki a symbol, nem a libbol (elofordulhat), vagy bugos a compiler (ilyenre is volt pelda), de azt is gondolhatja a user, hogy az o libje tul uj, es abbol mar hianyzik egy deprecated opcio (erre is volt mar pelda).

Ezert jobb az 5-re valtas, mert az egyertelmuen tudatja, hogy ujabb verzio kell. Ellenkezo esetben van legalabb 3 mas alternativa is. Tovabba, ha upstream noveli a so-versiont, akkor a disztributoroknak is leegyszerusodik a dolga, mert nem kell figyelniuk, hogy minden amit az uj readline 4.4-hez forgatnak, az >= 4.4 -re dependeljen, ne pedig siman >= 4.x -re. (Vagy epp >= 5.0-ra, >= 4.3 helyett)

Mellesleg szerintem tok logikusan hangzik, hogy ha valamihez hozzaadsz uj dolgokat, akkor noveled a verzioszamot, nem? :)

Az alábbiak a CHANGES fájlból vannak összeválogatva. Ha az elvi soname billentési vitát nem is fogják eldönteni, azt teljesen egyértelműen jelzik, hogy a 4-es sorozat során számtalan alkalommal bővült az interface. Okozott valakinek problémát? Egyáltalán észrevette valaki?


This document details the changes between this version, readline-4.3,

and the previous version, readline-4.2a.

f. New application-settable completion variable:

rl_completion_mark_symlink_dirs, allows an application's completion

function to temporarily override the user's preference for appending

slashes to names which are symlinks to directories.

g. New function available to application completion functions:

rl_completion_mode, to tell how the completion function was invoked

and decide which argument to supply to rl_complete_internal (to list

completions, etc.).

i. New application-settable completion variable:

rl_completion_suppress_append, inhibits appending of

rl_completion_append_character to completed words.

This document details the changes between this version, readline-4.2a,

and the previous version, readline-4.2.

a. Added extern declaration for rl_get_termcap to readline.h, making it a

public function (it was always there, just not in readline.h).

c. New readline variable: rl_readline_version, mirrors RL_READLINE_VERSION.

d. New bindable boolean readline variable: match-hidden-files. Controls

completion of files beginning with a `.' (on Unix). Enabled by default.

This document details the changes between this version, readline-4.2,

and the previous version, readline-4.1.

a. The blink timeout for paren matching is now settable by applications,

via the rl_set_paren_blink_timeout() function.

b. _rl_executing_macro has been renamed to rl_executing_macro, which means

it's now part of the public interface.

c. Readline has a new variable, rl_readline_state, which is a bitmap that

encapsulates the current state of the library; intended for use by

callbacks and hook functions.

g. New application-callable function rl_set_prompt(const char *prompt):

expands its prompt string argument and sets rl_prompt to the result.

h. New application-callable function rl_set_screen_size(int rows, int cols):

public method for applications to set readline's idea of the screen

dimensions.

k. New function, rl_get_screen_size (int *rows, int *columns), returns

readline's idea of the screen dimensions.

This document details the changes between this version, readline-4.1,

and the previous version, readline-4.0.

g. New function for use by applications: rl_on_new_line_with_prompt, used

when an application displays the prompt itself before calling readline().

h. New variable for use by applications: rl_already_prompted. An application

that displays the prompt itself before calling readline() must set this to

a non-zero value.

i. A new variable, rl_gnu_readline_p, always 1. The intent is that an

application can verify whether or not it is linked with the `real'

readline library or some substitute.

> Mellesleg szerintem tok logikusan hangzik, hogy ha valamihez hozzaadsz uj dolgokat, akkor noveled a verzioszamot, nem? :)

De, igen. A library tényleges teljes verziószáma (nem a soname) nő is.

Mellesleg szerintem tök logikusan hangzik, hogy ha valamiből kijön egy újabb verzió, ami új feature-öket tartalmaz, a régiek viselkedését is esetleg javítja, de semmit nem vesz el vagy nem változtat meg inkompatibilis módon, akkor a régi alkalmazások is automatikusan ezt az újat használják, nem? :)


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).

Node magaban a libraryban tortent a valtozas! A csomag verzioja akkor is no, ha csak doksiban tortent valtzas, vagy a libhez mellekelt binarisokban. Azt is illik valahogy jelezni, hogy a libraryban is tortent valtozas.

Logikusnak logikusnak hangzana, ha nem lenne ott mellette, hogy ily modon ha az uj funkciokat is hasznalo progit regi libbel forgatom, akkor unresolved symbol uzenetet kapok. (Ami mint egy masik hozzaszolasomban mar emlitettem, kozel sem jelenti egyertelmuen azt, hogy uj libre kell upgradelni; a csomagkezelot meg itt felejtsd el, tegyuk fel hogy ez itt egy linux from scratch cucc).

A regi alkalmazasok teljesen jol hasznalhatjak a libraryt addig, amig az csak bugfixeket tartalmaz. Amint valtozik az API (uj funkcio, mas parameterek, funkcio eltunik, stb), illik az uj so-version, kulonben elobb-utobb szep kis kaosz lesz, hogy akkor most melyik verziohoz mi kell meg kulonben is.

Egy linux from scratch esetén miért akarsz bajlódni régi és új verziójú libek párhuzamosan tartásával, pláne amikor az új felülről kompatibilis a régivel?

Az utolsó bekezdésedre: pont erről van szó, egyetlen olyan csomagról sem tudok, ahol a mainstream karbantartó minden egyes új feature berakásakor forkolja a cuccát és a bugfixeket minden ágon továbbvinné. Vagyis a legapróbb interface bővítés során te a régivel linkelt programok esetén szeretnél lemondani mindenféle bugfix lehetőségéről?

Elvi síkon valóban igazad van abban, hogy kavarodást okozhat az általad említett szituáció, de ez a kavarodás véleményem és gyakorlati tapasztalataim alapján nagyságrendekkel kisebb (gyakorlatilag elhanyagolható), mint amennyi kellemetlenséget a folytonos verziónövelés okozna azzal, hogy a régiben lévő hibák nem fixálódnak, hogy csomó verziót kell párhuzamosan telepíteni és karbantartani... nade ezeket már elmondtam, miért is ismételném magamat...

Azert, mert baromira nincs kedvem ujraforgatni X programot azert, mert egyetlen lib upgradelodott, ami kell egyetlenegy uj programnak. Van jobb dolgom is a folyamatos forgatasnal. (/me a lusta user, akkor upgradel ha kell, nem pedig folyamatosan, erre pedig a ket lib egyutt egy ideig megoldas idealis. A legtobb user pedig, ha hiszed, ha nem, lusta.)

Bugfixek: a legtobb bugfix trivialisan backportolhato, sok esetben ugyanaz a patch ami felmegy az uj verziora, valtozatlanul felmegy a regire is (kiveve ha nagyon divergalodott a kod, de az azert ritka...)

A gyakorlatban megis eleg gyakori a so-version novekedes (foleg a fiatalabb projecteknel, regieknel lassabb fejlesztes, feature-completeness, stb miatt kevesbe), vagy pedig verziozva vannak a symbolok (erre egyre tobb lib all at, ami nem egy hatrany, sok so-version bumpot lehet vele sporolni :).

Az en gyakorlati tapasztalatom, jopar ev Debian hasznalat, debian-devel-changes@ es unstable kovetes utan (jezusom, ez mar az 5. evem unstable userkent!) az a tapasztalatom, hogy 2 verzional ritkabban kell tobbet karbantartani, es azokkal sincs sok melo. Libekben szerencsere ritkabbak a security bugok, es kevesbe divergalodik a kodjuk egyes verziok kozott, mint a programoke, igy a security updatek is egyszerubbek.

> B: Lasd Debian, mi ezt az utat jarjuk a legtobb esetben.

Értem, amit írsz, ezt pontosan így kell csinálni abban az esetben, ha egy library fő verziója indokolt módon megnő.

Mondjuk amikor kijött a readline 4.2 után a 4.3, és nyilván bővült az interface, akkor is így csinálta a Debian? Esetleg patchelte a readline-t, hogy jó legyen, és különböző verzión tudja vinni a kettőt? Vagy simán befrissítette? Miért?

Említed a sávszélesség-spórolást meg a sok apró és nem egyben nagy frissítést -- ezek mind amellett kardoskodnak, hogy ha nem indokolt, vagyis ha kompatibilis visszamenőlegesen a lib, akkor inkább ne csináljunk neki új csomagot, hanem egyszerűen a régi csomagot frissítsük be.

Írásaidat végigolvasva a kompatibilis interface-bővítés esetén történő verzió növekedésének egyetlen előnyét látom, azt is én mondtam elsőre, 3rdparty alkalmazás indulásának hibája esetén informatívabb hibaüzenet. Ebben te is megerősítettél, de nem találtam más érvet részedről. Ez szerintem elég apró érv azokkal szemben, amiket a túloldalon felsorakoztattam.

> Azert, mert baromira nincs kedvem ujraforgatni X programot azert, mert egyetlen lib upgradelodott, ami kell egyetlenegy uj programnak.

Miért kéne újrafordítanod? Egészen végig arról az esetről beszélünk, amikor az új lib felülről kompatibilis API és ABI terén is a régivel, vagyis a jó öreg alkalmazásaid mind egy szálig gond nélkül futnak az új libbel, jóllehet az új lib immár többet is tud, ami többletet ezek a programok nem fogjnak kihasználni.

Vagy eddig valami tök másról beszéltünk volna?

> ...2 verzional ritkabban kell tobbet karbantartani...

Biztos vagy benne, hogy ez akkor is így lenne, ha minden egyes apró új feature megjelenése verziónövekedést eredményezne a library soname-ben?

Akkor reason #2: Forgatok egy binarist, ami hasznalja az uj functiont, es odaadom havernak (vagy egyszeruen atrakom a masik gepre, amin szinten LFS van, csak a libet epp nem frissitettem, mert oda nem kellett a program), es nala nem megy, mert regi lib van. Ha mar van verzio, akkor az legyen hasznalhato - ha az ujjal forgatott cucc nem megy regivel, akkor valami modon valtozzon meg a verzio, es legyen ez benne a binarisban. Elvegre a verzio azert van hogy a valtozasokat kovesse, nem?

Abban is biztos vagyok, hogy 2-nel tobbet nem nagyon kellene - nincsen minden masnap release az egyes libekbol. Egy-ket het, de egy honap alatt siman at lehet allni az uj libre, szepen lepcsozetesen. Ha meg olyanrol van szo, mint readline, vagy libc, akkor meg sokkal sokkal tobb ido van erre. Meg a leggyakrabban releaselo libek is 2-3 hetente jonnek ki imho (ha gyakrabban, akkor ott baj van, es nem kene sharednek lennie, mert meg nem eleg stabil).

Vagy verziozzak a symbolokat es akkor nemileg kevesebb gond van.

Mivel a so-version akkor nem valtozott, a Debian kovette upstreamet. Kapott egy olyat a csomag, hogy amit vele forgattak, az mar az uj verziora dependelt. Nem szep, de ha upstream nem csinalja meg, akkor a distro workaroundolja. Ez meg nem jelenti azt, hogy ez jo. Ez egy workaround.

Savszel, egyebek: Adott libreadline4, kijon libreadline5. Elobb-utobb ugyis at kell allni libreadline5-re, ergo uj csomag mindenkepp kell. Elobb-utobb ugyis ujrafordul hozza minden. Ha csak egy libreadline csomagod van verzio nelkul, az szerintem eleg szivas :) Ugy eselytelen lepcsozetesen upgradelni (nem lehetetlen, csak csunyabb, mintha eleve a so-version benne van a csomagnevben).

*sigh*

Pedig par ervet felsoroltam:) De vegunk megegy analogiat, ha az eddigiek nem gyoztek meg: adott egy program, beleteszel uj featureoket. Noveled a verziot, vagy nem? (Egyetlen egy script az egesz a pelda kedveert). Tegyuk fel, hogy ezt mas scriptek/programok hasznaljak, parameterezik meg mindenfele josag. Ha uj feature van, noveled a verzioszamot? Szerintem mindket esetben igen a valasz, fuggetlenul attol, hogy inkompatibilis-e a regivel, avagy nem. Ugyanez a helyzet a libeknel is.

Valamint emlitettem meg azt, hogy ha upstream noveli a so-versiont uj feature eseten, akkor a disztributor dolga - marha lepcsozetesen akar upgradelni, ami nem egy rossz dolog ha az ember lusta mint a fene - lenyegesen egyszerubb, mert nem kell neki kitalalnia, hogy akkor most melyik verzion kell dependeljen minden, amit a libhez forgat. Mig ha upstream nem noveli, akkor ez a disztribek feladata - extra munka nekik. Ergo ha uj featurenel upstream so-versiont bumpolja, egyszerubb a distribek feladata ateren, hogy kovetik, mikor kell a libhez forgatott progik dependencyjet igazitani. Ha meg nem akarsz lepcsozetesen upgradelni, akkor egyszeruen azt mondod hogy mindent egylepesben ujraforgatsz es feltoltesz. Igy ebben az esetben is konnyebb dolgod van, mert upstream megmondta, hogy most kell ujraforgatni, mert uj feature van, es nem neked kell kitalalni.

Ez nem szamit igen igen nagy elonynek, meg disztribucio kesziteskor is? (Csak hogy eltavolodjunk az LFS otlettol, mert disztribet megiscsak tobben hasznalnak/csinalnak/wtf)

> adott egy program, beleteszel uj featureoket. Noveled a verziot, vagy nem? (Egyetlen egy script az egesz a pelda kedveert). Tegyuk fel, hogy ezt mas scriptek/programok hasznaljak, parameterezik meg mindenfele josag. Ha uj feature van, noveled a verzioszamot?

A csomagkezelőben, a --help-re kiírt szövegben növelem a verziószámot. DE a lényeg: a bináris vagy a library elérhetőségét, ahogyan másoknak hivatkozniuk kell rá, nem változtatom meg. A /bin/ls továbbra is /bin/ls marad. Vajon miért nem /bin/ls-5.2.0 volt eddig és /bin/ls-5.2.1 lett most belőle? És ha valaki ír egy szkriptet, ami igényli az 5.2.1 egy új feature-ét, akkor az bizony nem fog 5.2.0-val futni. Ez van. A library-k esetén sem kéne ennek másképp lennie. Amíg csak bővül, csak bővül a tudása, addig maradjon azonos néven elérhető.

Ha 5.2.0 kell neki akkor megnezi ./configure vagy hasonlo idejen a verzioszamot, es le sem fordul, akarcsak a libeknel:)

Libeknel - binarisokkal ellentetben - megvan az a lehetoseg, hogy raagassuk a verziot. Es hamar ott van, hasznaljuk ki. Uj dolog -> uj verzio, igy volt mindig, igy is kene maradjon, kulonben nagy kavarodas lesz elobb utobb (vagy a disztribek nyakaba szakad az egesz verziokezeles, ami mar igy is terhes picit, milyen lenne akkor ha senkinek nem none a verzioja, csak ha incompatible lesz).

Tovabbra is ajanlom hogy googlet hasznalva lelj fel nemi szakirodalmat ezugyben - lehet hogy ott jobban, erthetobben le van irva, ki van fejtve, hogy mikor es miert novel az ember so-versiont. Meg persze azt, hogy kepzeld el, mi lenne, ha neked kene figyelned MINDIG, hogy mikor kell novelni minden egyes libnel a dependency stuffot. Nem lenne terhes melo? Vagy az, vagy pedig a masik eset, hogy neha bizony no az so-version. A kozeput a random breakage. Ami abbol all hogy jon a bugreport hogy unresolved symbol, es akkor utolag az ember helyrehozza. De nem jobb elore gondolkodni?

(En mindenesetre elmegyek most aludni, jo googlezast :)