Newsgroup: it.comp.os.linux.iniziare
Titolo: RPM Based & C... Considerazioni e Delucidazioni.

Da quando uso Linux ho sempre avuto fra le mani distro basate su RPM, RH6,
FC2, MDK10, installavo quello che potevo poi spesso mi affidavo ai sorgenti
per avere tutto quello che mi serviva... Per esempio ora con mdk ho
installato SDl, non avendo gli rpm ho installato tutto a manina, solo che
poi ho fatto copia e incolla dei file perchè le directory delle
applicazioni installate da rpm sono diverse da qualle installate dai
sorgenti (forse per gestire meglio il sistema a RPM) e per ora sembra
funzionare bene. Quello che penso io è che comunque rpm e sorgenti non sono
proprio una coppia vincente, mi interessava sapere come funzionava il
sistema di installazione dei pacchetti delle altra maggiori distro (Slack,
SuSe, Debian) e se avevano lo stesso "problema" o se aveno un metodo
migliore per ovviare a dipendenze e cose varie.
-- 
Elimina Mark Phoenix per rispondermi in pvt.

 Davide
Installi la distro con l'essenziale e poi ti scarichi i sorgenti...è una
soluzione dato che ogni pacchetto cmq deriva da lì...


Mad Dog Michigan wrote:
 > (Slack, SuSe, Debian)
I files .deb (di debian) hanno praticamente gli stessi 
vantaggi/svantaggi degli rpm; vengono usati anche da knoppix, ubuntu, 
xandros, ximian...
Gli rpm sono usati da fedora, redhat, mdk, suse...
Gentoo usa un sistema diverso (portage)
Slack non usa niente (o meglio niente di ufficiale).
Per mettere le cose a posto puoi usare checkinstall.
-- 
Lorenzo `paulatz' Paulatto
Trieste
``Se Gauss fosse vivo oggi, sarebbe un hacker.''
      --Peter Sarnack (Princeton University)

 migliore per ovviare a dipendenze e cose varie.
Il sistema di slack per gestire le dipendenze è il migliore: non gestire 
le dipendenze :-)
Suse usa anch'essa rpm, anche se Yast ci mette del suo a controllare 
quello che fai quando installi/disinstalli. APT pure. In pratica pero', 
nessuno di loro è in grado di aiutarti se all'insaputa del packet 
manager gli installi di forza qualcosa direttamente dai sorgenti :-)
La via "corretta" di fare le cose sarebbe (il condizionale è d'obbligo), 
quando parti dai sorgenti, preparare di tua manina un rpm o deb e 
installare quello. Ma più realisticamente, se mantieni la roba 
installata a manina in un ambiente abbastanza pulito (cioè la installi 
in directory ben precise e controllabili con facilità) puoi cavartela 
abbastanza bene anche mescolando i sistemi.
-- 
Fabrizio "Hermooz" Ermini

 per avere tutto quello che mi serviva... Per esempio ora con mdk ho
Premetto che uso mandrake e sono entusiasta dell'accoppiata rpm + urpm*, 
che quando li conosci bene si rivelano *veramente* utili.
Usare un sistema di pacchettizzazione come rpm (altro non conosco, e non 
posso dire) ti garantisce queste cose:
1. Installare facilmente un programma con tutte le dipendenze, nella 
medesima versione e nello stesso ambiente di altre migliaia di persone, 
perciò spesso eventuali problemi che possono accadere sono già noti ed è 
facile risolverli.
La presenza di repository come quelli offerti da mandrake facilita 
ulteriormente questo passo.
Per non parlare del fatto che spesso questi sistemi di gestione dei 
pacchetti aggiornano anche i menù degli ambienti desktop degli utenti, 
facendoci risparmiare un po' di lavoro se abbiamo definito più di un utente.
2. Rimuovere facilmente un programma che non ti serve più (farlo dai 
sorgenti può essere parecchio seccante, a volte). Inoltre sei stai per 
rimuovere (per recuperare di spazio sul disco, per esempio) una libreria 
che che credi inutile, sei avvisato se c'è qualche programma che dipende 
da essa.
3. Aggiornare facilmente una vecchia versione di un pacchetto a una più 
recente, che eventualmente corregge bug.
4. sapere in ogni istante cosa hai installato sul sistema e cosa no.
5. Controllo sulla qualità del pacchetto scaricato e installato: rpm fa 
  uso di pgp e md5, per garantire l'integrità e l'affidabilità di quanto 
installi.
6. (questa non è molto pubblicizzata ma è importante IMHO) Un sistema di 
pacchettizzazione ti consente di confrontare i file installati sul 
sistema con informazioni nel database, per verificare se c'è qualche 
file importante danneggiato, mancante o corrotto, e consente di 
ripristinare rapidamente il file danneggiato. Credo che "rpm -Va" sia 
impagabile, e ti può salvare in molti casi.
7. Ti aiuta a capire cosa fa un certo file: supponi che girovagando per 
il file system ti imbatti in un misterioso file chiamato /etc/bho, e tu 
stia morendo dalla curiosità di sapere chi l'ha installato e a chi 
serve... puoi sempre chiederlo a rpm o a urpmi:
$ rpm -qf /etc/bho
bho-0.1.2-mdk
oppure
$ urpmf /etc/bho
bho-0.1.2-mdk
E poi puoi farti dire che fa quel pacchetto:
$ urpmq -i bho-0.1.2-mdk
Name        : bho
Version     : 0.1.2
Release     : mdk
Group       : uncertain
Size        : 123                       Architecture: i586
Summary     : The bho program.
Compilare dai sorgenti è OK, ma a quel punto userei sempre checkinstall, 
per assicurarmi di poter rimuovere facilmente il programma quando mi va, 
o quando ne viene rilasciata una nuova versione, per aggiornarla, o 
infine, per rintracciarlo nel caso mi fossi dimenticato di averlo 
installato.
In proposito credo siano interessanti queste pagine:
http://www.rpm.org/max-rpm-snapshot/index.html
http://mandrake.vmlinuz.ca/bin/view/Main/UsingUrpmi
http://qa.mandrakesoft.com/twiki/bin/view/Main/UrpmiResources
http://asic-linux.com.mx/~izto/checkinstall/docs.php
ciao
gerlos
-- 
  "Solo lo scienziato è vero poeta: ci dà la luna, ci promette le stelle,
   ci farà un nuovo universo se sarà il caso."
     _                                        Allen Ginsberg
    (y)
     =      gerlos  + - - - >  gnu/linux registred user #311588
            < 
http://gerlos.altervista.org
 >

 Slack non usa niente (o meglio niente di ufficiale).
obbella, e i vari pkgtools che sono? O_o
-- 
28/2/2005 | -1 all' alba!

 per ovviare a dipendenze e cose varie.
a parte gentoo (che ha un sistema di pacchettizzazione basato su sorgenti)
tutte le altre hanno problemi coi sorgenti
soluzione?
1) Usa gli rpm/deb/tgz (quelli della slack) e basta
2) Usa i sorgenti e basta
3) Litighi con un sistema misto
in effetti visto che usi una mandrake la cosa piu' facile e'
aggiungere quanti piu' repository (e possibilimente repository "pieni")
via urpmi.addmedia (fosse stata una debian t' avrei detto apt, yast per
suse, yum per la fedora, ecc) e, al limite cercare gli rpm/deb/quelchee'
in rete.



io ora uso slack ma per almeno 2-3 anni ho usato redhat prima e fedora poi
e non mai avuto *nessun* problema o conflitto con rpm e sorgenti..
quando digiti configure praticamente sempre puoi specificare la dir dove
andrà ciascuna cosa dai binari alle pagine di man.. quindi non vedo il
perchè di copiare i file a mano.. l'unica cosa negativa è che il database
di rpm non viene certo aggiornato.. e quindi spesso ti figureranno delle
dipendenze mancanti quando invece ce le hai.. ma il tutto si risolve con
un semplice e perfetto programmino: *checkinstall* che ti crea un rpm ad hoc
e poi lo installa risolvendo ogni possibile conflitto..
se poi il tuo problema sono le dipendenze ci sono tutte le rh based hanno
il loro programmino tutto fare che ti automatizza le cose.. yum, apt(per
rpm), yast, urpmi.. 
non capisco davvero il problema dove sia.. 
-- 
[Filippo...........................]
[Linux User #342745................]
        ==[...penguin powered...]==

 3) Litighi con un sistema misto
4) usi checkinstall


 wrote:
scusate per il quoting.. avevo intenzione di tagliare dopo finito di
scrivere ma mi sono dimenticato..

 obbella, e i vari pkgtools che sono? O_o
Ok, ci sono tool di gestione del software, quello che intendevo dire è 
che non usa un formato specifico di impacchettamento con informazioni 
aggiuntive.
Mi scuso con gli slackwaristi.


 posso dire) ti garantisce queste cose:
<cut>
Il sistema usato dalla Gentoo (portage) garantisce tutte le cose che hai 
detto, e inoltre ti permette di installare tutto da sorgente, con le 
ottimizzazioni che vuoi, e tutta una serie di altri vantaggi, compresa 
la facilità nel creare un "pacchetto" compilabile, installabile e quindi
disinstallabile anche di software non ancora compreso nella distro.
IMHO è un sistema nettamente superiore agli rpm, ai deb, ai pacchetti à 
la slack ecc. - avendo usato mandrake per anni, la slack per oltre un 
anno, e avendo a tutt'oggi una debian su un vecchio pentium 100 conosco
piuttosto bene tutti i vari sistemi. Al secondo posto metterei la 
gestione rpm di Mandrake (urpmi).
-- 
Taekyon

 4) usi checkinstall
sara' che sono io che non lo so usare, ma da me il caso 4 e' incluso nel
caso 3...


 aggiuntive.
no, no... c' e'!
e' il .tgz!!!
solo perche' non l' hanno rinominato .slack non significa che non ci sia!


 la slack ecc.
potrei anche essere daccordo con te, se non fosse che comunque compilare
ogni santissimo programma (vabe', ci sono i vari stage per iniziare, pero'
poi senza gcc non vai da nessuna parte) per un computer non proprio all'
ultimo grido non e' il massimo...


 detto, [cut]
Tolto gran parte del punto 2:
2. Rimuovere facilmente un programma che non ti serve più (farlo dai
sorgenti può essere parecchio seccante, a volte). Inoltre sei stai per
rimuovere (per recuperare di spazio sul disco, per esempio) una libreria
che che credi inutile, sei avvisato se c'è qualche programma che dipende
da essa.
vedi 
http://www.gentoo.org/doc/it/portage-manual.xml
:
[..]
Avvertenza: Fare unmerge sui pacchetti può essere pericoloso. Se
rimuovete i pacchetti base il vostro sistema può smettere di funzionare e
la rimozione di varie librerie può causare errori nel software. Il
Portage non vi avvisa se state rimuovendo pacchetti che fanno parte del
nucleo o dipendenze di altri pacchetti
Ricordare di usare l'opzione --pretend per vedere cosa succederà prima di
rimuovere qualcosa. Per maggiore sicurezza, emerge aspetterà un numero
specifico di secondi per dare all'utente il tempo di uscire. Durante
questo tempo di attesa l'utente può premere Control-C per fermare tutto
prima che unmerge inizi.
[..]

 caso 3...
sarò io fortunato.. ma davvero in 2 anni non ho mai avuto un problema.. e
usavo in ugual modo sorgenti, rpm singoli, rpm con yum prima, rpm con apt
poi.. 
cmq checkinstall non è mica difficile..
$ ./configure
$ make
# checkinstall
rispondi "si" a tutte le domande e R quando ti chiede che tipo di
pacchetto vuoi e il risultato sarà un rpm che potrai tranquillamente
disinstallare con rpm -e
che c'è di difficile?!?


 migliore per ovviare a dipendenze e cose varie.
un grosso vantaggio di debian e' che trovi moltissimo software, quindi
difficilmente devi installare qualcosa da sorgente. Puo' capitare per
qualche software "nuovo" ma quasi mai per le librerie, che sono le
piu' rognose. Inoltre sia con rpm sia con deb puoi farti abbastanza
facilmente i pacchetti dai sorgenti scaricati, in modo da farti il tuo
deb da installare e sapere sempre tutto dove e' messo e come.
.a.
-- 
Il mattino ha l'oro in bocca. Il MATTino ha l'OrO In bOcca.
i lma tt ino ha l'o roin bocc a.ilmattinohal'oroinbocca. il ma tt in
oh al' or oi nb oc ca. il matti noha l'oroinbocca. IL MATtiNO Ha l'ORO
InBOCCa. I l m a t t i n o  h a l' o r o i n b o c c a . ilmattinohal'oroin
BoCcA. iLmAtTiNoHaL'oRoInBoCcA.

 gerlos
grazie sei stato molto esauriente. 


> non capisco davvero il problema dove sia..
Non è tanto questione di "problema", che leggendo i vari post mi sono state
consigliate un casino di soluzioni, era più un dubbio che mi sorgeva, io ho
descritto un pò per esperienza personale come vedevo il mondo, poi qualcuno
mi ha detto che si poteva andare oltre le colonne d'ercole. :)


 che c'è di difficile?!?
...che a me
1) l' rpm non lo crea
2) comunque mi trovo i binari gia' sparsi per l' hd come se avessi fatto
un make install...


 Il sistema usato dalla Gentoo (portage) garantisce tutte le cose che hai 
[CUT]
non ho mai usato gentoo.. ma se portage assomiglia al sistema dei port di
freebsd e openbsd.. condivido pienamente che sia il miglior sistema di
gestione dei pacchetti! secondo me il miglior sistema di gestione di
pacchetti è quello basato sui sorgenti..e a questo si dovrebbe puntare per
la costruzione di un package manager standard di linux.. non a ventimila
sistemi diversi basati su binari incompatibili tra loro.. praticamente
ogni pacchetto si trova come tar.gz, questo è il vero standard dei
pacchetti linux.. quindi è questo che bisogna gestire nel migliore dei
modi! per quanto riguarda i computer lenti si potrebbe ovviare con un
sistema di base di pacchetti precompilati (come fanno i *bsd) da cui
partire per compilare ciò che si vuole aggiungere..



Li' si sta parlando dei pacchetti base. Nessuno sano di mente si metterebbe a 
fare "emerge -C python".
Per togliere cio' che non serve piu' basta dare "emerge depclean", in sicurezza. 


Quali informazioni aggiuntive si porterebbe dietro un tgz?
-- 
Enrico Bodo  -  Assistant Professor in Theoretical Chemistry 
University of Rome "La Sapienza" 
Department of Chemistry         

 un make install...
quando fai un make install i binari non vanno sparsi per l'hd ma in posti
ben precisi definiti nel momento in cui tu digiti configure..
se non ti va bene ci sono i vari --prefix=DIR che ti permettono di
controllare ogni singola cosa..
quello che conta e che con checkinstall il database rpm sarà aggiornato e
potrai fregartene di dove vanno a finire le cose perchè sarà scritto nel
database e ti basterà una query per saperlo.. e un rpm -e per
disinstallare.. esattamente come per gli rpm fatti da terzi che scarichi
su internet..


 migliore per ovviare a dipendenze e cose varie.
x me il sistema migliore è quello. tanto gli rpm vanno in /usr/lib/ o da 
qualche parte sempre nell albero /usr . invece nell albero /usr/local/ 
poniamo i pacchetti compilati. dimodochè se proprio non vuoi perdere i 
tuoi capolavori di compilazione in seguito a sputtanamento del sistema, 
puoi creare un altra partizione montata in /usr/local. tanto i pacchetti 
da compilare sono sempre i soliti, mentre gli altri rpm di sistema 
cambiano con l aggiornamento di mandrake.
un altro sistema è abbonarsi al mandrake club e usare solo pacchetti rpm 
  dei repository ufficiali. ma questa è una soluzione a pagamento e 
quindi mi sa che non fa parte del gioco ;)

ZeD ha scritto:

si non è il massimo aspettare secoli per compilare, però se ottimizzi un 
programma al 100% stai certo che  il pc non all ultimo grido ti 
ringrazierà sonoramente :)
.

 Quali informazioni aggiuntive si porterebbe dietro un tgz?
documentazione sul tipo di pacchetto, eventuali script da eseguire, e,
ovviamente, i file nelle rispettive locazioni.



Queste sono informazioni contenute nei file al suo interno. O sbaglio? Il
tgz di per se non ha nessuna informazione se non appunto i file+path.   


 tgz di per se non ha nessuna informazione se non appunto i file+path.
esatto
il sistema di pacchettizzazione della slack si basa su un insieme di
informazioni + file compressi in un file .tgz (in genere i sorgenti,
invece, sono distribuiti con l' estensione .tar.gz... e' pacifico,
comunque, che potevano usare un nome un po' diverso...)
