ma i source che compili, di un programma qualsiasi, non conflittano in qualche modo con i pacchetti già installati?
Può succedere in Debian, ma in Slackware, a meno che non si tratti di dipendenze davvero importanti (SDL, GTK e altre) di solito se compili e installi, sovrascrivendole semplicemente è come fare un upgrade, e non hai alcuna ripercussione sul sistema.
ti giri tutti i siti o ne esiste uno dove sono disponibili tutti i source?
Nei siti della Slack c'è poco o niente. Io giro finchè non trovo la dipendenza che mi serve, ma se ho fortuna gli errori in configure mi dicono già dove andare a prendere i pacchetti.
Se ad esempio nella "repo" di Slack scrivo "speex" o "twolame" (due codec per MPlayer) non trovo risultati. Scommetto che in Debian esistono, ma Debian non è affar mio.
Perchè, ti spiego, a me che arrivo da Ubuntu la compilazione è sempre sembrato qualcosa sporca come cosa, mi è sempre sembrata una cosa che lasciava tracce qua e la e mal si integrava con gli aggiornamenti di sistema e della Distro...
Eh... qua si potrebbe aprire un dibattito infinito...
Ogni pacchetto, prima di essere reso disponibile, viene compilato "genericamente" per un tipo di macchina. Il problema è che il "tipo" di macchina può essere leggermente diverso da un "tipo" di macchina simile, ma non
uguale... la compilazione serve anche ad evitare che si abbiano errori di esecuzione o di memoria. Io scommetto quello che vuoi che se ci si compilasse tutti i programmi per Windows si darebbe una segata almeno al 35% dei problemi legati alla memoria o alle relativamente scarse prestazioni. O ai conflitti tra applicazioni, hardware e API.
Installare da sorgenti e installare da pacchetti è la stessa cosa. Dipende solo da come installi. In Debian hai un migliaio di tool che fanno la guardia sul sistema, in Slackware sei praticamente da solo, e il 100% del sistema (meno, dai... facciamo il 95%) è sotto la tua diretta responsabilità.
Di solito ci sono tutti i documenti e i testi per imparare che cosa fare per aggiornare un determinato software o libreria. Di solito, anche, l'utente non ha voglia di leggerseli, e la probabilità di sovrascrivere roba con effetti catastrofici -o quasi- è piuttosto alta.
Un esempio classico è SDL.
http://en.wikipedia.org/wiki/Simple_DirectMedia_LayerTante volte mi era capitato di dover reinstallare SDL per problemi di incompatibilità con alcune applicazioni. Qui il cross-compiling viene in grande aiuto. SDL è una libreria di sistema medio-base. Diciamo che se non hai SDL non ti gira qualcosa come il 50% delle applicazioni per X. SDL è due passi sopra il kernel, sopra framebuffer e Xlib, e quest'ultimo è indispensabile per far girare X. Se ci giochicchi troppo sono c@@@i. Sul serio.
Per questo le alternative sono due. O aggiorni la distro intera (e vai di formattone) oppure crei una directory apposta e poi, in fase di configurazione dell'applicazione, punti la directory delle SDL nella cartella dei sorgenti che hai appena compilato. Però per fare questo non bisogna installare le librerie. Anzi, questo è un cross-compiling "temporaneo" perchè le librerie non escono dalla cartella dei sorgenti. Se installi in una directory diversa del sistema (mettiamo, /usr/local/lib/SDL1.2.13 mentre hai le SDL 1.2.10 di default nel sistema in /usr/lib) allora è vero cross-compiling. (Non sarebbe tanto "vero", perchè un cross compiler è un'altra cosa. Però credo che sia lecito chiamare quest'azione "cross-compiling", perchè il fine è comunque "creare più piattaforme diverse sullo stesso sistema".) E' un metodo come un altro per salvaguardare l'integrità e la purezza del sistema pur avendo applicazioni e librerie aggiornate.
Per questo una compilazione non è mai "sporca". Dipende da come viene fatta.
