Gentoo + Squeezelite-R2

[antonellocaroli]

Su questo io non entro, ma se è così è il caso di avere ffmpeg (e tanto altro) nelle global use flags? Non è meglio tenere snello e , solo se serve, chidere lo specifico pacchetto?

Ho cercato di spiegarlo diverse volte...anche in queso post...la parte riguardante mpd

http://www.nexthardware.com/forum/pc...tml#post964417

Le USE messe nella guida sono generiche e non pensate per un singolo software...
e li che sta la personalizzazione....si possono cambiare in base alle propie esigenze...anche al momento dell´installazione del singolo pacchetto

[marcoc1712]

PS la legge dal fatto che nelle use flags hai ffmeg e non hai dsd, lirc ecc

Cosa intendi?

Nelle USE FLAGS 'generali' (quelle in make.conf, per itenderci) ho quelle che hai consigliato in installazione, compreso ffmpeg.

Fino a che non ho richiesto l'emerge con squeezelite con -ffmpeg nelle use, non ha mai chiesto di installare ffmpeg.

dsd non ha dipendenze, quindi non installerà mai nulla, lirc è una use solo locale a squeezelite-R2, ovviamnete è solo facendo l'emerge di squeezelite-R2 che mi aspetto installi dsd e lirc, ma se metto -dsd e -lirc, mi aspetto NON richieda di installarle, come in effetti fa.

mi aspetterei lo stesso anche per ffmpeg, invece lo installa anche se è -ffmpeg.

Pare esserci quindi una asimmetria: se la USE è solo locale, con -xxx non la installa, se è generale, invece, la installa comunque, anche se è rierita SOLO come -.

Se è così, ha senso metterlo negli USE FLAG 'generali'?

Ovvio che io parto dal punto di vista di un sistema che ha solo squeezelite, quindi probabilmente va tolto, così da installarlo SOLO se richiesto espliicitamente.

[marcoc1712]

Ho cercato di spiegarlo diverse volte...anche in queso post...la parte riguardante mpd

http://www.nexthardware.com/forum/pc...tml#post964417

Le USE messe nella guida sono generiche e non pensate per un singolo software...
e li che sta la personalizzazione....si possono cambiare in base alle propie esigenze...anche al momento dell´installazione del singolo pacchetto

Si, daccordo su questo, ma mi stupisce il fatto che -ffmpeg NELLE IUSE del pacchetto provochi l'installazione, dato che non c'è nessuna differenza pratica rispetto a non mettere proprio ffmpeg, nesusno la usava prima, nessuno continua ad usarla dopo, perchè vienne installata adesso?

Non lo sapevo e mi sembra abbastanza sciocco, tutto qui.

Nella fattispecie, come consiglio a chi vuole usare solo squeezelite con C-3PO, lo toglierei.

[antonellocaroli]

dsd non ha dipendenze, quindi non installerà mai nulla, lirc è una use solo locale a squeezelite-R2, ovviamnete è solo facendo l'emerge di squeezelite-R2 che mi aspetto installi dsd e lirc, ma se metto -dsd e -lirc, mi aspetto NON richieda di installarle, come in effetti fa.



Pare esserci quindi una asimmetria: se la USE è solo locale, con -xxx non la installa, se è generale, invece, la installa comunque, anche se è rierita SOLO come -.

Se è così, ha senso metterlo negli USE FLAG 'generali'?

Prova a mettere dsd nelle USE flags (nel make.conf) e prova a reinstallare squeezelite....

Ovvio che io parto dal punto di vista di un sistema che ha solo squeezelite, quindi probabilmente va tolto, così da installarlo SOLO se richiesto espliicitamente.

Ovvio che va tolto se non ti interessa, e non c é bisogno del - nella ebuild....

Ho sempre cercato di dire che vanno tolte dalle USE flags cose che non interessano.

[UnixMan]

Sto ascoltando.

facci sapere le tue impressioni...

[...] hanno prodotto CFLAGS diversi per il make, il che ha 'attivato' la patch (comunque applicata, nei due casi) , tagliando via tutto il contenuto del file flac.c e la dichiarazione stessa del suo utilizzo da decode.c, producendo un binario diverso nei due casi:
Hai prodotto una nuova versione di Squeezelite che non sa dell'esistenza del codec flac.

...che è esattamente lo scopo che si prefiggeva chi ha scritto originariamente la ebuild (e le relative patch).

Ma dov'è il vantaggio, dato che si tratta di librerie dinamiche?

che elimini una dipendenza e puoi evitare di installarla, se non ti serve...

(il fatto che in questo caso ci sia già è irrilevante: potrei non aver installato precedentemente MPD e quindi neanche flac, oppure potrei decidere di disinstallarlo a posteriori, e con quello eliminare anche flac).

[...] non cambia assolutamemte NULLA a runtime, tranne aver creato le condizioni per un poissbile errore. non gestito.

questo sarebbe un errore nelle patch... che avrebbero dovuto eliminare ogni riferimento a flac, prevenendo qualsiasi possibilità di errore.

BTW: se quel che dici è corretto, il modo in cui gestite le librerie dinamiche in SL è “insolito”. In genere gli "Shared Object" delle librerie non vengono gestiti come se fossero dei "plugin"... al contrario, vengono sempre "linkati" dal dynamic linker all'avvio. Se uno o più .so mancano, si ha un errore ed il programma non viene avviato.

Se metti -flac nelle use, emerge non prova ad installare il pacchetto flac, ci sia o meno già nel sistema, OK?
[...]
Dato che la patch ha messo delle condizioni in decode.c ed in flac.c IN FUNZIONE del valore di "-DSL_NO_FLAC, il risultato sarà un binario che NON SA che esista flac, quindi non ci può fare nulla, anche se il pacchetto flac è installato nel sistema.

esatto. Che è esattamente ciò che si vuole che sia.

Se il pacchetto 'A' non elenca il pacchetto 'B' come sua dipendenza, ci si aspetta che 'A' non abbia nulla a che fare con 'B' (e che quindi 'A' non cerchi 'B' e non provi ad utilizzarlo, neanche se c'è).

Al contrario, se 'A' usa 'B', anche solo opzionalmente, normalmente 'B' deve in qualche modo comparire tra le dipendenze (eventualmente "opzionali") di 'A'.

Per gestire le "dipendenze opzionali", in Debian esistono delle forme di dipendenza "più deboli": i "recommend" ed i "suggests". I primi sono dipendenze "non strettamente essenziali" (cioè, il software può funzionare anche senza), ma senza le quali si perdono delle funzionalità più o meno importanti. I secondi invece sono possibili "complementi" del tutto facoltativi (non necessariamente utilizzati direttamente da 'A'). Sono appunto niente altro che suggerimenti: “guarda che se installi 'A', forse potrebbe farti comodo anche 'B'”).

Non so se/come siano gestite/gestibili cose analoghe in Gentoo...

[marcoc1712]

Non so a che servono quei - che hai messo nella ebuild....

ma gentoo/portage ragiona sul sistema no sul singolo software...

se imposti le USE Flags in make.conf in un certo modo...va avanti cosi....quindi tutto quello che non vuoi nel tuo sistema lo devi togliere/o non lo devi mettere dalle/nelle USE Flags nel make.conf

https://gentoo-handbook.lugons.org/d...?part=2&chap=2

No, qui ti sbagli.

dal testo da te citato:

Ci sono due tipi di flag USE: globali e locali.

• Una flag USE globale è usata da alcuni pacchetti a livello di sistema. Questo è ciò che molti utenti vedono come flag USE.
• Una flag USE locale è usata da un singolo pacchetto per prendere decisioni specifiche sul pacchetto stesso.

In latre parole, il iistema ragiona sul singolo pacchetto, che EREDITA (cioè usa anche) quanto scritto a livello superiore
.
Perchè credi che funzioni la "if use dsd then..." quando dsd NON è una USE generale? Perchè è una use locale in quell'ebuild specifico.
v. https://devmanual.gentoo.org/quickstart/

Da qualche parte avevo letto di mettere le USE a livello generale SOLO se usate, come opzione, da 5 pacchetti o più.

Non mettere o togliere nelle/dalle USE in make.conf non è, quindi, un modo per eliminare o 'proibire' ovunque.

Se lo metti nel singolo pacchetto entra ugualmente, se lo metti in tutti i pacchetti entra dovunque, se lo metti nel generale ma lo togli nel pacchetto, il pacchetto NON lo usa (ma lo installa, questo è lo strano), in barba alle use generali, che sono SOLO un livello di una catena di ereditarietà.

[marcoc1712]

Prova a mettere dsd nelle USE flags (nel make.conf) e prova a reinstallare squeezelite....


Ovvio che va tolto se non ti interessa, e non c é bisogno del - nella ebuild....

Ho sempre cercato di dire che vanno tolte dalle USE flags cose che non interessano.

SI, ma c'era un fraintendimenti di base:

tu intendi per USE FLAGS solo quelle in make.conf., non è così, quelle sono quelle 'generali'. ogni pacchetto 'vede' quelle e le altre in una specifica gerachia di ereditarietà, che arriva fino a delle variabili temporanee per la build del singolo pacchetto in quella precisa sessione.

Io intendo quelle risultanti per il pacchetto e credevo, sbagliando, che se nelle generali c'è ffmpeg ma nel locale c'è -ffmpeg, il risultato fosse che non ci fosse, come non mettendolo. In realtà non è così, ma:

Poniamo di avere "XXX" nelle use flags glogali.

Se IUSE= ""

non puoi chiederti "if use xxx", produce un errore.


Se IUSE= "XXX"

risolve la dipendenza, installa e "if use xxx" è Vero.


Se IUSE= "-XXX"

risolve la dipendenza, installa e "if use xxx" è Falso.

l'ultima cosa è quella che mi lascia perplesso, il resto ci sta.

[marcoc1712]

facci sapere le tue impressioni...

E' presto, diverso è diverso, ma ho bisogno di ascoltare per giudicare.

Al resto ho già risposto più volte e dato che finalmente abbiamo trovato una quadra, va benissimo così.

Rimane ancora qualche punto di attenzione e di incomprensione, ma ci stiamo avvicinando e comunque nulla che non possa essere sistemato da un sistemista (...mai nome per una profesione fu così sbagliato...) quindi me ne torno a brucare...

Una cosa però la dico: Per richiedere una 'stracciatura di m...i così ENORME deve produrre risulati sonori a livello di orgasmo, altrimenti non ne vale la pena. E' tutto il giorno che litigo con lightpd, o meglio, non tanto con lui, ma con il fatto di dover aggiornare, sincronizzare,... che porta via ore ed ore.

[marcoc1712]

Ovvio che va tolto se non ti interessa, e non c é bisogno del - nella ebuild....

Qui è il problema.

SE vuoi usare le formule "if use then... " in src_complile per impostare i CFLAGS, la IUSE deve essere impostata con o senza -. Il fatto che lo sia quella globale, per l'ebuild non conta, se non trova la IUSE, produce un errore.

[bigtube]

E' presto, diverso è diverso, ma ho bisogno di ascoltare per giudicare.

Al resto ho già risposto più volte e dato che finalmente abbiamo trovato una quadra, va benissimo così.

Rimane ancora qualche punto di attenzione e di incomprensione, ma ci stiamo avvicinando e comunque nulla che non possa essere sistemato da un sistemista (...mai nome per una profesione fu così sbagliato...) quindi me ne torno a brucare...

Una cosa però la dico: Per richiedere una 'stracciatura di m...i così ENORME deve produrre risulati sonori a livello di orgasmo, altrimenti non ne vale la pena. E' tutto il giorno che litigo con lightpd, o meglio, non tanto con lui, ma con il fatto di dover aggiornare, sincronizzare,... che porta via ore ed ore.

opinione legittima. Sta di fatto che il sottoscritto per es. non tornera' indietro....ci ho provato...ma di volata son tornato a Gentoo.
Inoltre lo sbattimento per essere completo deve prevedere l'installazione anche del server con LMS+C3PO su Gentoo....proprio oggi
ho provato a tornare sul vecchio server con Debian....l'ho lasciato immediatamente senza il minimo dubbio.
Anche senza orgasmo siamo su un altro livello a sistema completo. Di "apparizioni mariane" nessuno ha parlato
Sappiamo tutti che per piccoli o meno piccoli miglioramenti bisogna "spendere" tanto. E di certo non eravamo a "piedi" prima.
Nessuno ha detto che era facile.....inoltre hai fatto attenzione alla compilazione del Kernel....anche quello è un passo fondamentale
Negli screenshot riportati nella guida ci sono i passaggi minimi per un kernel gia' ben organizzato per partire....poi si puo' fare di meglio.
Se la pazienza è poca o anche il tempo è risicato c'è una marea di sistemi operativi a disposizione.
C'è anche chi ascolta con le cineserie e si dichiara soddisfatto. Il mondo è bello perchè vario anche se noi lo vogliamo assoggettare a tutti i costi.