# GeCHI Weekly Report #1.4

## oRDeX

Quarto report settimanale dei GeCHI.

Come al solito, rinnovo l'invito a commentare il thread e ricordo che in fondo sono presenti le referenze per seguire i report tramite RSS.

==

GeCHI Weekly Report #1.4

Benvenuti al quarto GeCHI Weekly Report, il quale fornisce sommari e notizie importanti relative allo sviluppo della distribuzione Gentoo riguardanti il seguente periodo: 09.10.2009 - 15.10.2009.

[1] Hardened sys-devel/gcc-4.3.4 (stabilizzazione) (13.10)

Di recente, per i profili hardened, è stata stabilizzata la versione 4.3.4 di sys-devel/gcc, la quale differisce rispetto alla precedente versione stabile 3.4.6 del compilatore per le seguenti feature:

1. FORTIFY_SOURCE=2 e -fno-strict-overflow - abilitate di default (non lo erano per gcc 3.4.6);

2. Stack Smashing Protection (SSP) - disabilitata;

tutte le altre ottimizzazioni tipiche del compilatore hardware restano invariate. Per l'upgrade si raccomanda di seguire i consigli riportati al paragrafo [2] Istruzioni per un aggiornamento generale della guida ufficiale Gentoo: Guida all'aggiornamento di GCC per Gentoo

[2] Monthly Gentoo Council (12.10)

Il 12 ottobre si è svolto l'incontro mensile del Consiglio Gentoo in cui si è discusso se i vari package manager di Portage devono o meno preservare i timestamps dei files quando emerge installa i file; la decisione finale è stata quella di preservare i timestamps per garantire una migliore QA ed evitare il verificarsi di bug e regressioni quali:

report #263387

report #83877

Portage preserva i timestamps dalla versione 2.1.2.10, così come pkgcore, mentre Paludis non è PMS compliant ed è quindi soggetto a tutte le problematiche legate alla modifica degli mtimes. Per maggiore informazioni su tali problemi, si consiglia la lettura di questa discussione.

Il resto degli argomenti dell'agenda previsto per questo meeting non sono stati discussi perchè non ci sono stati cambiamenti di rilievo rispetto all'incontro dello scorso mese.

[3] Nuove USE globali (11.10)

Un nuovo RFC è stato presentato riguardante l'introduzione di due nuove USE globali:

static-libs - Build static libraries;

dbi - Enable dev-db/libdbi (database-independent abstraction layer) support;

Va doverosamente segnalato che l'introduzione della USE globale static-libs sarà l'inizio di una nuova era per la distribuzione Gentoo, in quanto apporterà un netto miglioramento della stabilità e affidabilità dell'intera distribuzione a causa della rimozione dei file *.a (static library) e *.la (libtool archive) che generalmente vengono compilati e installati di default dai pacchetti di Portage, ma che sono praticamente inutili per l'utilizzo desktop/server (fatte le dovute eccezioni che si contano sulle dita di una mano). In modo particolare i file *.la, oltre ad essere inutili, sono anche pericolosi, perchè sono spesso la fonte di random segmentation fault e di comportamenti anomali delle applicazioni (spesso di difficile individuazione e correzione), quindi la loro totale rimozione non può che migliorare la qualità finale delle librerie a tutto vantaggio dell'utente finale che si ritroverà una Gentoo box meno soggetta a "problematiche inesplicabili".

Ci sono anche altri benefici indiretti dovuti alla rimozione dei file *.a/*.la, quali:

1. tempi di compilazione e installazione ridotti (vedere anche punto 3) - i file *.a, che sono copie statiche dei corrispettivi file *.so, non verrebbero compilati e quindi tanto meno installati, riducendo i tempi di esecuzione delle varie ebuild phase;

2. minore spreco di spazio - non installando i file *.a/*.la si spreca meno spazio sull'hd e in particolar modo, evitando i file *.la che sono generalmente più piccoli di 1KiB, si evita di sprecare spazio a causa di file eccessivamente piccoli rispetto al block size del filesystem in uso (generalmente 4KiB);

3. riduzione dell'effetto 'LDPATH Pollution' - molti, se non quasi tutti i file *.a/*.la vengono installati in /usr/lib e siccome non vengono usati, hanno il pessimo effetto di rallentare inultimente il loader e linker di sistema in quanto entrambi devono rifare la scansione di /usr/lib ogni qual volta non trovano una libreria nei path o nella cache di sistema, quindi meno spazzatura c'è in /usr/lib minore saranno i tempi di caricamento e linking (ergo, di compilazione) delle librerie, a tutto vantaggio della reattività del sistema e dell'utente finale;

Affinchè tutti gli ebuild presenti in Portage che installano i file *.a/*.la vengano convertiti all'uso della nuova USE static-libs, sarà necessario attendere un po di tempo, vista l'enorme mole di ebuild da aggiornare e considerando che tutto il processo di conversione è iniziato da poco. Nonostante ciò, i solerti sviluppatori Gentoo, già dallo scorso aprile, hanno reso disponibile in Portage l'utility: dev-util/lafilefixer, tramite la quale è possibile individuare i file *.la con riferimenti errati e correggerli (si consiglia di usarlo regolarmente, soprattutto dopo ogni compilazione).

E' superfluo dire che Gentoo sarà la prima distribuzione Linux in assoluto ad operare la sopra citata operazione, mentre tutte le altre distribuzioni al momento preferiscono 'distribuire' sia le librerie statiche che i lafile, con tutti gli svantaggi del caso.

Per chi fosse interessato ad approfondire ulteriormente l'argomento sulle librerie statiche e i lafiles, si consiglia la lettura dell'esauriente serie di articoli scritti dallo sviluppatore Gentoo Diego 'flameeyes' Pettenò reperibili al seguente link.

[last rites]

Il Gentoo Tree Cleaning Team segnala che i seguenti pacchetti verranno rimossi dal tree di portage entro 30 giorni:

# Markus Meier  gentoo.org> (11 Oct 2009)

# mask media-gfx/autopano-sift for removal in 30 days

# use media-gfx/autopano-sift-C instead

media-gfx/autopano-sift

# Jonathan Callen  gentoo.org> (11 Oct 2009)

# Old KDE 3.5.9 monolithic ebuilds.  Replaced by kde*-meta.

# Masked for removal in 30 days

kde-base/kdeaccessibility

kde-base/kdeaddons

kde-base/kdeadmin

kde-base/kdeartwork

kde-base/kdebase

kde-base/kdeedu

kde-base/kdegames

kde-base/kdegraphics

kde-base/kde

kde-base/kdemultimedia

kde-base/kdenetwork

kde-base/kdepim

kde-base/kdesdk

kde-base/kdetoys

kde-base/kdeutils

kde-base/kdewebdev

# Ulrich Mueller  gentoo.org> (11 Oct 2009)

# Blocked by its own dependency, therefore no longer installable.

# Use the news module of app-admin/eselect-1.2* as replacement.

# Masked for removal in 30 days, bug 288560.

app-admin/eselect-news

# Samuli Suominen  gentoo.org> (15 Oct 2009)

# ksynaptics is replaced by x11-misc/touchfreeze

# gsynaptics is replaced by gnome-extra/gpointing-device-settings

# libsynaptics is orphaned library

# bug 289170

gnome-extra/gsynaptics

x11-libs/libsynaptics

kde-misc/ksynaptics

# Michael Sterrett  gentoo.org> (14 Oct 2009)

# Requires aRTs and last released in 2007

games-engines/kwest

chi fa uso di uno o più dei pacchetti sopra citati è fortemente incoraggiato a trovare alternative oppure a contribuire al loro mantenimento.

----

Puoi seguire i GeCHI Weekly Report tramite i seguenti canali:

- gechi.it RSS Feed;

- Twitter: GeCHI Group | GeCHI RSS Feeds;

- Identi.ca: GeCHI Group | GeCHI RSS Feeds;

- Facebook;

----------

## cloc3

 *oRDeX wrote:*   

> 
> 
> Va doverosamente segnalato che l'introduzione della USE globale static-libs sarà l'inizio di una nuova era per la distribuzione Gentoo

 

proprio l'altro ieri mi ero imbattuto quasi per caso in questo warning:

 *emerge wrote:*   

> 
> 
>  * This version of libogg has stopped installing .la files. This may
> 
>  * cause compilation failures in other packages. To fix this problem,
> ...

 

quando ho eseguito il fix, ho osservato un numero incredibile di correzioni.

volevo aprire un thread, ma è un periodo che mi cimento solo in interventi di qualità scadente   :Rolling Eyes:  .

certo che, mentre gentoo si dota di strumenti sempre più sofisticati ed efficienti, per l'utente diventa complicato tenere d'occhio ogni novità.

non capisco però perché consigliate di usare il comando ad ogni compilazione e non è sufficiente applicarlo una tantum per stabilizzare il sistema definitivamente.

----------

## Scen

 *oRDeX wrote:*   

> Paludis non è PMS compliant

 

D'oh!  :Shocked:  Questo non l'avrei mai immaginato, ero ancora rimasto che Paludis fosse sempre davanti a Portage su tutto   :Exclamation: 

 *oRDeX wrote:*   

> 
> 
> Va doverosamente segnalato che l'introduzione della USE globale [b]static-libs sarà l'inizio di una nuova era per la distribuzione Gentoo, in quanto apporterà un netto miglioramento della stabilità e affidabilità dell'intera distribuzione a causa della rimozione dei file *.a (static library) e *.la (libtool archive) che generalmente vengono compilati e installati di default dai pacchetti di Portage,
> 
> [...]
> ...

 

Ohhhh, questa è una bella novità, speriamo che le migliore elencate avvengano concretamente   :Cool: 

----------

## !equilibrium

 *cloc3 wrote:*   

> quando ho eseguito il fix, ho osservato un numero incredibile di correzioni.
> 
> volevo aprire un thread, ma è un periodo che mi cimento solo in interventi di qualità scadente   .

 

eh sì, il numero di lafiles errati è elevato (colpa di upstream, non di gentoo!), purtroppo chi scrive un software non sempre sa a cosa servono e quando usarli, quindi si limitano a copiare cosa fanno gli altri con i risultati (e relativi problemi) che vedi.

 *cloc3 wrote:*   

> certo che, mentre gentoo si dota di strumenti sempre più sofisticati ed efficienti, per l'utente diventa complicato tenere d'occhio ogni novità.

 

è il motivo per cui ho iniziato a scrivere i GWR (a cui seguiranno a ruota altri servizi di informazione) perchè il gap tra l'utente medio e i devel è oramai enorme e negli ultimi due anni ci sono stati troppi allarmismi e FUD infondati del tipo "gentoo è morta" che vorrei stroncare sul nascere nel futuro prossimo.

 *cloc3 wrote:*   

> non capisco però perché consigliate di usare il comando ad ogni compilazione e non è sufficiente applicarlo una tantum per stabilizzare il sistema definitivamente.

 

ecco bravo, ora che mi ci hai fatto riflettere, forse è stata un po esagerata la mia affermazione, ma i problemi dei lafiles dipendono molto dal tipo di installazione e dalla frequenza degli aggiornamenti fatti; io in genere ho un alto numero di pacchetti che giornalmente ricompilo e/o installo per svariati motivi, quindi mi ritrovo sempre con tonnellate di lafiles da correggere, ma la situazione non cambia anche se rapportata a frequenze di update inferiori: avrai pochi aggiornamenti e pochi lafiles da correggere, ma ce li avrai sempre.

----------

## djinnZ

domande in breve:

visto che sono un tantino "distratto" ultimamente non è che qualcuno potrebbe riassumere perchè ssp è stata disabilitata di default?

dato che la situazione mi consiglia di non aggiornare più la gentoo che ho ma di reinstallarla ex novo val la pena di disabilitare globalmente static-libs?

----------

## !equilibrium

 *djinnZ wrote:*   

> domande in breve:
> 
> visto che sono un tantino "distratto" ultimamente non è che qualcuno potrebbe riassumere perchè ssp è stata disabilitata di default?

 

certo! è questo lo scopo dei GWR, informare da un lato e dare help/feedback agli utenti dall'altro.

per il tuo quesito va fatta una premessa: attualmente SSP è suddiviso in due branch di sviluppo, uno per gcc3 e uno per gcc4, questo per svariati motivi, un po perchè gcc4 è molto diverso da gcc3 e un po perchè il branch per gcc3 è praticamente morto (non viene più sviluppato). sfortunamente SSP per gcc4 non è ancora completo, non ha le stesse funzionalità di gcc3.

da quello che mi risulta SSP dovrebbe essere completo con la stabilizzazione di gcc4.4

----------

## !equilibrium

 *Scen wrote:*   

> D'oh!  Questo non l'avrei mai immaginato, ero ancora rimasto che Paludis fosse sempre davanti a Portage su tutto   

 

strano ma vero, su questo punto Paludis non preserva i timestamp generando quindi molti problemi con la roba python, lisp, ruby e altro; da quando Ciaranm ha fatto il fork di Gentoo con Exherbo, Paludis è nettamente peggiorato, mentre pkgcore è migliorato parecchio (io continuo a preferire Portage 2.2 che nelle ultime versioni ha parecchie killer-feature)

 *Scen wrote:*   

> Ohhhh, questa è una bella novità, speriamo che le migliore elencate avvengano concretamente  

 

Diego "flameyes" Pettenò ed io siamo in prima linea e non molliamo il fronte fino a quando l'ultimo lafile non verrà rimosso; ho già sistemato un po di ebuild a riguardo nel mese scorso, ma sono davvero tanti da sistemare e i devel sono pochi, per cui si sta optando più per una soluzione unica e definitiva tramite il filtraggio by eclass e portage stesso, così che si vada a colpire la maggior parte degli ebuild con una modifica sola (o una manciata).

----------

## Apetrini

 *Scen wrote:*   

>  *oRDeX wrote:*   [b]Paludis non è PMS compliant 
> 
> D'oh!  Questo non l'avrei mai immaginato, ero ancora rimasto che Paludis fosse sempre davanti a Portage su tutto  
> 
> 

 

Premetto che sono di parte e la mia è solamente un idea personale. Volevo dire che Paludis è sempre davanti a Portage  :Smile: 

Il motivo per cui paludis non ha "implementato" la famosa preservazione di mtime è dovuta al fatto che tale caratteristica non è stata spiegata con la dovuta precisione in PMS. Sembra che questa regola sia stata scritta più guardando a quello che già faceva il portage; non è un problema se non fosse che a volte portage ha dei comportamenti ambigui a tal proposito. Definire, quindi, cose del tipo "quando si copia da D a ROOT bisogna preservare sempre gli mtime, salvo in casi in cui è necessario non farlo" non giova al sistema perché è un comportamento ambiguo e in futuro potrebbero esserci problemi (e poi va contro la filosofia di ciaran che vuole bene i puntini sulle i e non lascia nulla al caso).

Giusto per chiarezza, posto in inglese il commento di ciaran (non me la sento di tradurlo per non scambiare accidentalmente pan per polenta nella traduzione) *Quote:*   

> 
> 
> Looking at implementing this, my current list of questions is:
> 
> * Preserve mtimes on what? Definitely just regular files?
> ...

 

Tornando all'altro discorso io sarei per tenere un thread sticky dove inserire tutti i link e un thread a settimana.

[/code]

----------

## !equilibrium

 *Apetrini wrote:*   

> Il motivo per cui paludis non ha "implementato" la famosa preservazione di mtime è dovuta al fatto che tale caratteristica non è stata spiegata con la dovuta precisione in PMS. Sembra che questa regola sia stata scritta più guardando a quello che già faceva il portage;

 

non è così, l'argomento è stato discusso in Gentoo Council per tutti e tre i package manager, guarda caso, pure pkgcore è compliant alla questione degli mtimes perchè è un problema noto dalla notte dei tempi.

 *Apetrini wrote:*   

> non è un problema se non fosse che a volte portage ha dei comportamenti ambigui a tal proposito.

 

non è vero, non è portage ad avere comportamenti ambigui, l'installazione dei pacchetti andrebbe a buon fine anche senza fare il preserve degli mtimes, ma senza di essi la cache e il bytecode di certi linguaggi interpretati (in primis python, a seguire ruby) smette di funzionare come dovrebbe, generando malfunzionamenti "ambigui" a tutti i pacchetti che ne fanno uso (quindi portage compreso visto che è scritto in python! ma portage non è la causa del sopracitato problema, ne è la vittima indiretta). la questione è ben spiegata nel link del GWR.

 *Apetrini wrote:*   

> Definire, quindi, cose del tipo "quando si copia da D a ROOT bisogna preservare sempre gli mtime, salvo in casi in cui è necessario non farlo" non giova al sistema perché è un comportamento ambiguo e in futuro potrebbero esserci problemi (e poi va contro la filosofia di ciaran che vuole bene i puntini sulle i e non lascia nulla al caso).

 

la "filosofia" di ciaranm non è legge, e le sue affermazioni si basano su trip mentali che nessun altro si pone; il problema degli mtimes coinvolge una fetta del tree di portage troppo vasta (hai idea di quanti pacchetti python,ruby,lisp ne sono coinvolti? e mi fermo solo a python,ruby e lisp, ma la questione mtimes va ben oltre) per poter essere risolta dal punto di vista degli ebuild quindi, in questi casi, è preferibile una soluzione unica a livello di PMS (leggi package manager) per risolvere definitivamente il problema alla radice; se tu e ciaranm siete disposti a smazzarvi l'onere di modificare singolamente qualche migliaia di ebuild per aggiustare gli mtimes file per file siete liberi di farlo   :Rolling Eyes:  scomettiamo che nessuno lo farà e che nemmeno l'incredibile Ciaranm "troverà" la soluzione definitiva, etica e perfetta al problema senza passare dal PMS?   :Wink:  (è da tre anni che i devel discutono sto problema e sta fantomatica soluzione definitiva, etica e perfetta non l'ha trovata ancora nessuno, se Ciaranm ce l'ha perchè non la condivide?)

----------

## !equilibrium

 *djinnZ wrote:*   

> dato che la situazione mi consiglia di non aggiornare più la gentoo che ho ma di reinstallarla ex novo val la pena di disabilitare globalmente static-libs?

 

non ho capito questa domanda, perchè vorresti disabilitare globalmente static-libs che è già disabilitata di default? se l'abiliti ti installa i file *.a e i lafiles (motivo per cui è disabilitata di default) e comunque non ho capito l'attinenza con la reinstallazione. più info please.

----------

## cloc3

 *!equilibrium wrote:*   

> purtroppo chi scrive un software non sempre sa a cosa servono e quando usarli, quindi si limitano a copiare cosa fanno gli altri con i risultati (e relativi problemi) che vedi.
> 
> 

 

quindi lafilfixer è uno strumento indipendente da revdep-rebuild?

mi sfugge ancora l'esatta relazione tra questi due programmi.

----------

## djinnZ

Ho capito al contrario, che static-libs fosse abilitata di default per la transizione.

Reistallo perchè per il nuovo gcc devo comunque ricompilare tutto.

gcc 4.4 quindi non prima di un annetto per avere ssp?

@Apetrini: Tanto per dire la sulla polemica per gli mtimes vorrei far notare che sono un problema del portage tree non di emerge in se stesso, per capirci.

----------

## !equilibrium

 *cloc3 wrote:*   

> quindi lafilfixer è uno strumento indipendente da revdep-rebuild?
> 
> mi sfugge ancora l'esatta relazione tra questi due programmi.

 

sì, lafilefixer è un semplice script bash che va a leggersi il contenuto dei file .la (che sono dei semplici file di testo a loro volta) e se al loro interno ci sono delle reference sbagliate (librerie vecchie, librerie inesistenti, altri file .la) vengono corretti per puntare alle reference giuste, tutto qua; pensa un po, per uno stupido file di testo che non viene mai usato, ci si ritrova con vagonate di problemi che teoricamente non dovrebbero nemmeno esistere o presentarsi...

 *djinnZ wrote:*   

> gcc 4.4 quindi non prima di un annetto per avere ssp?

 

non ne ho idea sinceramente, ma di sicuro non nel giro di pochi mesi ecco.

----------

## Apetrini

@!equilibrium:

Credo di essere stato in parte frainteso. Quando ho detto che il portage ha comportamenti ambigui intendevo un'altra cosa. Sebbene si dica che il portage è PMS compliant e che preserva gli mtimes, qualcuno dice(io oramai non posso parlare perché non uso emerge da piu di un anno e mezzo) che ci sono situazioni in cui ad alcuni file non viene preservato mtimes. Ora, la domanda sorge spontanea, quando questo è permesso e quando no.

Ma lasciamo perdere questo dettaglio degli mtimes e guardiamo la questione in una maniera più generica (che secondo me è anche il nocciolo della questione nonché la mia personale interpretazione del pensiero di ciaranm).

Se si crea uno standard, o meglio, una specifica (in questo caso PMS) bisognerebbe esprimere in maniera molto precisa i modi, i vincoli e quant'altro riguardi la suddetta. Se ciaranm ha delle domande riguardo all'implementazione/procedure di alcune cose è giusto che gli venga data una risposta; chi meglio di coloro che hanno stilato la specifica possono rispondere alle domande? Se poi la specifica non esplica alcune cose(magari anche seghe mentali), gli autori hanno 2 strade: o viene spiegata meglio e viene aggiunta una postilla(passatemi il termine) alla specifica oppure si decide di non aggiungere nulla etichettando la domanda/quesito come "non rilevante".

Ora il problema, secondo me, è che se qualcosa viene definito "non rilevante" deve essere "non rilevante" anche in futuro (per quanto possibile).

La tipica situazione che si vuole evitare è: "abbiamo detto che era irrilevante, ma poi ci siamo accorti che emerge assume un certo comportamento in proposito e in realtà se non si assume lo stesso comportamento di emerge, non funziona".

Io credo che ciaranm voglia solo delle risposte...

In tutta questa faccenda si sta perdendo, secondo me, la finalità principale di PMS, ovvero l'indipendenza totale dal package manager. E' naturale pensare che emerge faccia un po' da traino, ma se alcune scelte rendono "le cose piu facili" andando però contro la finalità principale del PMS, be queste scelte non mi trovano affatto d'accordo.

Per quanto mi riguarda è meglio avere una specifica giusta e un implementazione sbagliata che un implementazione ottima di una specifica barlocca.

P.s. probabilmente ho preso troppo alla lettera l'obiettivo della PMS, ma secondo me è una grande idea e sicuramente richiede dei grossi sforzi.

----------

## cloc3

 *oRDeX wrote:*   

> Nonostante ciò, i solerti sviluppatori Gentoo, già dallo scorso aprile, hanno reso disponibile in Portage l'utility: dev-util/lafilefixer

 

ho incontrato un fastidiosissimo effetto collaterale associato all'uso di lafilefixer che impone una segnalazione:

i successivi controlli del sistema tramite chiamata a qcheck generano una lista infinita di falsi positivi.

----------

## riverdragon

Perché non usi semplicemente lafilefixer --justfixit e lo lasci arrangiarsi?

----------

## cloc3

 *riverdragon wrote:*   

> Perché non usi semplicemente lafilefixer --justfixit e lo lasci arrangiarsi?

 

è esattamente il comando che genera il problema.

dopo il passaggio di lafilefixer, tutti i file corretti assumono un md5sum diverso da quello originale conservato nel database di sistema, dunque qcheck li considera corrotti.

----------

## !equilibrium

 *cloc3 wrote:*   

> dopo il passaggio di lafilefixer, tutti i file corretti assumono un md5sum diverso da quello originale conservato nel database di sistema, dunque qcheck li considera corrotti.

 

quale preferisci tra i due mali? una gentoo che segfault casualmente o avere il comando qcheck con falsi positivi?   :Laughing: 

p.s.: la soluzione definitiva è solo una: rimboccarsi le maniche e modificare gli ebuild affinchè vengano rimossi i lafiles.

----------

## cloc3

 *!equilibrium wrote:*   

> 
> 
> quale preferisci tra i due mali?

 

capisco bene.

ma questo implica dei problemi di comunicazione.

l'utente non deve considerare lafilefixer come un software di sistema, ma come uno strumento estraneo e provvisorio, integrato solo parzialmente. quanto meno, sarebbe utile inserire qualche avviso opportuno sia nell'ebuild del pacchetto che in ogni luogo ufficiale ove ne venga consigliato l'uso.

----------

## !equilibrium

 *cloc3 wrote:*   

> l'utente non deve considerare lafilefixer come un software di sistema, ma come uno strumento estraneo e provvisorio, integrato solo parzialmente. quanto meno, sarebbe utile inserire qualche avviso opportuno sia nell'ebuild del pacchetto che in ogni luogo ufficiale ove ne venga consigliato l'uso.

 

allora segnalalo sul bugzilla di gentoo

----------

## Ic3M4n

è stato già segnalato segnato come INVALID.

https://bugs.gentoo.org/show_bug.cgi?id=274585

----------

## Scen

 *Ic3M4n wrote:*   

> è stato già segnalato segnato come INVALID.
> 
> https://bugs.gentoo.org/show_bug.cgi?id=274585

 

E nel commento #5 viene proposta una soluzione temporanea, direi, semplicemente geniale  :Cool: 

 *Daniel Pielmeier wrote:*   

> 
> 
> If you want correct md5sums you should consider adding something like this to
> 
> your /etc/portage/bashrc:
> ...

 

----------

## cloc3

 *Scen wrote:*   

> E nel commento #5 viene proposta una soluzione temporanea, direi, semplicemente geniale 
> 
> 

 

infatti. portage possiede in sé gli strumenti per risolvere il caso.

non capisco, a questo punto, perché non si utilizzi direttamente un'istruzione che rimuove i lafile, anziché fissarli.

magari predisponendo una FEATURE apposita da selezionare in make.conf

----------

## !equilibrium

 *cloc3 wrote:*   

> non capisco, a questo punto, perché non si utilizzi direttamente un'istruzione che rimuove i lafile, anziché fissarli.magari predisponendo una FEATURE apposita da selezionare in make.conf

 

in realtà la soluzione non è così semplice; è vero che i lafiles sono il male e vanno rimossi, ma è anche altrosì vero che non si deve fare di tutte le erbe un fascio, ma va valutato singolo caso per singolo caso.

Un esempio ne è app-arch/libarchive-2.7.1 che ho di recente modificato in -r1 (vedere log: /usr/portage/app-arch/libarchive/ChangeLog ) in cui una rimozione indiscriminata dei lafiles avrebbe compromesso il normale funzionamento del pacchetto in determinate circostanze; quindi, se da un lato bisogna rimuovere i lafiles, dall'altro lato bisogna fare attenzione che tali modifiche non diventino una nuova fonte di problemi, ergo, no alle soluzioni di sterminio di massa dei lafiles, sì ad una loro oculata rimozione. (per comprendere meglio il problema: diff -u /usr/portage/app-arch/libarchive/libarchive-2.7.1.ebuild /usr/portage/app-arch/libarchive/libarchive-2.7.1-r1.ebuild)

----------

