Newsgroup: it.comp.os.linux.iniziare
Titolo: Precompilati, sorgenti, gestione pacchetti...chiarimenti.

Salve a tutti.
Vorrei fare quattro chiacchere con voi, sperando di togliermi alcuni
dubbi in merito al mantenimento di un sistema linux.
Premetto che anche se da circa un anno ho installato fedora, sono
ancora un niubbo a causa dell'utilizzo limitato.
Per prima cosa, avendo letto qua e la in merito, mi chiedevo quale
fosse effettivamente la differeza tra le diverse modalità di
installazione del software sotto linux.
In particolare ho letto che l'installazione da sorgenti rende il
software installato maggiormente efficiente e performante.
Il mio dubbio è il seguente:
Se un utente alle prime armi o quasi installa software da sorgenti, ci
possono essere veramente dei vantaggi?
Mi spiego meglio:
Il trittico usuale ("./configure", "make", "make install o meglio
checkinstall"), può rende effettivamente più prestante il software
installato?
Chiedo questo perchè mi viene il dubbio che la reale maggiore
efficienza di software installato da sorgenti stia nella possibilità
di aggiungere opzioni al comando ./configure. Se così fosse (e a voi
chiedo conferma), un niubbo farebbe fatica a rendere queste migliori
prestazioni del software effettive....
Per il momento mi fermo qua, sperando che a qualcuno vada di parlarne.
Arrisentirci

 possono essere veramente dei vantaggi?
oltre ad imparare meglio come funziona, puoi eventualmente cambiare
delle impostazioni che non ti servono nel configure ... cosa che nei pkg
di solito non e' consentito ... es: il MALEDETTO supporto MySQL che non
mi serve e ci sta SEMPRE di default ;-)))
ciao ...
-- 
#include <stdio.h>
int main(void){char c[]={10,65,110,116,111,110,105,111,32,98,97,114,98,111,110,
101,32,60,104,105,110,100,101,109,105,116,64,116,105,115,99,97,108,105,110,101,
116,46,105,116,62,10,10,0};printf("%s",c);return 0;}

 installato?
Se non vengono fatte ottimizzazioni, no. Normalmente l'utente alle
prime armi non ne fa.
Se lanci il "trittico" con le opzioni di default e senza cambiare flag
al compilatore ottieni pari-pari il binario che puoi scaricare
precompilato per la tua distro.

precompilato per la tua distro.
Ma scusa la distro non e' detto che lasci al default le
opzioni, un po' possono essere gia' piu' adattate, oppure mi
sbaglio io a pensare questo?
-- 
Saluti, Dalet

 sbaglio io a pensare questo?
Bisogna vedere l'esempio concreto.
In generale però è difficile che cambiando le opzioni di configure tu
ottenga ottimizzazioni prestazionali, quasi sempre si tratta di
aggiungere o togliere una feature.

 precompilato per la tua distro.
Ok.
Era quello che mi interessava... nella mia ignoranza pensavo che
lanciando il ./configure semplicemente, il pacchetto si "preparasse"
al meglio per l'installazione sulla macchina e SO corrente, dando
luogo, in seguito ad un'installazione ottimale. Invece così non è, a
quanto pare. Quindi, per una persona che è alle prime armi e di suo
non sà propriamente ciò che sta facendo è decisamente meglio il
precompilato, direi (certo se non si vuole restare niubbi per
sempre....bisognerà anche sperimentare un po'...).
Anzi da quello che dite potrebbe essere che in alcuni casi, cioè per
alcuni pacchetti, i precompilati della propria distribuzione siano
stati già migliorati da mani decisamente più esperte del sottoscritto.
Spero di aver capito bene.
Chiarito questo, può capitare a volte che l'accoppiata precompilato +
gestore di pacchetti (yum, apt, yast....), non ci consenta di
installare un determinato pacchetto: come comportarsi?
Chiaramente questa domanda sottintende una risposta un po' meno
generale della precedente, nel senso che ci si comporterà in modo
diverso, presumo, a seconda della distribuzione installata...
Mi spiego:
sul mio pc è installata fedora che utilizza yum e pacchetti rpm.
Mettiamo che un pacchetto non sia presente nei repositori...mi direte:
"aggiungi o aggiorna i repositori...", ma mettiamo che il pacchetto
che voglio installare non sia presente nei repositori.
Io faccio così (a dire il vero l'ho fatto assai di rado.):
1- cerco l'rpm oppure lo creo con checkinstall dai sorgenti (./
configure, make, checkinstall...)
2- in entrambi i casi vado nella cartella dove è presente l'rpm e do
"yum locallinstall [nome_pacchetto]"
Penso che qualcosa di analogo sia possibile anche con altre
distribuzioni che utilizzano diversa pacchettizzazione e gestione.
Che cosa ne pensate? E' una scelta giusta?
Qualche volta ho fatto così, per lasciare che yum risolva le
dipendenze automaticamente, cosa che non riuscirei a fare con il
comando rpm -ivh ....
Anche se a dire la verità, non ho ancora capito se poi l'rmp e tutta
la directory dove l'avevo scaricato/creato posso eliminarla
impunemente oppure, dopo, al momento dell'eventuale disinstallazione
avrei dei problemi utilizzando yum....

 Bisogna vedere l'esempio concreto.
Le opzioni contenute in /usr/lib/rpm/i686-linux/macros sono usate per
compilare i pacchetti con rpm per Fedora su piattaforma i686 (sono usate
di default per athlon oltre che per pentium4, core duo e compagnia):
optflags: -O2 -g -march=i686
Un rpm č piů ottimizzato di ./configure && make && make install.
Debian piů spesso utilizza -O3 e anche ubuntu (non ricordo se le opzioni
sono in debian/control o debian/rules).
-march implica un sacco di opzioni. Tra i386 e i686 ci sono veramente
molte differenze (tipo -mmmx -msse ...), ./configure && make crea binari
ottimizzati per i386, salvo diverse indicazioni.
Questo dell'ottimizzazione č un altro dei motivi per cui creare
pacchetti destinati alla distribuzione con checkinstall (oltre al
problema delle dipendenze) č una bella minchiata.
Ciao, ClaudioT.

 optflags: -O2 -g -march=i686
No, correggo. Non ci sono pacchetti ottimizzati per athlon nè in Fedora,
nè in Debian/Ubuntu. Tutti i pacchetti sono ottimizzati per i686 (che è
una buona ottimizzazione anche per athlon). Se si compila localmente un
rpm con --target=athlon viene usato il flag -march=athlon che porta con
sè maggiori ottimizzazioni per quel processore.
Tempo fa avevo provato a compilare una gentoo con flag da *autentico*
coglione (-mtune=athlon-xp che rompe la compatibilità con altri
processori, -ffast-math che arrotonda senza controlli ...) e il
sistema che avevo ottenuto non era poi più veloce di Fedora. In compenso
le tribolazioni con un portage tree eternamente inconsistente mi
hanno fatto cambiare strada (e Eric Raymond si lamenta di Fedora...)