Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
GeCHI Weekly Report #2.07
View unanswered posts
View posts from last 24 hours
View posts from last 7 days

 
Reply to topic    Gentoo Forums Forum Index Forum italiano (Italian) Forum di discussione italiano
View previous topic :: View next topic  
Author Message
!equilibrium
Bodhisattva
Bodhisattva


Joined: 06 Jun 2004
Posts: 2109
Location: MI/BG/LC

PostPosted: Mon Feb 15, 2010 12:57 pm    Post subject: GeCHI Weekly Report #2.07 Reply with quote

Settimo report del 2010 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.

===

Benvenuti al settimo GeCHI Weekly Report del 2010, il quale fornisce sommari e notizie importanti relative allo sviluppo della distribuzione Gentoo del seguente periodo: 06.01.2010 - 12.01.2010.

[1] perl-5.10 spostato in unstable (14.02)
Tutti i pacchetti per dev-lang/perl:5.10 sono stati spostati da hard-masked a unstable per iniziare la fase finale di testing prima della stabilizzazione; tutti coloro che fossero interessati a contribuire alla fase di testing sono pregati di contattare l'herd Perl.

[2] Monthly Gentoo Council (08.02)
Lo scorso 8 Febbraio si è svolto il consueto incontro mensile del Consiglio Gentoo in cui si sono discussi i seguenti argomenti:
  • discussione GLEP 58 - Lo sviluppatore Robin Hugh Johnson ha apportato le modifiche richieste dal precedente meeting (per maggiori dettagli vedere il GWR #2.04) alla GLEP 58, la quale è stata approvata all'unanimità con la seguente roadmap:
    • aggiunta del supporto ai MetaManifest in emerge e Portage (categorie, metadata, eclass ecc);
    • aspettare 6-12 mesi prima di iniziare a rimuovere tutti i Manifest per ogni singolo pacchetto presente in Portage e in questo periodo definire ed estendere tutte le parti del MetaManifest ancora incomplete o che necessitano di maggiore testing;
    • rimuovere tutti i Manifest per ogni singolo pacchetto presente in Portage;
  • discussione GLEP 59 - Lo sviluppatore Robin Hugh Johnson ha apportato le modifiche richieste dal precedente meeting alla GLEP 59, la quale è stata approvata all'unanimità con la seguente roadmap:
    • aggiunta immediata degli hash WHIRLPOOL e SHA512;
    • rimozione immediata degli hash SHA1 e RIPEMD160;
    • modifica delle vecchie versioni dell'utility emerge affinché supporti soltanto gli hash attualmente disponibili in Portage, così da permettere il normale ciclo di aggiornamento per le vecchie installazioni;
  • discussione GLEP 60 - Lo sviluppatore Robin Hugh Johnson ha apportato le modifiche richieste dal precedente meeting alla GLEP 60, la quale è stata approvata all'unanimità con la seguente roadmap:
    • aggiunta immediata dei nuovi tipi di file previsti dalla GLEP per Manifest2;
    • per garantire la retrocompatibilità non verrà rimosso nessuno dei tipi di file, così da permettere il normale ciclo di aggiornamento per le vecchie installazioni;
  • discussione GLEP 61 - Lo sviluppatore Robin Hugh Johnson ha apportato le modifiche richieste dal precedente meeting alla GLEP 61, la quale è stata approvata dalla maggioranza dei membri del Consiglio; la compressione dei Manifest2 per singolo pacchetto non verrà aggiunta fino a quando l'implementazione delle GLEP 57, 58, 59 e 60 non sarà completa;
  • uno standard ufficiale per la cache VDB - i membri del Consiglio sono stati chiamati a votare sulla possibilità di introdurre ufficialmente in PMS uno standard che definisca le specifiche della cache VDB usata dai vari package manager di Gentoo, in quanto al momento ogni packager utilizza un formato differente rendendo di fatto tale cache non compatibile tra i vari package manager. La decisione finale è stata quella di non definire nessuno standard e di lasciare ogni dettaglio sull'implementazione della cache VDB direttamente ai corrispettivi sviluppatori dei vari package manager, così da garantire maggiore innovazione e libertà;

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

# Ben de Groot (yngwin [at] gentoo.org) (09 Feb 2010)
# Mask pending removal on 2010-03-09. Upstream dead, open bug #227717,
# alternatives exist (e.g. media-gfx/feh)
x11-misc/bbrb

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:

_________________
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
View user's profile Send private message
Apetrini
Veteran
Veteran


Joined: 09 Feb 2005
Posts: 1158

PostPosted: Tue Feb 16, 2010 5:11 pm    Post subject: Re: GeCHI Weekly Report #2.07 Reply with quote

!equilibrium wrote:
[*]uno standard ufficiale per la cache VDB - i membri del Consiglio sono stati chiamati a votare sulla possibilità di introdurre ufficialmente in PMS uno standard che definisca le specifiche della cache VDB usata dai vari package manager di Gentoo, in quanto al momento ogni packager utilizza un formato differente rendendo di fatto tale cache non compatibile tra i vari package manager. La decisione finale è stata quella di non definire nessuno standard e di lasciare ogni dettaglio sull'implementazione della cache VDB direttamente ai corrispettivi sviluppatori dei vari package manager, così da garantire maggiore innovazione e libertà;


L'ultima volta che ho parlato con zacmedico e compagnia è venuto fuori che l'ottimizzazione della cache VDB è un punto cruciale ed è strettamente legato(anche) a quel fastidiosissimo(diciamo) bug che colpisce certi tipi di aggiornamenti, in primis aggiornamenti delle qt e kde(ma anche cose minori...) .

Siccome molte soluzioni (teoriche) proposte per risolvere il codesto bug sono state scartate, tra cui:

1) Infilare informazioni aggiuntive negli ebuild che hanno bisogno di trattamenti particolari per via di vincoli particolari (credo che exherbo usi una soluzione di questo tipo; suggerisce al PM come districarsi/affrontare i blocchi).

2) Soluzioni ultra fantasiose come le installazioni a blocchi atomiche a mo' di acid (sql)...

3) Forzatura a ricalcolare l'intero grafico delle dipendenze, in modo da poter aiutare il PM a prendere la decisione giusta.(zac sostiene che se si facesse, emerge funzionerebbe bene con gli aggiornamenti "difficili").

Quest'ultimo punto è stato scartato solamente per il tempo necessario a svolgere tale operazione; se si facesse ogni volta cosi il PM sarebbe veramente lento a fare "qualsiasi cosa".

Ecco che rientra in gioco la cache VDB... dalle mie impressioni sembra che la speranza per il futuro sia quella di trovare un modo estremamente efficiente per fare caching e quindi magari usare la soluzione del punto 3...

C'è da dire anche che il morale non è dei migliori; nessuno dei 3 PM ha trovato una soluzione adeguata al problema del caching.
Se qualcuno ha qualche idea su come fare, invito a segnalare l'idea, anche perché qui non andiamo piu avanti...
_________________
Linux ape 2.6.31-vanilla. Paludis since 0.28.0.
Back to top
View user's profile Send private message
!equilibrium
Bodhisattva
Bodhisattva


Joined: 06 Jun 2004
Posts: 2109
Location: MI/BG/LC

PostPosted: Thu Feb 18, 2010 3:27 pm    Post subject: Re: GeCHI Weekly Report #2.07 Reply with quote

Apetrini wrote:
C'è da dire anche che il morale non è dei migliori; nessuno dei 3 PM ha trovato una soluzione adeguata al problema del caching. Se qualcuno ha qualche idea su come fare, invito a segnalare l'idea, anche perché qui non andiamo piu avanti...


è molto difficile elaborare un'idea e un algoritmo appropriato quando per due dei tre PM non esiste uno straccio di documentazione tecnica degli internal (per realizzare dei moduli addizionali) e ne tanto meno un'API ufficiale per estendere il PM; io prima di pensare al problema della cache, lavorerei su questo, così da dare la possibilità ad un numero maggiore di persone di collaborare attivamente allo sviluppo dei vari PM.
_________________
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
View user's profile Send private message
Apetrini
Veteran
Veteran


Joined: 09 Feb 2005
Posts: 1158

PostPosted: Thu Feb 18, 2010 4:53 pm    Post subject: Re: GeCHI Weekly Report #2.07 Reply with quote

!equilibrium wrote:

è molto difficile elaborare un'idea e un algoritmo appropriato quando per due dei tre PM non esiste uno straccio di documentazione tecnica degli internal (per realizzare dei moduli addizionali) e ne tanto meno un'API ufficiale per estendere il PM; io prima di pensare al problema della cache, lavorerei su questo, così da dare la possibilità ad un numero maggiore di persone di collaborare attivamente allo sviluppo dei vari PM.


Questo è un problema. Sono convinto che ci sia la necessità di avere delle API per fare(almeno) tutte le operazioni comuni; in questo modo i vari programmi di supporto userebbero le API e una modifica alla gestione di <qualcosa> non richiederebbe la riscrittura di n componenti. Questa è la strada piu ovvia e corretta per evitare ridondanza di codice(o addirittura implementazioni che danno risultati discordanti).

Comunque, giusto per essere chiari, paludis ha una discreta documentazione (non totalmente completa, no diagrammi di sequenza ne diagrammi di classi etc..., ma almeno c'è qualcosa). Si trova qui: http://paludis.pioto.org/trunk/api/cplusplus/index.html , ruby bindings http://paludis.pioto.org/trunk/api/ruby/classes/Paludis.html e python bindings http://paludis.pioto.org/trunk/api/python/index.html.

Un giorno mi sono intestardito su portage e ho trovato questo: http://dev.gentoo.org/~zmedico/portage/doc/ e http://dev.gentoo.org/~zmedico/portage/doc/api/ . Sarò anche un po' impedito ma di certo non lo hanno messo in bella vista...

Mi astengo dal fare qualsiasi commento su pkgcore perché, ad esser sincero, non mi sono mai curato di lui.
_________________
Linux ape 2.6.31-vanilla. Paludis since 0.28.0.
Back to top
View user's profile Send private message
!equilibrium
Bodhisattva
Bodhisattva


Joined: 06 Jun 2004
Posts: 2109
Location: MI/BG/LC

PostPosted: Sat Feb 20, 2010 9:35 am    Post subject: Re: GeCHI Weekly Report #2.07 Reply with quote

Apetrini wrote:
Mi astengo dal fare qualsiasi commento su pkgcore perché, ad esser sincero, non mi sono mai curato di lui.


pkgcore non ha una documentazione delle API, o meglio, esiste, ma è anche peggiore di quella di portage, il che è tutto dire... per questo ho detto che solo 2 PM hanno una doc: portage e paludis.

C'è anche da dire che non c'è molto da criticare lo sviluppo Portage, tutto il lavoro viene svolto da una sola persona: Zac Medico e lui fa quello che può per aggiungere le nuove feature del PMS il prima possibile; questo ovviamente va a discapito della documentazione, delle API e dei binding. Se qualche baldo sviluppatore italiano di python volesse contribuire si faccia avanti ;) Zac non dice mai di no a nessuno.

Altro punto dolente che manca in tutti i PM: non c'è integrazione con dbus; non sarebbe male avere le notifiche di quello che sta facendo il PM (ebuild phase) tramite dbus, così da permette lo sviluppo di applet e frontend avanzati per i vari DE.
_________________
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
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Forum italiano (Italian) Forum di discussione italiano All times are GMT
Page 1 of 1

 
Jump to:  
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