Gentoo: applicazioni, dubbi, filosofia

[marcoc1712]

no, sta semplicemente facendo il "build" dei relativi "pacchetti", per integrarli nel sistema.

Forse sbaglio io, ma normalmente la 'build' è intesa come insieme di compilazione e link guidata dal makefile, qui si tratta piuttosto di script di installazione di eseguibili prodotti altrove.

Forse solo a me, ma la cosa provoca confusione.

[antonellocaroli]

Forse sbaglio io, ma normalmente la 'build' è intesa come insieme di compilazione e link guidata dal makefile, qui si tratta piuttosto di script di installazione di eseguibili prodotti altrove.

Forse solo a me, ma la cosa provoca confusione.

Ti devi lamentare con chi mantiene gentoo...perché funziona cosi.

emerge ha bisogno di un file .ebuild

tutte le ebuild che lavorano un binario hanno sempre un nome-bin , bin sta per binary.
infatti mi é sembrata strana anche la tua domanda precedente.

un esempio questo é un overlay dove ci sono le ebuild di LMS binario

https://gpo.zugaina.org/media-sound/...ediaserver-bin
media-sound/logitechmediaserver-bin
e si chiamano logitechmediaserver-bin-9999.ebuild

e questo per i sorgenti
https://gpo.zugaina.org/media-sound/logitechmediaserver

[UnixMan]

Forse sbaglio io, ma normalmente la 'build' è intesa come insieme di compilazione e link guidata dal makefile, qui si tratta piuttosto di script di installazione di eseguibili prodotti altrove.

Forse solo a me, ma la cosa provoca confusione.

that's the way it is... :-)

Nel gergo comune, la creazione di un "pacchetto" per una distribuzione binaria (o l'equivalente operazione di integrazione di un software in Gentoo) si chiama comunque "build".

Questo sia perché di solito (cioè, quando è possibile) si parte dai sorgenti originali del sw, unitamente ai "sorgenti del pacchetto" (gli ebuild ed i relativi files accessori nel caso di Gentoo), per cui il "build" dei binari a partire dai sorgenti è parte integrante del più ampio processo di "build" del "pacchetto" (l'installazione di software precompilato costituisce una eccezione, non la regola), sia (soprattutto) perché si tratta comunque di un processo di "costruzione" di una nuova "unità software" a partire da diversi componenti di partenza (quindi di un processo per molti versi analogo a quello della "costruzione" di un binario a partire dai suoi sorgenti).

Spesso anche gli strumenti utilizzati sono (almeno in parte) gli stessi (in molti casi per costruire i "pacchetti" si usa proprio "make", oppure altri strumenti dedicati ma per molti versi analoghi a quello).

BTW: temo che la tua "confusione" - e molte delle incomprensioni che ci sono state - nascano fondamentalmente da una scarsa comprensione della "filosofia" dei sistemi Linux, nonché dei concetti di base dell'organizzazione, della gestione e dell'integrazione del software in tali sistemi. Che è profondamente e sostanzialmente diversa da quanto accade per altri.

Forse la difficoltà di comprensione origina dal tuo punto di vista, dal modo in cui “guardi” le cose. Se intuisco correttamente, tu vedi "il sistema" e "gli applicativi" come due entità distinte, sostanzialmente diverse e separate tra loro.

Al contrario, alla base della filosofia, dell'idea stessa dei sistemi Unix - ed ancora di più nel caso di quelli GNU/Linux - c'è invece il concetto di "integrazione". In un sistema Linux un applicativo non è visto come qualcosa di diverso e distinto dal sistema stesso, ma piuttosto come una sua parte. Magari opzionale, ma integrata ed integrante.

Quindi un qualsiasi applicativo che si vuole "aggiungere" al sistema è un qualcosa che (a prescindere dalla sua "origine") deve essere integrato, "standardizzato" e reso quanto più possibile affine ed "indistinguibile" da tutti gli altri elementi del sistema.

Lo scopo di un "pacchetto" (o di un "ebuild") non è banalmente solo quello di "installare sul sistema" un dato software (così come è stato pensato dai suoi sviluppatori), ma piuttosto quello (molto più ampio ed "invasivo") di cercare di integrare quanto più possibile quel software nel sistema.

Va da sé che la cosa fa letteralmente a cazzotti con la tua idea di software applicativo indipendente ed autoconsistente, "chiuso in sé stesso", agnostico rispetto al sistema. In effetti, per molti versi ne è l'esatto contrario.

Nel mondo Unix/Linux la "portabilità" è vista soprattutto a livello dell'intero sistema (con tutti i suoi applicativi) rispetto a piattaforme (hardware) differenti, non di singole applicazioni tra "mondi" differenti. L'idea stessa di software autocontenuto, autoconsistente ed "indipendente dalla piattaforma" (laddove per "piattaforma" si intenda anche il SO) è sostanzialmente antitetica con la filosofia di base dei sistemi Unix. Che al contrario si basa soprattutto sull'idea di avere una collezione di software semplici, leggeri, altamente specializzati e fortemente integrati tra loro che formano e costituiscono il sistema stesso. Ciascuno pensato per svolgere al meglio un unico semplice compito, mentre la realizzazione di funzioni più complesse è affidata alla combinazione (spesso decisa dall'utente stesso) di software diversi ed indipendenti che interagiscono tra di loro.

Volendo fare una analogia politico/sociologica, al contrario di altri sistemi che sono basati su modelli sostanzialmente "individualistici" (e.g. windows, MacOS), un sistema Unix/Linux è un sistema basato su un modello di tipo intrinsecamente, fondamentalmente e radicalmente "collettivista" e "cooperativista". :-)

Anche l'idea alla base dei sistemi di gestione del software con i "pacchetti" (o gli ebuild in Gentoo) si basa su questa stessa filosofia e su questa idea di sistema totalmente integrato e standardizzato (e quindi per certi versi anche "centralizzato", dove al centro di tutto c'è il sistema stesso visto come un tutto unico e sinergico, non come un semplice "supporto" di base su cui poggiare più o meno alla rinfusa elementi esterni indipendenti tra loro).

Hope it helps...

[marcoc1712]

that's the way it is... :-)

Nel gergo comune, la creazione di un "pacchetto" per una distribuzione binaria (o l'equivalente operazione di integrazione di un software in Gentoo) si chiama comunque "build".

Questo sia perché di solito (cioè, quando è possibile) si parte dai sorgenti originali del sw, unitamente ai "sorgenti del pacchetto" (gli ebuild ed i relativi files accessori nel caso di Gentoo), per cui il "build" dei binari a partire dai sorgenti è parte integrante del più ampio processo di "build" del "pacchetto" (l'installazione di software precompilato costituisce una eccezione, non la regola), sia (soprattutto) perché si tratta comunque di un processo di "costruzione" di una nuova "unità software" a partire da diversi componenti di partenza (quindi di un processo per molti versi analogo a quello della "costruzione" di un binario a partire dai suoi sorgenti).

Spesso anche gli strumenti utilizzati sono (almeno in parte) gli stessi (in molti casi per costruire i "pacchetti" si usa proprio "make", oppure altri strumenti dedicati ma per molti versi analoghi a quello).

BTW: temo che la tua "confusione" - e molte delle incomprensioni che ci sono state - nascano fondamentalmente da una scarsa comprensione della "filosofia" dei sistemi Linux, nonché dei concetti di base dell'organizzazione, della gestione e dell'integrazione del software in tali sistemi. Che è profondamente e sostanzialmente diversa da quanto accade per altri.

Forse la difficoltà di comprensione origina dal tuo punto di vista, dal modo in cui “guardi” le cose. Se intuisco correttamente, tu vedi "il sistema" e "gli applicativi" come due entità distinte, sostanzialmente diverse e separate tra loro.

Al contrario, alla base della filosofia, dell'idea stessa dei sistemi Unix - ed ancora di più nel caso di quelli GNU/Linux - c'è invece il concetto di "integrazione". In un sistema Linux un applicativo non è visto come qualcosa di diverso e distinto dal sistema stesso, ma piuttosto come una sua parte. Magari opzionale, ma integrata ed integrante.

Quindi un qualsiasi applicativo che si vuole "aggiungere" al sistema è un qualcosa che (a prescindere dalla sua "origine") deve essere integrato, "standardizzato" e reso quanto più possibile affine ed "indistinguibile" da tutti gli altri elementi del sistema.

Lo scopo di un "pacchetto" (o di un "ebuild") non è banalmente solo quello di "installare sul sistema" un dato software (così come è stato pensato dai suoi sviluppatori), ma piuttosto quello (molto più ampio ed "invasivo") di cercare di integrare quanto più possibile quel software nel sistema.

Va da sé che la cosa fa letteralmente a cazzotti con la tua idea di software applicativo indipendente ed autoconsistente, "chiuso in sé stesso", agnostico rispetto al sistema. In effetti, per molti versi ne è l'esatto contrario.

Nel mondo Unix/Linux la "portabilità" è vista soprattutto a livello dell'intero sistema (con tutti i suoi applicativi) rispetto a piattaforme (hardware) differenti, non di singole applicazioni tra "mondi" differenti. L'idea stessa di software autocontenuto, autoconsistente ed "indipendente dalla piattaforma" (laddove per "piattaforma" si intenda anche il SO) è sostanzialmente antitetica con la filosofia di base dei sistemi Unix. Che al contrario si basa soprattutto sull'idea di avere una collezione di software semplici, leggeri, altamente specializzati e fortemente integrati tra loro che formano e costituiscono il sistema stesso. Ciascuno pensato per svolgere al meglio un unico semplice compito, mentre la realizzazione di funzioni più complesse è affidata alla combinazione (spesso decisa dall'utente stesso) di software diversi ed indipendenti che interagiscono tra di loro.

Volendo fare una analogia politico/sociologica, al contrario di altri sistemi che sono basati su modelli sostanzialmente "individualistici" (e.g. windows, MacOS), un sistema Unix/Linux è un sistema basato su un modello di tipo intrinsecamente, fondamentalmente e radicalmente "collettivista" e "cooperativista". :-)

Anche l'idea alla base dei sistemi di gestione del software con i "pacchetti" (o gli ebuild in Gentoo) si basa su questa stessa filosofia e su questa idea di sistema totalmente integrato e standardizzato (e quindi per certi versi anche "centralizzato", dove al centro di tutto c'è il sistema stesso visto come un tutto unico e sinergico, non come un semplice "supporto" di base su cui poggiare più o meno alla rinfusa elementi esterni indipendenti tra loro).

Hope it helps...

Avevo risposto in modo molto più articolato, ma ho perso tutto...

Riassumo:

0. Il codice viene - normalmente - scritto affinchè possa avere la massima diffusione possibile. Tutte le evoluzioni tecnologiche degli ultimi 70 (settanta) anni vanno in questo senso.

Fino a qui, individualisti, anarchici, collettivisti o sovietici hanno poco da fare... Il codice è scritto NECESSARIAMENTE nel modo più agnostico posibile rispetto alla particolarità di OS e HW.

1. Parlando di codice scritto in C, per semplicità, l'unica istruzione in grado di produrre binari diversificati in funzione della piattaforma è CFLAG (o CXXFLAG se C++) e questo si applica in fase di LINK del MAKE. (build).

stessi CFLAG su sistemi diversi producono uguale eseguibile, diversi CFLAG su stesso sistema producono eseguibili diversi.

sui sistemi GNU, la compilazione (gcc o cc o c o ...) ed il link vengono getsiti dal makefile, invocato dal comando make. in MSVS si usano strimemnti diversi, ma con analogo risultato.

NULLA dopo il make può cambiare le istruzioni che vengono eseguite, compree le iUSE di Gentoo, che sono sonlo una DICHIARAZIONE di dipendenze tra pacchetti, ma in nessun modo possono contrastare le dipendenze DA CODICE.

Quello che puoi cambiare sono la presenza o meno di librerie o componenti nel sistema (non il fatto che le usi, solo che siano necessariamente pesenti) il che IN ALCUN MODO può influenzare il funzionamento dell'applicazione in se, piuttosto, questo si, è il sistema che cambia, ma non in ragione dellle dipendenze (se corrette) di un applicativo.

Puoi fare danni, ma non migliorarlo.

2. Io sono individualista ed anarchico, quindi standardizzazione, centralizzazione, cooperzione e collettivismo sono concetti che rifuggo in generale, nella realizzazine di codice applicativo appartengono all'età dei dinosauri, ormai completamente sostituiti al concetto di integrazione debole o addirittura inversione di controllo, che 'liberano' il programmatore ai vincoli dettati dalle altre applicazioni, se non in ragione di 'contratti' precisi in merito ai servizi mutualmente utilizzati.

In che modo, a titolo di esempio MySQL, è più integrato in Linux che non in Win o altrove?

3. Quello in cui Linux è diverso da Win è "l'orchestrazione" del middleware, cioè di quello strato di software costituito da installers, gestore di pacchetti,... che conducono a che l'insieme del software ESEGUIBILE A,B e C funzioni nel più efficient emodo possibile.

Ma si tratta di tools. Comunque tu arrivi alla configurazione finale, quella è, sia con ebuild, che manualmente, se repplichi esattamente gli stessi passi. Non che lo consigli, anzi, una efficiente gestione dei pacchetti è un plus notevole a mio avviso, soprattutto per la manutenzione, ma NON AGGIUNG ENULLA (per fortuna) a quanto stabilito nell apartitura (il sorgente).

4. Il fatto che Linux possa comprendere la build nel corso dell'installazione del pacchetto e che gentoo chiami ebuild lo strumento contribuiscono ad aumentare la confusione, rimangono comunque fasi distinte con significati e portata del tutto diversa.

Non sono incomprensioni (al netto dei termini), sono punti di vista radicalmente diversi. Io credo che una buona applicazione NON debba sapere su che sistema giri, così da poterlo fare su tutti, tu che debba essere realizzata in modo da 'integrarsi al meglio' nel sistema di destinazione.

Al netto delle idee, però, i fatti sono concreti: Solo i CFLAGS possono cambiare l'eseguibile prodotto dalla BUILD, nulla di quanto viene dopo, quindi parlare di 'integrazione' prodotta dall'ebuild (a parità di CFLAGS) è quantomeno imporprio.

Per favore evitiamo di prolungare la polemica sulle idee, se ci sono errori in quello che ho scritto, perchè le cose non stanno così, allora correggetemi pure, portando però casi pratici concreti. Parliamo di squeezelite?

[bigtube]

Avevo risposto in modo molto più articolato, ma ho perso tutto...
.................................................................................................... ..............................................
Riassumo:

Parliamo di squeezelite?

Marco
dal basso di mero utente di Sistemi Operativi e di Programmi faccio delle osservazioni.
- i Programmi o Applicazioni sono scritti per essere usati. Per usarli ci vogliono i sistemi operativi nei quali si devono integrare
Un bel programma scritto benissimo inserito in un S.O. osserviamo comunemente tutti i giorni che lavora bene o molto bene....in altri S.O. meno bene....in altri ancora in modo eccellente.
Se tu mi chiedessi di usare per es. Windows io ti rispondo .... "Mai" o una volta che riscontrassi che va' molto bene...."Ok lo uso ma solo se mi soddisfa per quel programma specifico".
Per quello che serve a me Win non mi interessa quotidianamente.
Ora se dopo tante esperienze con sistemi operativi utilizzati per l'ascolto di musica GLI STESSI PROGRAMMI CHE PIACCIONO A ME....e tu sai quali sono molto bene,
fatti girare su Gentoo fanno letteralmente il salto nell'eccellenza, secondo me dimostra quanto segue :
un bel programma ben articolato nel suo funzionamento per dare il meglio deve integrarsi in un sistema che glielo permette.
Mi pare del tutto utopistico che tu pensi di isolare l'applicativo dai sistemi che lo devono gestire.
Puo essere che in futuro ci arriveremo ma ora nel mondo reale le cose vanno cosi.
Ancora stiamo nel software proprietario e open source e le distorsioni del software propietario sono sotto gli occhi di tutti.