Pagina 1 di 1

Analisi librerie di un repository non ufficiale

Inviato: mercoledì 5 settembre 2007, 13:39
da DktrKranz
Spinto da alcuni commenti di diversi utenti del forum, ho dato una controllata ad uno dei repository più popolari del panorama italiano, quello di Treviño.

Ho notato con un po' di preoccupazione che vengono distribuite tre librerie presenti in Feisty, aggiornate ad una nuova versione. Siccome l'aggiornamento di un pacchetto di libreria deve seguire regole ben precise, ho deciso di controllare a fondo i tre pacchetti in questione:
  • libfaac0
  • libsnack2
  • libgeoip1
Per prima cosa ho osservato i pacchetti da cui dipendono le librerie in questione, fortunatamente nessun pacchetto essenziale è coinvolto:

Codice: Seleziona tutto

libfaac0
Reverse Depends:
  mplayer-nogui
  mplayer
  mencoder
  libfaac-dev
  gstreamer0.8-faac
  gstreamer0.10-plugins-bad-multiverse
  faac
  avidemux

libgeoip1
Reverse Depends:
  xqf
  webalizer
  pike7.6-pexts-geoip
  link-monitor-applet
  libapache2-mod-geoip
  libapache-mod-geoip
  ipv6calc
  geoip-bin
  python-geoip-dbg
  python-geoip
  libgeoip-dev

libsnack2
Reverse Depends:
  wavesurfer
  transcriber
  libsnack2-dev
  alicq
L'operazione successiva è consistita nell'analisi dei simboli introdotti o rimossi per ciascuna libreria.
Anche in questo caso, se si escludono alcune librerie standard, non sono emersi problemi particolari:

Codice: Seleziona tutto

Nuovi simboli libfaac
+__stack_chk_fail



Nuovi simboli libsound
+TclTomMathInitializeStubs
+floorf
+tclTomMathStubsPtr

Nuovi simboli libsnack
+TclTomMathInitializeStubs
+floorf
+tclTomMathStubsPtr

Nuovi simboli libsnackogg
+TclTomMathInitializeStubs
+tclTomMathStubsPtr



Nuovi simboli libGeoIPUpdate
-strchr
L'analisi più approfondita da fare è stata quella su libgeoip1. Siccome il file di libreria è cambiato (da libGeoIP.so.1.3.17 a libGeoIP.so.1.4.0), ho dovuto ricontrollare manualmente se tutti i pacchetti dipendenti da tale libreria avessero correttamente impostato quella nuova.
Fortunatamente il soname non è mutato (libGeoIP.so.1) e potevo comunque evitare di controllare, ma un controllo aggiuntivo non fa mai male:

Codice: Seleziona tutto

root@moses:/# ldd /usr/games/xqf | grep -i GeoIP
        libGeoIP.so.1 => /usr/lib/libGeoIP.so.1 (0xb7f80000)
root@moses:/#

root@moses:/# ldd /usr/bin/webalizer | grep -i GeoIP
        libGeoIP.so.1 => /usr/lib/libGeoIP.so.1 (0xb7f26000)
root@moses:/#

root@moses:/# ldd /usr/lib/pike/7.6.93/lib/modules/GeoIP.so | grep -i GeoIP
        libGeoIP.so.1 => /usr/lib/libGeoIP.so.1 (0xb7f8e000)
root@moses:/#

root@moses:/# ldd /usr/lib/link-monitor-applet/link-monitor-applet | grep -i GeoIP
        libGeoIP.so.1 => /usr/lib/libGeoIP.so.1 (0xb73ce000)
root@moses:/#

root@moses:/# ldd /usr/lib/apache2/modules/mod_geoip.so | grep -i GeoIP
        libGeoIP.so.1 => /usr/lib/libGeoIP.so.1 (0xb7f3b000)
root@moses:/#

root@moses:/# ldd /usr/lib/apache/1.3/mod_geoip.so | grep -i GeoIP
        libGeoIP.so.1 => /usr/lib/libGeoIP.so.1 (0xb7fdd000)
root@moses:/#

root@moses:/# ldd /usr/bin/ipv6calc | grep -i GeoIP
        libGeoIP.so.1 => /usr/lib/libGeoIP.so.1 (0xb7f66000)
root@moses:/#

root@moses:/# ldd /usr/bin/geoiplookup | grep -i GeoIP
        libGeoIP.so.1 => /usr/lib/libGeoIP.so.1 (0xb7f5d000)
root@moses:/# ldd /usr/bin/geoipupdate | grep -i GeoIP
        libGeoIPUpdate.so.0 => /usr/lib/libGeoIPUpdate.so.0 (0xb7fbd000)
        libGeoIP.so.1 => /usr/lib/libGeoIP.so.1 (0xb7fa1000)
root@moses:/#

root@moses:/# ldd /usr/lib/python-support/python-geoip/python2.5/GeoIP.so | grep -i GeoIP
        libGeoIP.so.1 => /usr/lib/libGeoIP.so.1 (0xb7eef000)
root@moses:/# ldd /usr/lib/python-support/python-geoip/python2.4/GeoIP.so | grep -i GeoIP
        libGeoIP.so.1 => /usr/lib/libGeoIP.so.1 (0xb7f19000)
root@moses:/#
Il tutto mi ha portato via un paio di orette, questo per dimostrare la complessità di un'analisi di un pacchetto di libreria e la pericolosità di un suo aggiornamento azzardato. Fortunatamente i pacchetti in questione erano pochi, nell'ipotesi fosse stata coinvolta una libreria vitale per il sistema (per esempio libfreetype6), si sarebbe potuto tranquillamente parlare di suicidio di massa.

Re: Analisi librerie di un repository non ufficiale

Inviato: mercoledì 5 settembre 2007, 17:08
da Rospo Zoppo
ma quindi è un casino aggiornare una libreria... nel senso che bisogna ricompilare tutti i pacchetti che ne dipendono giusto?

Re: Analisi librerie di un repository non ufficiale

Inviato: mercoledì 5 settembre 2007, 17:12
da DktrKranz
In questo caso non è necessario, in questo sì.

Re: Analisi librerie di un repository non ufficiale

Inviato: mercoledì 5 settembre 2007, 17:15
da Rospo Zoppo
avevo visto quel bug, era linkato nel wiki... che casino  ::)

Re: Analisi librerie di un repository non ufficiale

Inviato: mercoledì 5 settembre 2007, 17:25
da DktrKranz
Quando si caricano nuove librerie negli archivi, i maintainer di Debian solitamente inviano una mail a debian-devel annunciando quali pacchetti sono soggetti alla transizione. Questo ne è un esempio: http://lists.debian.org/debian-devel/20 ... 00634.html.

Re: Analisi librerie di un repository non ufficiale

Inviato: martedì 11 settembre 2007, 17:21
da Lord_neo
Insomma è un bel casino :)

DktrKranz, cosa mi consigli di fare qui? Da quel poco che ci ho capito mi conviene lasciare perdere (yes)