Ragazzi, calma!
Marco è banalmente perplesso a proposito della scelta dello sviluppatore che ha creato l'ebuild di aggiungere quella patch.
Se non ho capito male, è preoccupato del fatto che, in futuro, la presenza di quella patch potrebbe rendere l'ebuild incompatibile con nuove versioni di squeezelite. Se il punto è questo, IMO si tratta di un non-problema: che "il sorgente" di un pacchetto (in questo caso l'ebuild) sia legato ad una particolare versione (dei sorgenti "upstream") del software che "gestisce" e debba essere aggiornato ogni qual volta esce una nuova versione del software è cosa del tutto normale.
Non di meno, indubbiamente è una scelta curiosa. Se non vado errato, avrebbe potuto ottenere il medesimo risultato banalmente impostando le opzioni di configurazione del "Makefile". Ma, evidentemente, avrà avuto i suoi buoni motivi per fare come ha fatto (magari era banalmente più semplice fare così...).
Comunque sia, per togliersi ogni dubbio, anziché perdere tempo a discuterne qui basterebbe mandargli una e-mail e chiedere lumi direttamente a lui, non credete?
Mi ripeterò, non ve ne abbiate a male...
Quella patch aggiunge un IF ed END IF prima delle include ed a fine sorgente di ogni codec, rendendoli in pratica fogli bianchi..., in funzione dell'opzione di link passata dalla ebuild che la preleva dalla iUSE.
Come metodo è più radicale e stupido di un buldozer, è in completa sovrapposizione con quello standard usato da squeezelite ed ovvviamente funziona solo dove le opzioni sono indicate, quindi per gentoo con quell'ebuild. Non serve aggiungere commenti, è una soluzione quick and dirty per raggiungere uno scopo 'one shot' senza preoccuparsi della manutenzione futura.
A cosa serve? a nulla, se non a 'sganciare' le dipendenze dinamiche anche da flac.c.
EDIT: correggo, oggi a nulla, nella prima versione c'era un problema di disponibilità di librerie in gentoo, per cui non era possibile compilare senza rimuovere in qualche modo alcune dipendenze.
I files toccati sono tutti codec.c + decode.c, quindi sorgenti non interessati da R2, ma direttamente dallo standrd di Triode (o quello mantenuto oggi da Ralphy), quindi volendo fare accogliere la modifica (con le dovute correzioni per renderla compatibile con le versioni portabili) dovrei convincere lui o rendere R2 incompatibile giusto per questo.
Ci sono controindicazione nel non applicarla? No, tranne che libflac.h dovrà essere presente sul sistema di compilazione. Se si vuole correggere questo, si applica a flac lo stesso metodo usato in squeezelite per gli altri codecs, piuttosto.
Per queste considerazioni ed almeno fino a che nessuno mi segnala altri fatti (es. che con la patch suona meglio, cosa che mi lascerebbe molto perplesso) questa modifica va esclusa da R2, il che non implica che non possa rimanere in quell'ebuild - non compete a me - , nel caso, però, chiedo cortesemente che venga aggiunto un cambio di versione e corrette le note di licensing, così che risulti evidente che NON è R2 (pur originando da li) e non è manutenuta da me. Basta farlo nel contesto della patch.
Il manutentore non è raggiungibile e comunque la sua versione non indirizzava R2 ma prima la versione di Triode e quindi una vecchia di Ralphy. R2 viene puntato solo da questa ultima release.
Di fatto usa il makefile (patchando anche lui, è un patchatore seriale...), ma ha costruito un gioco di incarstri tra USE, OPT ed INCLUDE nei sorgenti che gli ocnsente di 'governare' il tutto con le opzioni di USE nell'ebuild.
Se si conviene che la patch ai osrgenti non serve, la parte di make dell'ebuild si può semplificare moltissimo sostituendola con un semplice makefile dedicato o al limite dipendente dall'architettura (questo manca) così da impostare opportunamnet ei CFLAGS. Il come lo lascio decidere ai sistemisti, ma makefile.min è a mio avviso l'esempio da seguire.
Quanto viene dopo l'emake è quello che fa easetup in debian, nessun problema.
Rispondi quotando