Newsgroup: it.comp.os.linux.iniziare
Titolo: Installazioni sotto linux

Ciao a tutto il NG,
finalmente ho potuto dedicare un po' di tempo a questo nuovo sistema 
operativo che mi ha sempre affascinato, sin dalle origini. Dunque sono 
alle prime armi con questo OS ma non per questo non ho voglia di impare...
Allora vendo al dunque,
ho una serie di dubbi riguardanti le installazioni sotto Linux. I 
pacchetti RPM vengono installati con la sintassi (in genere): rpm -ivh o 
meglio a volte con: rpm -Uvh. Inceve per disinstallare si utilizza il 
comando rpm -e.  In generale facendo l'installazione il sistema RPM 
penserà lui a dove posizionare i relativi files. (fin qui giusto?! :-D)
Il problema sorge quando il programma da installare non è distribuito 
tramite RPM ma (ad. es Apache) deve essere installato con la sintassi 
(qui non la ricordo alla perfezione):
./config -PREFIX=prefix (prefix viene utilizzato per personalizzare la 
path dell'installazione!?)
make
make install
E' corretta!? Comunque qui mi sorge spontaneo anche quest'altro dubbio: 
utilizzando questo sistema, lui stesso penserà a installare il programma 
nelle cartelle appropriate o sono necessarie altre operazioni?!
Devo lanciare questi comandi sul pacchetto dopo averlo spostato in una 
cartella specifica o non c'è differenza!?
Sempre con questo sistema (che a volte compila i sorgenti) come posso 
operare una disistallazione?!
Grazie in anticipo per la disponibiltà,
jRed
PS: Scusate la lunghezza del post e le domande troppo annidate! Per caso 
c'è qualcuno che conosce un bel tutorial (caso mai in italiano) molto 
valido!? :-) Grazie ancora!

 operare una disistallazione?!
sempre nella stessa directory,
make uninstall
(funziona spesso ma non sempre).
E` comunque *caldamente consigliato* usare -o, in caso di bisogno, 
modificare- i pacchetti binari forniti dalla distribuzione, limitando
al massimo il ricorso ai sorgenti.
-- 
Francesco Romani -- Ikitt 
'In fact, users don't read /anything/'                         -- Joel Spolsky

 valido!? :-) Grazie ancora!
Noooo...sei stato bravo :P
Un tutorial... bhe.. basta che leggi la documentazione allegata al
programma che vuoi (se proprio devi) compilare...se ben fatta c'e'
scritto tanto :)
Inoltre se qualcosa va storto nel configure o nel make ti viene
restituito sempre un errore piu' o meno comprensibile che puoi sempre
copioincollare in google... 
ciauu :))
-- 
  .''`.  | Chi è prudente ed aspetta con pazienza chi non lo è, sarà
 : :'  : | vittorioso. [Sun Tzu]
 `. `'`  |
   `-    |

 Un tutorial... bhe.. 
Qui io mi riferiferivo ad un tutorial (anche su linux in generale)...o 
anche sul "dietro" di linux...comunque nulla di troppo approfondito! :-D
Ciao,
jRed
PS: forse un po' OT in questo post...ma che ne pensate della FC2!? 
Rispetto alla Red hat 9.0?!

 ancora meno yum (Casa Suse!?)
Casa Fedora e/o YellowDog (Distribuzione per PowerPC, MacIntosh e
compatibili).


 
quoto, e aggiungo usa checkinstall per i sorgenti ......
-- 
Linuxuser Slackwaredotato

 quoto, e aggiungo usa checkinstall per i sorgenti ......
sapreste anche spiegarmi il perche? per il fatto che non sempre funziona 
il make uninstall? mi sembrava di aver capito che fossero molto meglio i 
sorgenti, sapevo che complilandoli sulla propria macchina si adattavano 
meglio ed eran piů performanti dei pacchetti precompilati...
grazie a chi mi illumina!

 grazie a chi mi illumina!
si, messoti a posto il Makefile, ma la possibilita' didisinstallare 
facilmente e senza creare problemi e' un altro problema.
Come suggeritoti da dmec usa checkinstall.
ciao
-- 
Toyotoshy
Linux user #312588 ( 
http://counter.li.org
 )
Powered by GNU/Linux Slackware, kernel 2.4.26!
http://www.gnu.org/
  &   
http://www.linux.org/

 meglio ed eran più performanti dei pacchetti precompilati...
Premesso che dalle mie esperienze le distribuzioni basate su RPM danno
spesso problemi nella compilazione da sorgenti, dipendenze da soddisfare
gcc errato o altri problemini...........
il vantaggio di checkinstall è che tiene traccia di cosa ha installato e
dove, oltre a creare un pacchetto che puo' essere RPM .tgz o .deb a seconda
dei casi, quindi una volta creato il pacchetto usero' i tools nativi della
distribuzione per gestirli....
cmq io lo uso "sempre" su Slackware........vedi tu...
-- 
Linuxuser Slackwaredotato

 meglio ed eran più performanti dei pacchetti precompilati...
Sull'aumento di performance ci sono da fare parecchi distinguo
e da sfatare parecchi miti. In piu`, i guadagni, quando ci sono,
ci sono in ben determinate circostanza, e sotto configurazioni
accurate: non e` che la sacra trinita` (./configure && make && make install)
ha poteri magici, la differenza la continua a fare l'utente, 
anche in questo caso.
In piu`, esistono pur sempre i pacchetti sorgenti, che a costo di un
periodo di apprendimento maggiore, consentono di unire
i benefici (o quantomeno grossa parte di questi) dei due mondi.


>>>al massimo il ricorso ai sorgenti.
[CUT]
Grazie mille a tutti, ho capito.. pero' se dico che spesso e volentieri 
i pacchetti sono poco aggiornati siete daccordo? :P

 i pacchetti sono poco aggiornati siete daccordo? :P
In generale, no. Su sid mi/ci sparano anche 50 MB di update al giorno.
Su Gentoo sono sempre sul filo del CVS, o quasi.
Su Mandrake Cooker (O Slackware current) idem. 
Anche Fedora Core se la cavicchia.
Dipende dalla distribuzione, e dalla "versione" della medesima :)


 Dipende dalla distribuzione, e dalla "versione" della medesima :)
cavolo :)
io ho una debian testing/unstable e non mi sembrano molto aggiornati.. 
anzi.. tanto che e' un anno ormai che la uso ed ho sempre installato da 
sorgente (a parte qualche libreria).. per fare un esempio aMule che č 
alla versione 2.0.0 me la trova pacchettizata solo fino la 1.2.6!! e non 
č poi poco che e' uscita la 2.0.0, e cosi per la maggior parte dei 
programmi!
Cambiero'! :)

 alla versione 2.0.0 me la trova pacchettizata solo fino la 1.2.6!!
Si, queste 'stranezze' nella gestione dei pacchetti su deb/sid le ho
riscontrate anch'io, e francamente mi risultano per ora di difficile
comprensione.
Nel caso generale, pero` non ho di che lamentarmi :)


 distribuzione per gestirli....
Quindi come è possibile procedere utilizzando il checkinstall!? Scusate 
la domanda, forse un po' stupida, ma facendo checkinstall sopra un 
pacchetto installabile tramite (./config & make & make install) ottengo 
un RPM?!
Quindi in fin dei conti è meglio utilizzare checkinstall rispetto al 
make!? In che modo è possibile utilizzare il checkinstall ( e funziona 
con tutti i pacchetti/distro) ?!
Grazie in anticipo,
jRed

 un RPM?!
mi sono da poco documentato anche io su questo checkinstall, mi sembra 
di aver capito (in effetti funziona) che con
./configure && make && checkinstall make install
fai quello che facevi prima, solamente dopo aver compilato i sorgenti, 
crea il pacchetto (-D, -R, -S, vedi man checkinstall) e lo installa, 
rendendo cosi possibile la disinstallazione dello stesso e rendendo 
possibile al tuo sistema di gestione pacchetti capire che cosa hai 
effettivamente installato.


Io lo uso solo con Slack e debian pero' non credo dia problemi con gli
RPM...
cmq la sequenza è : ./configure ; make ; checkinstall .....
volendo puoi modificare il tuo checkinstallrc per fare le cose in automatico
cioè non ti farà domande e installerà al volo nel formato che hai scelto..
-- 
Linuxuser Slackwaredotato

 comprensione.
Perché 'unstable' non è 'bleeding edge'. In fondo, non stiamo mica
parlando di Gentoo, no? *grin*
Ciao,
 Emmanuele.
-- 
Emmanuele Bassi (Zefram)                 [ 
http://www.emmanuelebassi.net
 ]
GnuPG Key fingerprint = 4DD0 C90D 4070 F071 5738  08BD 8ECC DB8F A432 0FF4

 Perché 'unstable' non è 'bleeding edge'.
Claro: per quello c'e` experimental, o repository di terzi, o gentoo ;)
Quello che fatico a spiegarmi e` perche` certi pacchetti (chiaramente
di ordine di grandezza paragonabile) entrino in sid relativamente
in "ritardo".
Presumo, in effetti, che il problema principale sia la mia percezione
della "criticita`" di un'aggiornamento di un dato pacchetto, probabilmente 
sottostimata: iniziero` a guardare con piu` assiduita` ai vari 
README.debian e alle varie patch ;)
Oltre agli occasionali scazzi degli sviluppatori e/o agli orphaned,
che chiaramente possono sempre starci.


 in "ritardo".
Perché i maintainer mica possono tutto... ;-)
In fondo, non si tratta di prendere un tar.gz, compilarlo, e mettere su
un pacchetto, e chi si è visto, si è visto.
Bisogna rispettare - soprattutto in termini di auto-gestione - dei
canoni base per poter mettere su un pacchetto su Unstable. Ovvero, anche
se Unstable si può rompere ("and you keep both the pieces"), la volontà
principale sarebbe buttarci dentro roba che non si rompe se non su
alcune architetture esotiche, o quantomeno che se si rompe non fa danno.
Soprattutto in nuce del fatto che, ormai, gli utenti Debian tendono ad
usare Testing o direttamente Unstable, per via del ritardo infame
accumulato dalla Stable.
