linux user group brescia

From: Gabriele Villi <gvilli a iol.it>
>>From: "Luca Coianiz" <lcoianiz a w3.to>
>>  Io ho (purtroppo) installato tutto tramite YAST, che gestisce
direttamente
>>i pacchetti RPM e ogni volta che devo installare qualcosa NON compresa
nella
>>distro che ho su CD (quindi non necessariamente pacchetti RPM, anzi...
quasi
>>mai) mi vengono i vermi [...]
>>1) come fare a verificare i prerequisiti d'installazione ? (YAST lo fa per
i
>>cavoli suoi... sui suoi CD)
> Io ti so dire qualcosa per quanto riguarda i pacchetti rpm e tgz, per gli
> altri tipi (es deb) non so.

 Non ho idea se la SuSE permetta di gestire (a meno dell'installazione di
appositi tools) pacchetti in altri formati o in formati specifici di altre
distribuzioni (deb).
 In questi giorni ho avuto modo di parlare con un amico che se ne intende
più di me d'installazione, gestione e rimozione di sw che m'ha confermato
che lui, se può (quasi sempre però), usa i pacchetti in formato rpm (o, se
deve ricompilare, srpm).

 Come detto inizialmente: sono più che sicuro che RPM (il prodotto) gestisca
al meglio la "vita" del pacchetto (installazione, verifica dei prerequisiti,
history log, test, disinstallazione, ecc.), anche perchè mi pare sia nato
proprio per quello.
 Quindi seguito il suo (e tuo) saggio consiglio: nel limite del possibile
installerò .rpm (mi dicono che si trovano quasi sempre).

 Fra l'altro YAST dovrebbe gestire una spece d'interfaccia rpm ANCHE per
pacchetti esterni a quelli della distribuzione (ma questo devo verificarlo).
 L'alternativa è un uso command-line-only di RPM... oppure scovare
un'interfaccia grafico/testuale (a la MC) da poter utilizzare: personalmente
sono piuttosto favorevole (anche perchè sono un newbie) alle GUI minimali in
formato testo, mentre sono piuttosto contrario ad effettuare installazioni
da X (non c'è un motivo logico... è che X mi da una sensazione d'instabilità
che non provo nemmeno con Windows).

 Qualche consiglio in merito ad una RPM-GUI ?

 Come ultima "chicca" volevo dire che RPM sembra quasi clonato dal mondo IBM
MVS, dove girano prodotti tipo SMP/E che servono proprio a gestire
l'installazione e l'aggiornamento (tramite patch) dei prodotti ad Host.
Guarda caso, come nel mondo **ix, SMP/E può essere utilizzato con
un'interfaccia simil-GUI (MOLTO spartana) o tramite comandi (o batch).
 Sempre per il discorso "downsizing" che facevo in un altro messaggio: SMP/E
ha qualche annetto sulle spalle.  ;-)

>>  Dove cavolo riesco a vedere se HO installato glibc-v2.1.0,a-c*b [...]
> convenzionalmente il nome della libreria ti da indicazioni anche sul tipo
e
> sulla versione
> esempio libtermcap.so.2.0.8 e' la libreria dinamica (.so) termcap versione
> 2.0.8 mentre libpam_misc.a e' la libreria statica (.a) pam_misc.
> Strumenti utili sono ldconfig -p per le librerie dinamiche e
rpm --query -f
> nomefile per tutti i file. Ad es sul mio sistema
> [gv a mail]# ldconfig -p | fgrep libc.
>          libc.so.6 (libc6) => /lib/libc.so.6
>          libc.so.5 (libc5) => /usr/i486-linux-libc5/lib/libc.so.5
> [gv a mail]# rpm --query -f libpam_misc.a
> pam-0.68-7
> [gv a mail]# rpm --query -f libtermcap.so.2.0.8
> libtermcap-2.0.8-18
>
> E ancora
> [gv a mail]# rpm --query -a | fgrep libc
> glibc-profile-2.1.2-11
> libc-5.3.12-31
> glibc-2.1.2-11
> compat-glibc-5.2-2.0.7.1
> glibc-devel-2.1.2-11

 Per vedere se i conti tornavano sono andato a verificare i requirements di
un prodotto che tentavo di installare (apple2-emul-0.7.3): fra questi c'era
"joystick 0.8.0" (quindi posso immaginare che si riferisse al file
joystick-0.8.0).
 Vado a cercarlo e trovo:

#find / -name *joystick*
... (tutta una serie di dir/files)
/lib/modules/2.0.36/misc/joystick.o
/lib/modules/2.2.0-pre7/misc/joystick.o
... (tutta una serie di dir/files)

 Ora... di che versione possono essere 'ste librerie "joystick" ?  :-?
 Ah... fra l'altro, sempre nei prerequisiti, trovo: "libc 4.4.4 (or later).
Tested under glibc-2.0.6"
 Beh... libc l'ho trovata (-4, -5 e pure -6) ma di glibc nemmeno l'ombra.
:-|

>>2) una volta che sono (miracolosamente) riuscito ad installare... come
>>faccio, se mi va, a disinstallare (magari a distanza di tempo) SENZA
>>compromettere l'integrità (sacra) del sistema ? [....]
> Secondo me il problema va affrontato da un punto di vista piu' generale e
> cioe': quanto e' "sacra" l'integrita' del tuo sistema?

 Diciamo "abbastanza da potermi creare qualche problema se l'intero
ambaradan non funziona ma non tanto da spingermi al suicidio" (anche se
sento la mancanza di un buon backup).  :-)

 E' un "server" che uso, in rete locale, per testare i siti web che produco,
per imparare e (poco sigh) per divertirmi.
 Di "stabile" ci girano solo SETI a home ed Apache (più tutta quella congerie
di background tasks che uno tende a dimenticare quando tutto fila liscio e
che saltano invece alla ribalta quando c'è qualche problema). ;-)
 Fin'ora la programmazione si è limitata al livello source-only (shell e
Perl): non ho ancora compilato niente.

> Io installo e
> disinstallo spessissimo sia a casa che in ufficio. A casa la mia macchina
> e', tecnicamente parlando, un vero casino. In ufficio ho una macchina
> apposta sulla quale posso anche permettermi di distruggere tutta
> l'installazione. Non mi passa nemmeno per l'anticamera del cervello di
fare
> esperimenti sui server aziendali.

 Beh... diciamo che nel momento stesso in cui il mio pinguino dovesse
diventare un "server aziendale" (e spero che il momento NON sia troppo
remoto) terrei almeno un HD (da poter spianare) per installazioni e test (io
lavoro principalmente con HD su slitta, per avere la separazione fisica dei
diversi ambienti... e dei casini).

> E questo vale per linux, per win
> e per ogni altra diavoleria che dovesse venir fuori. Se c'e' qualcosa di
> nuovo da provare lo si fa su un muletto, MAI su macchine il cui fermo sia
> oneroso in termini economici.

 Infatti anche per Windows ho HD separati (sempre su slitta) per programmi
seri, giochi e prove: faccio partire di volta in volta il sistema che mi
serve (inutile dire che l'HD dei giochi è coperto da un paio di etti di
ragnatele).

> Se proprio sono costretto ad usare una
> macchina "preziosa" faccio un bel backup e prima di fare qualsiasi
> operazione piu' complessa di ls ci penso tre volte (e per me e' una vera
> impresa gia' pensare una volta sola, figurati tre!)

 ;-)))))

 A parte le battute, quello del backup è un argomento tra i più trascurati e
malvisti dell'intera informatica credo (dopo Windows intendo): personalmente
mi secca tantissimo pensare di "buttare via" tanto spazio di memorizzazione
(e tanto tempo per riempirlo)... tranne poi fare i salti di gioia quando
qualcosa va male ed HO fatto il backup.  ;-)))))

> Venedo alle tue domande specifiche:
> Se il pacchetto ti viene dato in forma rpm, deb o simili il relativo
> programma di gestione fornisce anche le opzioni per disinstallare il tutto
> (es rpm --uninstall).

 Infatti credo che userò solo quelli d'ora in poi.

> Se il pacchetto ti arriva in forma tar.gz se sei
> fortunato trovi o un makefile con l'opzione uninstall o uno script oppure
> istruzioni nei readme o doc. Se non le trovi puoi guardare cosa fa il
> processo di installazione  e procedere al contrario.

 Non sono ancora così ferrato da capire cosa fa esattamente uno script
(d'installazione o meno che sia).
 Per di più spesso il make --install  riversa tanti di quei messaggi che mi
lasciano veramente frastornato (dopo un pò rinuncio a capirci qualcosa e mi
chiedo perchè non me ne sono rimasto al caro vecchio Dos).

 Ma magari è colpa mia che parto dal fondo: forse se cominciassi a lavorare
con RPM me la caverei meglio.

> Se non c'e' neanche
> uno script (o simile) di installazione probabilmente il pacchetto e'
> talmente semplice che puoi rimuovere a mano i file. In ogni caso prima di
> cancellare definitivamente i file e' buona politica invocare l'aiuto dei
> tre santi: Santa Prudenza, San Buon Senso e San Backup, ad esempio
> spostando in una directory temporanea (magari su un'altra macchina)
> preservando la struttura e permessi (ad es sposta /usr/local/bin/makemoney
> in /home/luca/quarantena/usr/local/bin/makemoney). Per queste cose spesso
> viene molto utile il tar e le sue (n+1)! opzioni.

 Parole... sante.  ;-)

> Le conversioni tra tipi di pacchetto sono possibili (almeno da/a tgz)
> rpm2targz
> rpm2cpio
> rpm -b
> rpm -t
> Per i debian, invece, mi pare che si possano scompattare/creare con ar.
> Ovviamente la semplice scompattazione e' (o meglio, penso che sia) piu'
> semplice che non la creazione.
> Io uso con una certa frequenza rpm2targz perche' sono curioso :) Cosi'
> riesco anche a vedere dove diavolo vanno a finire i file!

 A parte il fatto che sono curioso anch'io... ma la conversione DA rpm non
risolve il problema: lo risolverebbe una conversione A rpm.
 Avendo letto però qualche dettaglio del formato rpm penso che NON sia
possibile convertire un .tgz in un .rpm in modo automatico (come non è
possibile cominciare a costruire una casa partendo dal tetto, mentre invece
E' possibile smontare il solo tetto da una casa già costruita).

> Da ultimo, anche se l'architettura unix ti sembra "sparsa" secondo me e'
> comunque meglio organizzata di quella win.

 Poco ma sicuro. Al limite posso dire che quella di Win è solo un pò meglio
conosciuta (ma neanche poi troppo... e poi io odio i giochetti a base di
file nascosti e chiavi di registro).

> Ci sono dei posti convenzionali
> dove mettere i file (se guardi l'archivio del lug trovi messaggi in cui
> questo argomento e' gia' stato affrontato) e non hai bisogno (leggi: sei
> ostaggio) di strumenti di gestione particolari (es regedit, user manager e
> via dicendo).

 Il semplice fatto di usare semplici file di testo per me è sempre stata una
gran cosa.
 Pensa che ho obbligato un programmatore Win che mi stava sviluppando
un'utility ad usare un config file di testo al posto delle maledette chiavi
di registro.  ;-)

> Inoltre e' tutto documentato. Devi solo aver piu' pazienza
> all'inizio.

 Hai pienamente ragione (lo sto imparando sulla mia pelle). Casomai si può
dire che "c'è troppa documentazione" e spesso si fa prima a chiedere (qui in
ML) in che direzione andare, piuttosto che spulciarsi tutto lo scibile Linux
on ed off line.
 NON è per menefreghismo: è proprio perchè uno, soprattutto agli inizi, si
sente perso in mezzo a tutti quei mega di roba.

 Grazie ancora per le molte informazioni: mi hai chiarito parecchio le idee.
 Proverò a lavorare con i pacchetti rpm... e credo che mi risentirai presto.
;-)

        Bye
        Sky