Analisi librerie di un repository non ufficiale

Coordinamento delle attività e informazioni sui progetti del gruppo: creazione, modifica e gestione dei pacchetti di Ubuntu e relative problematiche.

Moderatore: Gruppo Sviluppo

Avatar utente
DktrKranz
Rampante Reduce
Rampante Reduce
Messaggi: 5071
Iscrizione: giovedì 2 novembre 2006, 11:24
Desktop: GNOME Shell
Distribuzione: Debian GNU/Linux sid - x86_64
Località: Guastalla (RE)
Contatti:

Analisi librerie di un repository non ufficiale

Messaggio 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.
Ultima modifica di DktrKranz il mercoledì 5 settembre 2007, 13:46, modificato 1 volta in totale.
Avatar utente
Rospo Zoppo
Rampante Reduce
Rampante Reduce
Messaggi: 5291
Iscrizione: martedì 16 gennaio 2007, 20:35

Re: Analisi librerie di un repository non ufficiale

Messaggio da Rospo Zoppo »

ma quindi è un casino aggiornare una libreria... nel senso che bisogna ricompilare tutti i pacchetti che ne dipendono giusto?
Avatar utente
DktrKranz
Rampante Reduce
Rampante Reduce
Messaggi: 5071
Iscrizione: giovedì 2 novembre 2006, 11:24
Desktop: GNOME Shell
Distribuzione: Debian GNU/Linux sid - x86_64
Località: Guastalla (RE)
Contatti:

Re: Analisi librerie di un repository non ufficiale

Messaggio da DktrKranz »

In questo caso non è necessario, in questo sì.
Avatar utente
Rospo Zoppo
Rampante Reduce
Rampante Reduce
Messaggi: 5291
Iscrizione: martedì 16 gennaio 2007, 20:35

Re: Analisi librerie di un repository non ufficiale

Messaggio da Rospo Zoppo »

avevo visto quel bug, era linkato nel wiki... che casino  ::)
Avatar utente
DktrKranz
Rampante Reduce
Rampante Reduce
Messaggi: 5071
Iscrizione: giovedì 2 novembre 2006, 11:24
Desktop: GNOME Shell
Distribuzione: Debian GNU/Linux sid - x86_64
Località: Guastalla (RE)
Contatti:

Re: Analisi librerie di un repository non ufficiale

Messaggio 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.
Avatar utente
Lord_neo
Prode Principiante
Messaggi: 163
Iscrizione: giovedì 24 agosto 2006, 11:35
Contatti:

Re: Analisi librerie di un repository non ufficiale

Messaggio 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)
Scrivi risposta

Ritorna a “Gruppo Sviluppo”

Chi c’è in linea

Visualizzano questa sezione: 0 utenti iscritti e 1 ospite