linux user group brescia

    [...]
>>Ci HO guardato... ci sono dentro tutte (penso) le man pages.
>>Mi sono rimasti comunque DUE dubbi:
>>  1) cosa cavolo vuol dire se una pagina è in /usr/man/man2 piuttosto che
in
>>/usr/man/man6 ?
> le sezioni di man raggruppano i comandi per macro-argomenti. Esempio la
> sezione 2 documenta le chiamate di sistema. Da qualche parte c'e' anche un
> elenco (completo) delle convenzioni man non mi ricordo dove :) Comunque se
fai
> man 1 intro
> ottieni il "frontespizio" della sezione 1 (idem per la 2, 3, ecc.) con le
> informazioni del caso.

 Grazie per l'informazione: ho dato un'occhiata a tutte le intro (ed anche a
'man man') ed ho cominciato a capire qualcosa della struttura della
documentazione (info lo affronterò in seguito).

>>  2) come mai l'unico pacchetto (o dovrei dire "tarball" ?) che ho
installato
>>io ha piazzato la sua man-page in /var/catman/local/cat6/ ?
>>(se è in /var/... non dovrebbe essere un temporaneo ?)
> Le manpage di solito devono essere preprocessate prima di essere
> visualizzate [...] La copia preformattata puo'
> ovviamente essere creata e/o eliminata in ogni momento (ed ecco perche' e'
> in /var), mentre e' poco carino cancellare la pagina "sorgente" ...

 Infatti la cosa mi ha stupito un pò: è come se ci fosse la pagina
"cacheata" da CAT ma non ci fosse più traccia dell'originale (non l'ho
trovata nè con man -w ...  nè con un find).
 Non mi sembra molto regolare.

 Piuttosto: se trovassi il source della pagina che adesso è in /var/.../cat6
(ad es. apple2.6) e lo trasformassi in apple2.6.tgz lo potrei poi copiare in
/usr/man/man6/ senza rompere le uova nel paniere a man ? (o devo ricostruire
qualcosa (qualche indice) tramite mandb ?)

> Per ulteriori informazioni fai man man  - questa cosa qui mi e' sempre
> piaciuta un sacco :)

 Molto interessante davvero (ed anche sintetico).

>>  Una cosa credo d'averla capita: finchè non si è pratici di tutto
>>l'ambaradan conviene lavorare con i pacchetti .rpm o, al massimo, .srpm.
>>  Grazie per le info: tenterò di lavorare con RPM (il manager) e vedrò
cosa
>>ne salta fuori.  :-)
> gli rpm sono molto comodi ma rischi di perdere un po' il controllo (come
> con qualsiasi altro strumento automatico). Di fatto gli rpm (e i deb) non
> sono altro che targz arricchiti degli script di de/installazione,
> dipendenze, descrizioni, ecc. tutte cose che *dovresti* trovare anche in
un
> pacchetto tgz ben fatto. Con la differenza che con rpm e' la macchina che
> "si legge la documentazione", con i tgz invece sei tu. Pero' alla fine si
> tratta sempre della stessa roba: mettere i file nei posti giusti e con i
> permessi opportuni, eventualmente aggiornare alcuni script di
> configurazione e magari (ri)avviare alcuni demoni/servizi. Facile, vero?
:)

 Beh... se posso fare un paragone con cose che conosco un pò meglio, usare
un .tgz è un pò come, nel mondo Dos, scompattare un archivio (.zip, .lha,
.rar, .arj o altro) e lanciare install.bat il quale può o meno controllare
alcune cose principali (ad es. l'esistenza di alcuni file o la versione del
S.O.) ma non molto altro ed al massimo segnalare che è andata male
l'installazione.

 Usare RPM dovrebbe invece assomigliare di più all'utilizzo di un gestore
che controlla parecchie cose di più: che i "minimum requirements" siano
rispettati, il fatto di non andare a sovrascrivere file più nuovi di quelli
che ci si aspetta di trovare o anche, in fase di disinstallazione, che i
file generati dell'utente (setup particolari, textfiles, ecc.) non vengano
rimossi.

> Scherzi a parte, un problema che ho riscontrato e' che rpm (e suppongo
> anche deb) presuppongono che tu de/installi ogni cosa nel loro formato,
> perche' altrimenti non riescono ad aggiornare il loro db. Ad esempio, come
> fa rpm a sapere che io ho installato chebelpacchetto-1.5.8.tgz? Cosi'
> quando cerchero' di installare chissaseva-2.4.1.rpm che richiede
> libchebelpacchetto.1.5.8 avro' un bel messaggio che mi dice che la
> dipendenza non e' soddisfatta.

 Da questo punto di vista mi trovo d'accordo... con RPM (DEB ecc.): mi
sembra piuttosto illogico che un utente installi un pacchetto usando un
gestore e poi magari gli tolga il tappeto da sotto i piedi andando a zappare
file e librerie a mano.
 Probabilmente il problema principale nasce dal fatto di non trovare tutti i
pacchetti che si desidera installare in formato .rpm: a questo punto,
aggiornando la versione di una libreria tramite un .tgz, RPM rischia di
perdere il filo dello stato del sistema.
(quando usavo SMP/E, sotto MVS, TUTTE le installazioni e gli aggiornamenti
venivano effettuati via SMP... anche perchè IBM non forniva altro).

> Invece risenti di meno del problema se
> installi un pacchetto in forma tgz sorgente perche' spesso ti trovi lo
> script ./configure che valuta dinamicamente la configurazione del sistema
> (in pratica prova a compilare al volo con diverse opzioni/librerie per
> indovinare quelle che van bene) ed adatta il Makefile di conseguenza.

 Penso che il problema, con i .tgz, è che "ogniuno si fa i fatti suoi" (una
volta rispettati i requisiti minimi) mentre RPM tenta di avere una visione
globale del "parco software" installato e di manutenere quella.

> Quand'anche non ci fosse ./configure, puoi sempre risolvere le cose a
mano,
> tanto hai i sorgenti... :)

 Per chi mi hai preso ?.. non sono mica Mandrake io !!!  ;-)))

 Al mio attuale livello penso che ci metterò qualche annetto prima di poter
mettere le mani nei source di qualcun altro e far funzionare le cose che non
dovessero andare.

 E d'altro canto, anche se un pò di conoscenza di programmazione è
indubbiamente necessaria, io la vedo da un punto di vista più
"sistemistico": devo sapere quanto basta per far funzionare un sistema
(quindi al massimo un pò di shellscript e di Perl) ed avere la visione
globale della struttura (rete compresa), non sapere quale bit di quale
programma devo andare a modificare per far funzionare la tal cosa. Questo
ovviamente in ottica "business", dove non c'è tanto tempo "da perdere" e
dove, se serve, il know-how lo si "compra" da qualcun altro.

 In ottica hobbistica rimango su una posizione simile ma sono già molto più
disposto a "perdere tempo" cercando di capire cos'aveva per la testa il tal
programmatore quando ha implementato il tal algoritmo o perchè il tal
makefile produce errori sulla mia installazione.
 Infatti quasi tutti gli esperimenti li faccio, almeno per ora, su giochi
e/o affini: anche se non vanno non ci perdo molto.  ;-)

        Bye
        Sky