View previous topic :: View next topic |
Author |
Message |
oRDeX Veteran
Joined: 19 Oct 2003 Posts: 1325 Location: Italy
|
Posted: Sat Oct 17, 2009 2:18 pm Post subject: GeCHI Weekly Report #1.4 (novità dal mondo Gentoo)IMPORTANTE |
|
|
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:
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:
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; |
|
Back to top |
|
|
cloc3 Advocate
Joined: 13 Jan 2004 Posts: 4787 Location: http://www.gentoo-users.org/user/cloc3/
|
Posted: Sun Oct 18, 2009 7:07 pm Post subject: Re: GeCHI Weekly Report #1.4 (novità dal mondo Gentoo)IMPORT |
|
|
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,
* install dev-util/lafilefixer and run:
* lafilefixer --justfixit
|
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 .
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. _________________ vu vu vu
gentù
mi piaci tu |
|
Back to top |
|
|
Scen Retired Dev
Joined: 29 Jul 2003 Posts: 2470 Location: Padova, Italy
|
Posted: Mon Oct 19, 2009 7:11 am Post subject: Re: GeCHI Weekly Report #1.4 (novità dal mondo Gentoo)IMPORT |
|
|
oRDeX wrote: | Paludis non è PMS compliant |
D'oh! Questo non l'avrei mai immaginato, ero ancora rimasto che Paludis fosse sempre davanti a Portage su tutto
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 _________________ I was born in a deep forest/I wish I could live here all my life/I am made from stones and roots/My home, these woods and roads
All my life I loved this sound/Of the woods all around/Eagles flies where the winds blows free
Journey is my destiny |
|
Back to top |
|
|
!equilibrium Bodhisattva
Joined: 06 Jun 2004 Posts: 2109 Location: MI/BG/LC
|
Posted: Mon Oct 19, 2009 11:59 am Post subject: Re: GeCHI Weekly Report #1.4 (novità dal mondo Gentoo)IMPORT |
|
|
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. _________________ Arch Tester for Gentoo/FreeBSD
Equilibrium's Universe
all my contents are released under the Creative Commons Licence by-nc-nd 2.5 |
|
Back to top |
|
|
djinnZ Advocate
Joined: 02 Nov 2006 Posts: 4831 Location: somewhere in L.O.S.
|
Posted: Mon Oct 19, 2009 12:59 pm Post subject: |
|
|
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? _________________ scita et risus abundant in ore stultorum sed etiam semper severi insani sunt
mala tempora currunt...mater stultorum semper pregna est
Murpy'sLaw:If anything can go wrong, it will - O'Toole's Corollary:Murphy was an optimist |
|
Back to top |
|
|
!equilibrium Bodhisattva
Joined: 06 Jun 2004 Posts: 2109 Location: MI/BG/LC
|
Posted: Mon Oct 19, 2009 1:28 pm Post subject: |
|
|
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 _________________ Arch Tester for Gentoo/FreeBSD
Equilibrium's Universe
all my contents are released under the Creative Commons Licence by-nc-nd 2.5 |
|
Back to top |
|
|
!equilibrium Bodhisattva
Joined: 06 Jun 2004 Posts: 2109 Location: MI/BG/LC
|
Posted: Mon Oct 19, 2009 3:16 pm Post subject: Re: GeCHI Weekly Report #1.4 (novità dal mondo Gentoo)IMPORT |
|
|
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). _________________ Arch Tester for Gentoo/FreeBSD
Equilibrium's Universe
all my contents are released under the Creative Commons Licence by-nc-nd 2.5 |
|
Back to top |
|
|
Apetrini Veteran
Joined: 09 Feb 2005 Posts: 1158
|
Posted: Mon Oct 19, 2009 3:37 pm Post subject: Re: GeCHI Weekly Report #1.4 (novità dal mondo Gentoo)IMPORT |
|
|
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
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?
* Preserve how? Is second-resolution enough, or are we expected to preserve
nanosecond-resolution on systems that support it? What are the implications on
nanosecond-resolution systems where some files are merged by a rename and some
by a copy?
* Which files is the package manager allowed to modify mtimes for?
So far as I can see the Council didn't attempt to address any of these
questions when mandating the EAPI 3 change. Without answers to these, I don't
see the proposal as being implementable either as a standard or in code.
|
Tornando all'altro discorso io sarei per tenere un thread sticky dove inserire tutti i link e un thread a settimana.
[/code] _________________ Linux ape 2.6.31-vanilla. Paludis since 0.28.0. |
|
Back to top |
|
|
!equilibrium Bodhisattva
Joined: 06 Jun 2004 Posts: 2109 Location: MI/BG/LC
|
Posted: Mon Oct 19, 2009 4:25 pm Post subject: Re: GeCHI Weekly Report #1.4 (novità dal mondo Gentoo)IMPORT |
|
|
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 scomettiamo che nessuno lo farà e che nemmeno l'incredibile Ciaranm "troverà" la soluzione definitiva, etica e perfetta al problema senza passare dal PMS? (è 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?) _________________ Arch Tester for Gentoo/FreeBSD
Equilibrium's Universe
all my contents are released under the Creative Commons Licence by-nc-nd 2.5 |
|
Back to top |
|
|
!equilibrium Bodhisattva
Joined: 06 Jun 2004 Posts: 2109 Location: MI/BG/LC
|
Posted: Mon Oct 19, 2009 6:35 pm Post subject: |
|
|
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. _________________ Arch Tester for Gentoo/FreeBSD
Equilibrium's Universe
all my contents are released under the Creative Commons Licence by-nc-nd 2.5 |
|
Back to top |
|
|
cloc3 Advocate
Joined: 13 Jan 2004 Posts: 4787 Location: http://www.gentoo-users.org/user/cloc3/
|
Posted: Mon Oct 19, 2009 7:27 pm Post subject: Re: GeCHI Weekly Report #1.4 (novità dal mondo Gentoo)IMPORT |
|
|
!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. _________________ vu vu vu
gentù
mi piaci tu |
|
Back to top |
|
|
djinnZ Advocate
Joined: 02 Nov 2006 Posts: 4831 Location: somewhere in L.O.S.
|
Posted: Mon Oct 19, 2009 7:39 pm Post subject: |
|
|
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. _________________ scita et risus abundant in ore stultorum sed etiam semper severi insani sunt
mala tempora currunt...mater stultorum semper pregna est
Murpy'sLaw:If anything can go wrong, it will - O'Toole's Corollary:Murphy was an optimist |
|
Back to top |
|
|
!equilibrium Bodhisattva
Joined: 06 Jun 2004 Posts: 2109 Location: MI/BG/LC
|
Posted: Mon Oct 19, 2009 7:54 pm Post subject: Re: GeCHI Weekly Report #1.4 (novità dal mondo Gentoo)IMPORT |
|
|
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. _________________ Arch Tester for Gentoo/FreeBSD
Equilibrium's Universe
all my contents are released under the Creative Commons Licence by-nc-nd 2.5 |
|
Back to top |
|
|
Apetrini Veteran
Joined: 09 Feb 2005 Posts: 1158
|
Posted: Mon Oct 19, 2009 8:16 pm Post subject: |
|
|
@!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. _________________ Linux ape 2.6.31-vanilla. Paludis since 0.28.0. |
|
Back to top |
|
|
cloc3 Advocate
Joined: 13 Jan 2004 Posts: 4787 Location: http://www.gentoo-users.org/user/cloc3/
|
Posted: Wed Oct 28, 2009 9:38 am Post subject: Re: GeCHI Weekly Report #1.4 (novità dal mondo Gentoo)IMPORT |
|
|
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. _________________ vu vu vu
gentù
mi piaci tu |
|
Back to top |
|
|
riverdragon Veteran
Joined: 14 Sep 2006 Posts: 1269 Location: Verona
|
Posted: Wed Oct 28, 2009 10:14 am Post subject: |
|
|
Perché non usi semplicemente lafilefixer --justfixit e lo lasci arrangiarsi? |
|
Back to top |
|
|
cloc3 Advocate
Joined: 13 Jan 2004 Posts: 4787 Location: http://www.gentoo-users.org/user/cloc3/
|
Posted: Wed Oct 28, 2009 10:42 am Post subject: |
|
|
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. _________________ vu vu vu
gentù
mi piaci tu |
|
Back to top |
|
|
!equilibrium Bodhisattva
Joined: 06 Jun 2004 Posts: 2109 Location: MI/BG/LC
|
Posted: Wed Oct 28, 2009 10:48 am Post subject: |
|
|
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?
p.s.: la soluzione definitiva è solo una: rimboccarsi le maniche e modificare gli ebuild affinchè vengano rimossi i lafiles. _________________ Arch Tester for Gentoo/FreeBSD
Equilibrium's Universe
all my contents are released under the Creative Commons Licence by-nc-nd 2.5 |
|
Back to top |
|
|
cloc3 Advocate
Joined: 13 Jan 2004 Posts: 4787 Location: http://www.gentoo-users.org/user/cloc3/
|
Posted: Wed Oct 28, 2009 12:40 pm Post subject: |
|
|
!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. _________________ vu vu vu
gentù
mi piaci tu |
|
Back to top |
|
|
!equilibrium Bodhisattva
Joined: 06 Jun 2004 Posts: 2109 Location: MI/BG/LC
|
Posted: Wed Oct 28, 2009 1:58 pm Post subject: |
|
|
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 _________________ Arch Tester for Gentoo/FreeBSD
Equilibrium's Universe
all my contents are released under the Creative Commons Licence by-nc-nd 2.5 |
|
Back to top |
|
|
Ic3M4n Advocate
Joined: 02 Nov 2004 Posts: 3489 Location: Bergamo.
|
|
Back to top |
|
|
Scen Retired Dev
Joined: 29 Jul 2003 Posts: 2470 Location: Padova, Italy
|
Posted: Wed Oct 28, 2009 3:37 pm Post subject: |
|
|
E nel commento #5 viene proposta una soluzione temporanea, direi, semplicemente geniale
Daniel Pielmeier wrote: |
If you want correct md5sums you should consider adding something like this to
your /etc/portage/bashrc:
Code: |
post_src_install() {
echo "post_src_install: run lafilefixer ${D}"
lafilefixer "${D}"
echo ""
}
|
This way the libtool archives are fixed after the install phase and before
merging into the system. So the md5sums of the corrected *.la files are stored
and equery does not complain.
|
_________________ I was born in a deep forest/I wish I could live here all my life/I am made from stones and roots/My home, these woods and roads
All my life I loved this sound/Of the woods all around/Eagles flies where the winds blows free
Journey is my destiny |
|
Back to top |
|
|
cloc3 Advocate
Joined: 13 Jan 2004 Posts: 4787 Location: http://www.gentoo-users.org/user/cloc3/
|
Posted: Wed Oct 28, 2009 4:25 pm Post subject: |
|
|
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 _________________ vu vu vu
gentù
mi piaci tu |
|
Back to top |
|
|
!equilibrium Bodhisattva
Joined: 06 Jun 2004 Posts: 2109 Location: MI/BG/LC
|
Posted: Wed Nov 11, 2009 9:23 am Post subject: |
|
|
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) _________________ Arch Tester for Gentoo/FreeBSD
Equilibrium's Universe
all my contents are released under the Creative Commons Licence by-nc-nd 2.5 |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|