Gentoo: applicazioni, dubbi, filosofia

[bibo01]

Geniale ....
Io pero' mi sono stufato e anche pentito di aver condiviso.

La condivisione può continuare nell'altra discussione in rilievo ...e quella rimane

[marcoc1712]

Sono opzioni di GCC ma specificate dall'utente non tutte quelle che esistono e tutte previste nelle compilazioni generiche. C'è una bella differenza e la tipicita' di gentoo
non è di venire da pianeta Marte per avviarci alla " marzianita' " . E un sistema alternativo a tutti gli altri ma inserito nel contesto GNU per farlo funzionare col massimo della liberta'.
La tua posizione ideologica ti annebbia la vista . Nemmeno ti accorgi delle bordate che lanci . O forse te ne accorgi perfettamente e le lanci lo stesso.

Quali bordate?

IO dico semplicememente:

a. Solo le opzioni di compilazione (i.e. CFLAGS) influenzano la produzione dl codice binario a fronte di un dato sorgente.

b. gentoo non aggiunge opzioni di compilazioni proprie, sono le stesse di tutti i sistemi GNU.

c. le USE FLAGS non rientrano tra le opzioni di compilazione, quindi non possono influenzare il binario.

d. le USE FLAGS non possono modificare le dipendenze dinamiche, dichiarate nei sorgenti ma soddisfatte al runtime.

e. le USE FLAGS nulla aggiungono in termini di possibilità, rispetto di diverse versioni di codice a soddisfazione di dipendenze dinamiche. E' possibile solo se le due versioni sono compatibili rispetto a quanto stipulato nei sorgenti, come in qualsiasi altro sistema operativo.

f. le USE FLAGS dichiarano dipendenze DA e VERSO pacchetti, utilizzate in fase di installazione ed aggiornamento allo scopo di automatizzarne ed ottimizzarne la gestione.

Sono bordate? Non mi pare.

Tu (e forse Filippo) dici che almeno a, b e c NON sono vere perchè le USE FLAGS influenzao la compilazione.

Al che ti ho dimostrato, anche con esempio pratico, che così non è, ma è necessaria logica 'collante', scritta nell'ebuild.

Visto che non si discute di percezione, ma di tecnica ben documentata, o accetti la mia imostrazione o la confuti caltrettanto praticamente.

[marcoc1712]

Mi farebbe piacere, ma non ne sarei all'altezza. In questo campo c'è gente infinitamente più preparata di me. Sono stati scritti interi libri sull'argomento... http://en.wikipedia.org/wiki/Unix_philosophy


...e, tra tutti, c'era bisogno di fare tutto questo bordello? (tanto per restare in tema con il recente “Bottom”?)

Che vuoi che ti dica... in parte senza dubbio hai ragione: ovviamente non è solo per quello. Ma altrettanto indubbiamente è anche grazie a quello. Naturalmente non per le "USE" di per sé stesse, ma grazie ai meccanismi che queste innescano nei sistemi che gestiscono la compilazione (automatizzata) dei "pacchetti" che si vanno a compilare ed installare, incluse le eventuali patch (o quant'altro) che consentono a tali meccanismi di funzionare come previsto.

Che un sistema costruito interamente da zero includendo esclusivamente le opzioni e le librerie di cui si ha effettivamente bisogno, escludendo tutte le altre, alla fine risulti sensibilmente più "snello" e "leggero" di uno che, al contrario (per poter soddisfare qualsiasi possibile esigenza e necessità), non lascia fuori niente ed include ogni possibile opzione mi pare ovvio ed evidente.

Sono daccordo su QUASI tutto, se sostituiscii sostituire "innescano" con un "possono innescare" sottoscrivo pienamente, come se lo avessi scritto io, nel senso che non c'è NULLA di automatico, la logica di innesco è scritta caso per caso senza nessuna granzia di congruenza con quelle che sono le reali dipendenze dell'applicativo.

???

non ti seguo: come potrebbero non passare per la compilazione? A parte il caso di eventuali "plugin" attivabili o meno anche a runtime, è solo in quella fase che puoi decidere quali opzioni abilitare ovvero quali librerie (opzionali) includere o escludere...

Mi osno spiegato male, volevo dire che nella frase "gentoo risulta particolarmente ottimizzato grazie alla sua modalità di compilazione guidata dalle USE FLAGS" l'unico 'passaggio logico'
che non condivido è "modalità di compilazione guidata dalle USE FLAGS".

se invece di guidata da, metti un "e", svincolando le due cose, ancora una volta non avrei difficoltà a sottoscrivere.

dipende da che cosa si intende per “particolarità nella compilazione”. .

possibilità di infuire sul binario prodotto tramite strumenti diversi da quelli disponili con GCC su qualsiasi altro sistema GNU.

Non mi pare ce ne siano.

Per un singolo software non c'è molta differenza da ciò che puoi fare anche "a mano" su un qualsiasi altro sistema. Ma, in realtà, anche in questo caso, non del tutto: ci sono sempre le dipendenze e le eventuali dipendenze delle dipendenze, ecc, che agendo solo sul singolo software in oggetto restano fuori dal tuo controllo.

Se poi prendi in considerazione l'intero sistema, le differenze possono diventare enormi. Quale altro sistema ti consente di costruire sé stesso pezzo per pezzo, scegliendo con una simile granularità cosa includere e cosa no, quali opzioni ed ottimizzazioni utilizzare, ecc?

Evidentemente, una cosa del genere la puoi fare solo su un sistema che compili interamente tu, pezzo per pezzo, partendo da zero. Librerie e compilatori inclusi. Come per l'appunto Gentoo (oppure "LinuxFromScratch", che però è infinitamente più rozzo e scomodo... e devi fare praticamente tutto da solo, a mano).

Si, questo è il grande valore delle USE FLAGS e di portage, ne convengo. Facilitano e di molto un compito che altrimenti sarebbe immane.

Detto questo, le USE in se non bastano. Devi assicurarti che decsrivano correttamente le dipendenze presenti nel software, assemblando i pacchetti in modo da non introdurre inutili dipendenze artificiali. e questo richiede l'intervento dell'intelletto umano, supportato ma non sostituito da portage.

anche qui, dipende. Spesso proprio la gestione di simili dipendenze è lo scopo di alcune patch che vengono aggiunte e gestite attraverso le opzioni che puoi dare al sistema di "build" automatizzato di Gentoo...

Mi è chiaro, personalmente non mi piace e questo conta poco e non è certo un meccanismo 'proprio' solo di gentoo.

Nell'ottica di ' a mali estremi, estremi rimedi' ci sta, ma non stai 'gestendo le dipendenz con le USE': modifichi il sorgente prima di ircompilarlo, ... di fatto è come se qualcuno facesse una fork per gento e ti scaricassi e compilassi quella (cosa che farei io).

Potresti farlo anche indipendentemente dalla USE, non sempre 'dipendi' da lei strettamente: se non devii scaricare nulla ma solo togliere, ad esempio , la dipendenza da una libreria che sai che non ti serve perchè in gentoo non c'è? Perchè mettere la USE? fai la patch e basta.

Ciò a dire, che non c'è legame biunivoco tra le cose, sono collegate solo tramite una logica esterna ai due tools, GCC non sa che esistono le USE.

la distinzione è sottile, perché il "build" non lo fai direttamente tu: lo fai attraverso gli appositi strumenti forniti dal sistema, strumenti che nel farlo tengono conto di tutta una serie di impostazioni (tra i quali le "use", le istruzioni specifiche incluse nella ebuild, varie configurazioni globali a livello di sistema, ecc) che, tra le altre cose, controllano (automaticamente) anche le opzioni di compilazione...

Qui non siamo daccordo.

La build intesa come compilazione + link la fa il make, usando il makefile. L'unica cosa che viene presa in considerazione da GCC sono le ozpioni di compilazione, Tra cui NON ci sono le USE, gcc NON SA nemmeno cosa sono.

Perchè prenda in considerazione i concetti che le USE rappresentano (per chi crea il pacchetto, non in assoluto e nemmeno per chi ha scritto il codice, che nemmeno sa che verrà utilizzato su gento ed inserito in pacchetti, qui sta il punto), qualcosa (la ebuild) DEVE convertire le USE in CFLAGS o altro riconosciuto dal make.

L'esempio di squeezelite ti mostra come fare.

Il risultato finale del processo completo governato da portage PUO' portare a questo, ma che lo faccia o meno non dipende dalle USE in se, ma dal fatto che qualcuno abbia scritto gli ebuild 'orchestrando' bene i pacchetti in funzione delle dipendenze del codice.

Non so se è un bene o un male, ma non c'è automatismo, non discuto che tra la manina santa e portage il secondo sia preferibile.

E' chiaro il mio punto di vista?

[UnixMan]

E' poco? è tanto? non è questo il punto, il punto è che il vantaggio deriva dal fatto che compili i sorgenti per un uso specifico, non da una funzionalità esclusiva di gentoo.

ovvio.

La "funzionalità esclusiva di Gentoo" è casomai il modo in cui è stato architettato il sistema, l'insieme dei tools che consentono di gestire il tutto in maniera molto comoda (fatta salva la implicita scomodità di doversi compilare tutto...) ed efficacie, nonché -e soprattutto- il fatto che la cosa è applicata all'intero sistema, partendo da zero. Permettendo quindi di "tagliarsi su misura" ed "ottimizzare" non solo uno specifico programma, ma anche tutto ciò da cui questo eventualmente dipende, nonché l'intero sistema.

(per altro si tratta di una "funzionalità esclusiva" fino ad un certo punto, dato che Gentoo non è certo il solo sistema a poter essere costruito interamente a partire dai sorgenti e che il meccanismo dei "portage" è ispirato a quello dei "ports" di BSD).

Il vantaggio, quindi, è quello di installare da sorgente, così che tutto è allineato alle stesse opzioni. Personalmente, a pelle e senza averlo mai provato, sono poi convinto che il lavoro di portage con le USE FLAGS se ben orchestrato possa produrre ottimi vantaggi.

Esatto. Senza alcun dubbio.

Poi è chiaro che ogni strumento può essere utilizzato nbene o male, ma questo è completament eun'altro discorso.

ça va sans dire... :-)

[marcoc1712]

Chiarsisco il punto precedente con un esempio:

...
IUSE="aac dsd ffmpeg flac mad mpg123 resample visexport vorbis"
...


src_compile() {
    if use dsd; then
        append-cflags "-DDSD"
        einfo "dsd support enabled via dsd2pcm"
    fi

    # Build it
    emake || die "emake failed"
}

...

così l'ebuild informa il compilatore che se è presente la USE dsd, allora va aggiunto il CFLAG -DDSD, non è automatico e non è detto che questa sia la sola logica possibile, quindi è si possibile influenzare la compilazione con le USE FLAGS, a patto di farlo con portage all'interno della ebuild e di definirne la specific alogica al suo interno, caso per caso.

Diverso dal dire che le USE FLAGS influenzano la compilazione.

Se conveniamo anche su questo, siamo perfettamente allineati.