Gentoo Forums

Posted: **Sat Nov 14, 2009 8:36 pm**

Ottavo 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.8

Benvenuti all'ottavo GeCHI Weekly Report, il quale fornisce sommari e notizie importanti relative allo sviluppo della distribuzione Gentoo riguardanti il seguente periodo: 07.11.2009 - 13.11.2009.

[] kde-base/kdelibs-3* e kde-base/arts (10.11)
Continua inesorabile e senza sosta il processo di rimozione di kde:3 e Qt:3 da Portage, in particolare l'obbiettivo su cui gli sviluppatori di Gentoo si stanno maggiormente focalizzando ora è la rimozione di kde-base/kdelibs:3 e kde-base/arts entro la fine dell'anno 2009, compreso il masking della USE arts dai vari profili Gentoo (verrà rimossa definitivamente solo quando tutto kde 3.5.10 sarà stato eliminato). Rimuovere kde:3 e Qt:3 è anche un passo obbligatorio per un motivo molto semplice: tutti questi pacchetti non sono più mantenuti upstream da parecchio tempo e non funzionano con autoconf-2.64; mantenerli in Portage vorrebbe dire determinare una situazione che di fatto si tradurrebbe in un effetto domino catastrofico per tutti gli altri pacchetti presenti in Portage, infatti impedirebbero la stabilizzazione di autoconf-2.64 che a sua volta impedirebbe l'inserimento/stabilizzazione di nuovi pacchetti in Portage. La scelta più sensata quindi è quella di eliminarli da Portage (come stanno già facendo anche altre distribuzioni linux, per esempio Debian).

[] Stage 3 (Gentoo/Prefix) per Solaris 10 (10.11)
L'utente Tomasz Pawelczak ha reso disponibile uno stage3 nativo per Solaris 10 di Gentoo/Prefix; il pacchetto può essere scaricato qui e dopo la sua installazione, per usare Gentoo/Prefix in Solaris, è sufficiente eseguire il seguente comando:

Code: Select all

# /opt/gentoo/startprefix
# emerge --sync

[] Qt 4.5.3 stabilizzazione (10.11)
Dopo un lungo tira-e-molla Qt 4.5.3 è stato finalmente stabilizzato per le architetture ppc e ppc64; manca soltanto l'architettura hppa e poi Gentoo sarà la prima distribuzione Linux ad avere Qt 4.5.3 stabile per tutte le architetture maggiormente utilizzate.

[] Monthly Gentoo Council (09.11)
Il 9 novembre si è svolto l'incontro mensile del Consiglio Gentoo in cui si sono discussi i seguenti argomenti:

1. Linee di condotta per gli aggiornamenti di vecchie installazioni Gentoo - Per facilitare ulteriormente gli aggiornamenti di vecchie installazioni Gentoo si è proposto di regredire intenzionalmente il pacchetto sys-apps/portage e tutte le sue dipendenze ad EAPI0, in modo tale che sia possibile fare l'upgrade di una Gentoo box all'ultima release stabile disponibile direttamente da qualsiasi versione vecchia di portage (feature che le distribuzioni binarie non hanno); per garantire all'utente finale una maggiore efficienza di tutto il processo di migrazione, gli sviluppatori Gentoo hanno deciso di salvare periodicamente degli snapshot di portage e distfiles da usare internamente come base per i test di verifica degli aggiornamenti al fine di garantire che non sussistano problemi latenti per gli utenti; nei prossimi giorni questo discorso verrà esposto sulla ML degli sviluppatori al fine di definirne i dettagli, farne un progetto ufficiale Gentoo e stabilire dei leader che si sobbarchino l'onore e la responsabilità di portare avanti tale progetto;
2. Gentoo/Prefix inserito ufficialmente in portage - il consiglio ha deciso di inserire il supporto a Gentoo/Prefix direttamente in portage in modo da facilitare il lavoro degli sviluppatori del progetto Prefix, automatizzare alcuni task direttamente tramite emerge (e non tramite hack nelle varie eclass), nonchè permettere di avere ebuild con supporto nativo a Prefix direttamente nell'albero di portage; rinviata al prossimo meeting la decisione di implementare le specifiche di Prefix tramite EAPI2 oppure EAPI3 (ancora in fase di definizione);
3. Utilizzo delle funzioni avanzate di bash 3.2 in Portage - Il consiglio ha modificato Package Manager Specification (PMS) affinchè sia permesso l'utilizzo delle funzioni avanzate di =bash-3.2* negli ebuild/eclass; da notare che questa modifica non è volta ad apportare nuove migliorie a Portage, ma bensì a risolvere un problema di regole previste dal PMS che non sono state rispettate: già ora sia gli ebuild che le eclass fanno uso delle funzioni avanzate di bash 3.2, ma non ne è stata chiesta l'autorizzazione al Gentoo Council nonostante il PMS forzasse esplicitamente l'uso di =bash-3.0*, da qui la necessità di supperire al problema modificando le specifiche di PMS anzichè riconvertire svariate centinaia di ebuild e molte eclass;

[] USE 'cxx' abilitata di default (09.11)
Il team di sviluppo di Gentoo, per migliorare ulteriormente la qualità degli ebuild di Portage (grazie soprattutto all'adozione delle nuove feature messe a disposizione da EAPI2), sta discutendo un nuovo RFC che abiliterebbe globalmente la USE cxx di default, compresa la conversione della USE nocxx in cxx (con conseguente modifica degli ebuild che ne fanno uso).

[] Miglioramenti per package.mask (07.11)
Il team di sviluppo di Gentoo, per semplificare la manutenzione degli oltre 2000 pacchetti inseriti nel file /usr/portage/profiles/package.mask, sta discutendo delle nuove politiche di gestione per tale file, il quale verrebbe suddiviso in diversi file, ognuno dei quali adibito alla gestione di una specifica categoria di ebuild:

package.mask specifico per pacchetti beta/rc/alpha ;
package.mask specifico per pacchetti live;
package.mask specifico per last rites e la rimozione di pacchetti non funzionanti;
package.mask specifico per problemi di sicurezza (GLSA ecc);

Semplificando la gestione del file package.mask vorrebbe dire velocizzare di molto le operazioni di manutenzione dei pacchetti masked (più tempo risparmiato e quindi più tempo da dedicare a compiti più importanti), mantenere più pulito ed efficiente Portage, ma soprattutto migliorare la qualità degli ebuild a tutto vantaggio dell'utente finale.

[] Split ebuild per Intel Compiler Suite Professional Edition (07.11)
Per meglio sopperire alle esigenze degli utenti il team di sviluppatori di Gentoo sta discutendo la possibilità di avere una serie di split ebuild per la suite Intel Compiler Professional Edition (icc, ifc, mkl, ipp, tbb ecc), la quale è closed-source, ma free per uso non commerciale, e viene distribuita come un unico tarball monolitico contenente gli archivi RPM dei vari componenti della suite. Sfortunatamente Intel distribuisce parte di questi componenti (icc, ifc e tbb) anche come pacchetti separati, i cui tarball replicano le stesse librerie comuni, impedendo di fatto la creazione di split ebuild per il pacchetto dev-lang/icc a causa delle numerose collisioni e duplicazioni dei file; inoltre si obbliga l'utente finale ad installarsi l'intera suite (che sono parecchie librerie/eseguibili) per usare uno soltanto o solo una parte dei componenti della stessa.

L'unica soluzione al problema, senza incappare in funambolismi, è quella di ridistribuire gli RPM del tarball monolitico tramite i mirror Gentoo e basare i nuovi split ebuild su di essi anzichè i tarball ufficiali di Intel; al momento si sta verificando che non sussistano problemi di licenza a causa della ridistribuzione degli archivi RPM, ma se tutto volge per il meglio, presto gli utenti finali potranno beneficiare di versioni aggiornate e splitted della suite ICC.

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

# Samuli Suominen gentoo.org (13 Nov 2000)
# kde-base/kdelibs:3.5 reverse dependencies
# Bug #292791.
net-misc/kvpnc-0.9.3
media-tv/kdetv
media-tv/kvdr
net-wireless/kwlaninfo
net-misc/guidedog-1.1
net-misc/knutclient
net-misc/kovpn
net-misc/kwebget
net-analyzer/knetscan
net-analyzer/ksniffer
media-sound/amarokfs

# Samuli Suominen gentoo.org (13 Nov 2000)
# replaced by media-sound/kradioripper
media-sound/kstreamripper

# Markos Chandras gentoo.org (12 Nov 2009)
# Fails to build with recent kernels. Upstream doesn't
# support it anymore and it has been replaced by dazukofs
# (bug #278414)
sys-fs/dazuko

# Samuli Suominen gentoo.org (10 Nov 2009)
# Has kde-base/arts depend, and it can't be removed.
games-puzzle/quintalign
games-sports/kbilliards
games-strategy/kpictorial
games-util/krconlinux
games-puzzle/easysok
dev-perl/PerlQt
media-video/dpencoder
media-video/qvamps
media-video/asdf
dev-perl/DCOP
dev-perl/DCOP-Amarok
dev-perl/DCOP-Amarok-Player
sci-misc/kboincspy
x11-plugins/khexclock
x11-misc/lineak-kdeplugins
app-pda/libopensync-plugin-kdepim
app-laptop/kthinkbat

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;
YouTube: GeCHI Group;
FaceBook: GeCHI Group;
Digg: GeCHI Group | GeCHI RSS Feeds

Posted: **Sun Nov 15, 2009 11:31 am**

oRDeX wrote:3. Utilizzo delle funzioni avanzate di bash 3.2 in Portage - Il consiglio ha modificato Package Manager Specification (PMS) affinchè sia permesso l'utilizzo delle funzioni avanzate di =bash-3.2* negli ebuild/eclass; da notare che questa modifica non è volta ad apportare nuove migliorie a Portage, ma bensì a risolvere un problema di regole previste dal PMS che non sono state rispettate: già ora sia gli ebuild che le eclass fanno uso delle funzioni avanzate di bash 3.2, ma non ne è stata chiesta l'autorizzazione al Gentoo Council nonostante il PMS forzasse esplicitamente l'uso di =bash-3.0*, da qui la necessità di supperire al problema modificando le specifiche di PMS anzichè riconvertire svariate centinaia di ebuild e molte eclass;

Perché non passare direttamente a bash-4? È stabile su tutte le architetture già da un po' ormai.

USE 'cxx' abilitata di default (09.11)
Il team di sviluppo di Gentoo, per migliorare ulteriormente la qualità degli ebuild di Portage (grazie soprattutto all'adozione delle nuove feature messe a disposizione da EAPI2), sta discutendo un nuovo RFC che abiliterebbe globalmente la USE cxx di default, compresa la conversione della USE nocxx in cxx (con conseguente modifica degli ebuild che ne fanno uso).

Mi spiegate come una USE diversa migliora la qualità degli ebuild, e cosa comporta questa USE?

[] Split ebuild per Intel Compiler Suite Professional Edition (07.11)
Per meglio sopperire alle esigenze degli utenti il team di sviluppatori di Gentoo sta discutendo la possibilità di avere una serie di split ebuild per la suite Intel Compiler Professional Edition (icc, ifc, mkl, ipp, tbb ecc), la quale è closed-source, ma free per uso non commerciale, e viene distribuita come un unico tarball monolitico contenente gli archivi RPM dei vari componenti della suite. Sfortunatamente Intel distribuisce parte di questi componenti (icc, ifc e tbb) anche come pacchetti separati, i cui tarball replicano le stesse librerie comuni, impedendo di fatto la creazione di split ebuild per il pacchetto dev-lang/icc a causa delle numerose collisioni e duplicazioni dei file; inoltre si obbliga l'utente finale ad installarsi l'intera suite (che sono parecchie librerie/eseguibili) per usare uno soltanto o solo una parte dei componenti della stessa.

Comincia a prendere senso la possibilità di usare ICC al posto di GCC o rimane ancora in quasi ogni situazione un'inutile complicazione?

Posted: **Sun Nov 15, 2009 7:55 pm**

riverdragon wrote:Perché non passare direttamente a bash-4? È stabile su tutte le architetture già da un po' ormai.

Assolutamente no. Si è discusso all'ultimo gentoo council meeting e probabilmente saranno tassativamente vietate tutte le fetaures >bash-3.2.
Portare tutto a bash-4 non è fattibile per una serie di ragioni, tra cui garantire a installazioni vecchie fino a 2 anni di poter riuscire a fare gli aggiornamenti.
Per dirla tutta l'uso di bash-3.2, fino a qualche giorno fa non era permesso, ma la realtà era che già da alcuni anni c'erano ebuild che usufruivano di funzionalità di bash 3.2. Quello che si sarebbe dovuto fare era riscrivere una buona fetta degli ebuild in modo che usino soltanto le funzionalità di bash 3.0, questo sarebbe stato una grosso lavoro, perciò si è deciso di "approvare" le funzionalità di bash-3.2 e di vietare tutte quelle >3.2.
Le regole ci sono, sono stilate/votate/approvate e bisogna rispettarle(altirmenti è il far west); Il consiglio ha votato anche sulle misure da adottare qualora qualche furbone usasse funzionalità non permesse: da come l'hanno posta durante il meeting sembra che "cascasse il mondo, ogni ebuild che usa funzionalità non ammesse, dovrà essere riscritto e riadattato". Non si vuole piu ignorare il problema com'è successo tempo fa.

riverdragon wrote:Comincia a prendere senso la possibilità di usare ICC al posto di GCC o rimane ancora in quasi ogni situazione un'inutile complicazione?

Direi la seconda, usare ICC si puo, ma è solo un bed test, non è supportato in alcun modo e non credo che lo sarà. La questione è sugli ebuild, perché si sta cercando di "fare una scelta intelligente" per gli utilizzatori di ICC (e con questo non si intende per gli utilizzatore di ICC che vogliono compilare tutto il sistema con ICC)...

Posted: **Mon Nov 16, 2009 12:17 pm**

Apetrini wrote:Portare tutto a bash-4 non è fattibile per una serie di ragioni, tra cui garantire a installazioni vecchie fino a 2 anni di poter riuscire a fare gli aggiornamenti.

esatto, lo scopo della regola =bash-3.2* è quello di garantire l'aggiornamento all'ultima stable anche alle installazioni vecchie; forzare bash 4 impedirebbe a coloro che hanno installazioni vecchie (si ritrovano con bash 3 in locale) di leggere gli ebuild perchè portage non riuscirebbe a farne il "source".

Lo scopo della regola va visto anche nell'ottica del punto 1 "Linee di condotta per gli aggiornamenti di vecchie installazioni Gentoo", il cui obiettivo è permettere ad installazioni molto vecchie di fare l'update anche oltre i canonici 2 anni previsti dal PMS; come? semplicemente verrà reso pubblica una pagina web che spiegherà gli eventuali passaggi necessari per l'update per ogni ciclo di rilascio di portage, mi spiego meglio, supponiamo che qualcuno ha un'installazione Gentoo vecchia di 8 anni e mai aggiornata, teoricamente non è possibile fare l'update all'ultima release stabile perchè portage non è retrocompatibile se non per gli ultimi 2/3 anni. Ecco quindi che gli sviluppatori di Gentoo faranno ciclicamente degli snapshot di portage+distfiles che verranno usati per fare dei test e simulare gli aggiornamenti di vecchie installazioni Gentoo, da cui poi trarranno una serie di istruzioni passo passo per ogni ciclo di rilascio e rese pubbliche tramite un'apposita pagina web, qualcosa del tipo:

[1] istruzioni upgrade da versione X a versione X+2anni
Devi fare questo e quello, blablabla

[2] istruzioni upgrade da versione X+2anni a versione X+4anni
Devi fare questo e quello, blablabla

[3] istruzioni upgrade da versione X+4anni a versione X+6anni
Devi fare questo e quello, blablabla

[4] istruzioni upgrade da versione X+6anni a versione X+8anni
Devi fare questo e quello, blablabla

e l'utonto pigro è servito.

se, e ripeto SE, i devel manterranno questa promessa, Gentoo sarà l'unica distro al mondo che potrà essere aggiornata partendo da qualsiasi vecchia versione di portage; tutte le altre distro linux hanno cicli di rilascio di 2/3 anni e non sono retrocompatibili, devi per forza di cose reinstallare tutto da capo.

Apetrini wrote:Quello che si sarebbe dovuto fare era riscrivere una buona fetta degli ebuild in modo che usino soltanto le funzionalità di bash 3.0, questo sarebbe stato una grosso lavoro, perciò si è deciso di "approvare" le funzionalità di bash-3.2 e di vietare tutte quelle >3.2.

oltre alla questione tempo c'era anche il discorso di dover fare Nmila commit nel repository cvs, fare tonnellate di downgrade e re-keywording degli ebuild, situazione che avrebbe sicuramente fatto girare le palle a molti utenti

a causa delle inutili e continue compilazioni.

Apetrini wrote:Le regole ci sono, sono stilate/votate/approvate e bisogna rispettarle(altirmenti è il far west); Il consiglio ha votato anche sulle misure da adottare qualora qualche furbone usasse funzionalità non permesse: da come l'hanno posta durante il meeting sembra che "cascasse il mondo, ogni ebuild che usa funzionalità non ammesse, dovrà essere riscritto e riadattato". Non si vuole piu ignorare il problema com'è successo tempo fa.

e questa volta ci è andata di lusso perchè bash3.2 può essere letto anche dal vecchio bash3.0 in global space, se non fosse stato così si sarebbe per forza di cose dovuto fare il downgrade e la riscruttura di molte eclass/ebuild; mi auguro quindi che per il prossimo meeting vengano decise misure più severe per i trasgressori (tipo bannarli come devel visto che non agiscono in modo "comunitario", ma preferiscono fare i "cowboy fuorilegge") e che vengano migliorati i quiz per la reclutazione di nuovi devel.

riverdragon wrote:Mi spiegate come una USE diversa migliora la qualità degli ebuild, e cosa comporta questa USE?

è un discorso parecchio lungo e complesso, non so se riesco a spiegartelo qui sul forum: teoricamente dovresti sapere cosa è nocxx, perchè esiste e come va usata; per semplificare ai minimi termini, storicamente non era possibile avere la USE 'cxx' per questioni puramente tecniche (limiti di portage), quindi si è optato per nocxx e tutta una serie di workaround e dirty-hack sparsi un po qua e un po la. Oggi invece sarebbe possibile avere la USE cxx senza nocxx (rinominandola in cxx e modificando il comportamento degli ebuild) così da non avere più in giro workaround da mantenere ed ottenere allo stesso tempo la flessibilità della USE cxx (che non si può avere ora con la USE nocxx).

Posted: **Mon Nov 16, 2009 2:35 pm**

Capite entrambe le questioni (bash e cxx), grazie. Per quanto riguarda gli aggiornamenti da sistemi molto vecchi non penso si potrebbero criticare i devel se decidessero di mettere un "mezzo blocco" per dire a coloro che hanno un sistema vecchio di 3-4 anni che per la loro salute mentale è seriamente consigliato reinstallare.

Posted: **Mon Nov 16, 2009 2:44 pm**

onestamente, chi può avere un sistema così vecchio?

Posted: **Mon Nov 16, 2009 4:13 pm**

Io uso gentoo da tre anni e mezzo, ma sarei curioso di sapere a che versioni erano i principali software 4, 6 o otto anni fa!

Posted: **Mon Nov 16, 2009 9:54 pm**

non so se è una cagata, ma qualcuno a pensato di rendere gli ebuild posix compatibili? alla barba di bash...

per la storia della retrocompatibilià, ho qualche dubbio, ma è davvero importante l'aggiornamento di sistemi di Nmila anni fa? caspita, se nessuno impegna preziose risorse per progettare questa cosa, un motivo ci sarà? mah...

riguardo la rimozione di kde3, forse questa è la volta buona che cloc3 lascia gentoo

Posted: **Tue Nov 17, 2009 7:24 am**

lucapost wrote:non so se è una cagata, ma qualcuno a pensato di rendere gli ebuild posix compatibili? alla barba di bash...

per la storia della retrocompatibilià, ho qualche dubbio, ma è davvero importante l'aggiornamento di sistemi di Nmila anni fa? caspita, se nessuno impegna preziose risorse per progettare questa cosa, un motivo ci sarà? mah...

riguardo la rimozione di kde3, forse questa è la volta buona che cloc3 lascia gentoo

Non so cloc3, ma anche io sono molto incazz per la rimozione di kde3, kde4 è tutto fumo e arrosto molto poco! Mi scappa di paragonarlo a Vista nel mondo Microsoft. KDE4 non lo sopporto!
Ma lasciare Gentoo è un passo che non mi sognerei mai di fare. Per ora...

Tornando IT, se uno non ha aggiornato da anni, forse non ha intenzione di aggiornara la sua Gentoo.

Forse impegnare tanti sforzi solo per essere "l'unica distro al mondo che ti permette di..." mi pare un po' uno spreco.
Tutto questo IM(V^n)HO

Posted: **Tue Nov 17, 2009 10:10 am**

devilheart wrote:onestamente, chi può avere un sistema così vecchio?

forse per te sarà sconcertante, ma è una feature molto richiesta, soprattutto da chi usa Linux internamente in azienda sui server (server veri, non i pc adibiti a server casalinghi) dove gli update non si fanno perchè sono inutili (il server non è pubblico) e farli ciclicamente sono costi elevati per le aziende medio/grandi (perchè i software aziendali closed che ci girano sopra andrebbero ri-testati ad ogni update, cosa impensabile per un'azienda visti i costi stratosferici); in genere in questi scenari non si aggiorna la macchina (funziona tutto, perchè complicarsi la vita?) anche perchè i software proprietari hanno cicli di rilascio molto lunghi tra un update e l'altro, quindi non funzionano con le versioni aggiornate delle distro e si aspetta qualche anno prima di fare il salto nel buio, cioè lo si fa quando esce una nuova release del software closed-source che serve realmente all'azienda.

@devilheart glielo spieghi tu alle aziende che è meglio spendere ogni anno 250.000€ di aggiornamenti vari per le licenze SAP piuttosto che spendere qualche migliaia di euro per la tua consulenza, una tantum (2/3 anni), affinchè tu faccia l'aggiornamento delle installazioni linux solo quando necessario? provaci e se riesci a conservare il posto di lavoro ti offro una vacanza 6 stelle, tutta spesata, alle maldive per un anno

p.s.: se siete quelli che pensano "linux in azienda = printer/fax/file server" allora siete un branco di bamboccioni (scusate il termine, ma avete davvero le fette di salame sugli occhi), perchè quella non è nemmeno la punta dell'iceberg; giocare con il piccolo chimico non fa di voi un eminente scienziato.

riverdragon wrote:Io uso gentoo da tre anni e mezzo, ma sarei curioso di sapere a che versioni erano i principali software 4, 6 o otto anni fa!

lucapost wrote:per la storia della retrocompatibilià, ho qualche dubbio, ma è davvero importante l'aggiornamento di sistemi di Nmila anni fa? caspita, se nessuno impegna preziose risorse per progettare questa cosa, un motivo ci sarà? mah...

bandreabis wrote:Tornando IT, se uno non ha aggiornato da anni, forse non ha intenzione di aggiornara la sua Gentoo.

non avete capito una fava di quello che ho scritto, il mio esempio di 8 anni era solo un esempio e non era riferito al passato: la gentoo di oggi (2009) NON sarà retrocompatibile con le versioni del passato di portage (quelle rilasciate tra l'anno 1999 e il 2009), ma IN FUTURO, sarà possibile fare gli upgrade da una versione qualsiasi di portage successiva a quella in cui il progetto di retro-compatibilità è partito (quindi al massimo partendo da novembre 2009, o dalla data in cui partirà sto benedetto progetto) fino all'ultima versione stabile, il tutto tramite degli upgrade guidati e graduali; esempio: gentoo installata nel 2009, ma siamo nell'anno 2014 e vogliamo aggiornare all'ultima stabile = fai l'aggiornamento di portage all'ultima stabile (2014), ma siccome hai superato 2 volte i 2 anni previsti dal ciclo di rilascio di portage (2009 +2 = 2011 + 2 = 2013) sicuramente i file di configurazione di Gentoo e/o di portage possono essere cambiati (ma non è detto!), quindi vai sulla pagina web con le istruzioni passo passo per gli upgrade retro-compatibili che ho accennato nel GWR e modifichi quello che ti suggerirà tale guida (sempre che ci sia da modificare qualcosa), fine.

bandreabis wrote:Forse impegnare tanti sforzi solo per essere "l'unica distro al mondo che ti permette di..." mi pare un po' uno spreco. Tutto questo IM(V^n)HO

veramente è tutto automatizzato tramite script, quindi dal punto di vista prettamente umano, l'impegno da devolvere in questa iniziativa è prossimo allo zero: il team di sviluppo di portage già ora fa i test di retro-compatibilità (validi per 2 anni), ciò che cambierà è che dovranno mettere sulla pagina web le eventuali modifiche che ho accennato prima, tipo il passaggio da baselayout1 vs baselayout2 vs openrc vs $qualsiasi_altra_cosa_ci_sarà_in_futuro vs $nuovo_sistema_di_init_imposto_da_una_razza_aliena_che_nel_3009_ci_starà_schiavizzando.

L'utonto come fa a sapere cosa è stato modificato dalla sua storica installazione ad oggi se nessuno glielo dice? i messaggi di elog non forniscono queste informazioni e se hai "latitato" per anni, non sei al corrente delle modifiche e se stai usando Gentoo in produzione ti girano le balle dover rifare tutto da capo, soprattutto se hai TB di dati da convertire e/o ripristinare (come per i DB tipo postgres dove al cambio di release bisogna riconvertire tutto il DB con un dump+restore).

p.s.: le distro commerciali come redhat (non fedora!) e novell hanno la totale retrocompatibilità (tramite una GUI point&click che fa tutto il lavoro per voi), ma è un servizio che costa svariate migliaia di euro, all'anno; voi l'avreste, gratis e senza sforzo da parte dei devel Gentoo e vi lagnate pure; praticamente state sputando nel piatto in cui mangiate

bravi!

bandreabis wrote:Non so cloc3, ma anche io sono molto incazz per la rimozione di kde3, kde4 è tutto fumo e arrosto molto poco! Mi scappa di paragonarlo a Vista nel mondo Microsoft. KDE4 non lo sopporto!

kde:3, qt:3 saranno in un overlay per quelli che vogliono continuare ad usarli. Questa è l'unica soluzione, altrimenti, appena autoconf-2.64 viene stabilizzato (fra poco, come ho scritto nel GWR), i devel Gentoo, per poter tenere kde:3 in portage dovrebbero mascherarlo e obbligarvi a fare il downgrade alla versione precedente, cioè kde:2. Siete sicuri di volere una situazione del genere? avere kde:3 nell'overlay vi permette di evitare inutili downgrade ed isterie di massa, senza obbligare i devel Gentoo a funanbulismi inutili per non farvi eseguire "latman -a <overlay>". Su via, un po di serietà

Posted: **Tue Nov 17, 2009 11:47 am**

!equilibrium wrote:
bandreabis wrote:Non so cloc3, ma anche io sono molto incazz per la rimozione di kde3, kde4 è tutto fumo e arrosto molto poco! Mi scappa di paragonarlo a Vista nel mondo Microsoft. KDE4 non lo sopporto!
kde:3, qt:3 saranno in un overlay per quelli che vogliono continuare ad usarli. Questa è l'unica soluzione, altrimenti, appena autoconf-2.64 viene stabilizzato (fra poco, come ho scritto nel GWR), i devel Gentoo, per poter tenere kde:3 in portage dovrebbero mascherarlo e obbligarvi a fare il downgrade alla versione precedente, cioè kde:2. Siete sicuri di volere una situazione del genere? avere kde:3 nell'overlay vi permette di evitare inutili downgrade ed isterie di massa, senza obbligare i devel Gentoo a funanbulismi inutili per non farvi eseguire "latman -a <overlay>". Su via, un po di serietà

Naturalmente non era un incazz verso i devels!

Ma contro KDE4.

I devel Gentoo sono i miei preferiti da taaanti anni!

Posted: **Tue Nov 17, 2009 11:57 am**

bandreabis wrote:Non so cloc3, ma anche io sono molto incazz per la rimozione di kde3

Ma non viene RIMOSSO!

Viene spostato nell'overlay kde-sunrise, per i motivi tecnici elencati da !equilibrium!

Cari KDE3-addicted, non avete + scuse per lamentarvi e arrampicarvi sugli specchi

un'ex utente KDE3

Posted: **Tue Nov 17, 2009 1:18 pm**

Anche io sono addetto a kde3!
Se trovassi su KDE4 quello che avevo su KDE3 allora non avrei problemi... ma KDE4 sembra un abbozzo, un accrocchio.

E, ribadisco ancora una volta, non è certo colpa di Gentoo.

PS. io ho provato ad usare l'overlay ma dava blocchi con non ricordo cosa.... forse con kde3 e le sue dipendenze fuori da portage (non so ora a che punto siano, ma quando l'ho provato erano in portage entrambi gli slot) le cosa migliorano.

In ogni caso voglio continuare a dare possibilità a KDE4 anche se le cose non sembrano molto meglio con le versioni in testing.

Posted: **Tue Nov 17, 2009 2:09 pm**

bandreabis wrote: In ogni caso voglio continuare a dare possibilità a KDE4 anche se le cose non sembrano molto meglio con le versioni in testing.

Anche io spero in un miglioramento di kde4. Molte funzionalità sono state tolte. Ark ora non supporta più gli archivi splittati e quelli protetti da password. mentre ark in kde3 li supportava. Nonostante ci siano richieste nel bugzilla, nessuno le caga.
Secondo me fino a kde4.6 la situazione non cambierà di molto, generalmente parlando di kde4

Posted: **Tue Nov 17, 2009 7:48 pm**

Scen wrote: Ma non viene RIMOSSO!

purtroppo sì. viene rimosso.
infatti non sarà più presente in portage.

a breve, installare kde3.* diventerà progressivamente più difficoltoso: le dipendenze risulteranno irresolubili e le incompatibilità con altre parti del sistema, giù giù fino al kernel, faranno il resto. ma proprio questo è il motivo per cui la decisione dei devel (mio malgrado) è corretta. il supporto a kde3 è rimosso upstream, per gentoo non c'è nulla da fare. possessori di macchine vecchie, acquistate nuova ram.

un'ex utente KDE3

Posted: **Tue Nov 17, 2009 7:55 pm**

Certi che 'sti piagnoni di KDE3 sono proprio monotoni :-D

KDE3 esiste ancora, basta usare l'overlay opportuno :-o
KDE3 funziona anche con hardware recente, è solo un DE ;-)
KDE3 non è ancora stato (ancora) dichiarato fuorilegge 8-]

Vi trovate bene con il 3? Usatelo.
Non vi piace KDE4? Non usatelo.

Posted: **Tue Nov 17, 2009 9:28 pm**

xdarma wrote:Certi che 'sti piagnoni di KDE3 sono proprio monotoni

non ci sto.
un software instabile viene imposto in sostituzione di uno stabile e collaudato, con danni precisi per gli utenti.

capisco i cento motivi, buoni o cattivi per cui questo accade.
so anche che oramai il motore è avviato e non c'è modo di tornare indietro (forse non ha neppure senso).
ma lasciaci questa la libertà di lagnarci apertamente.

Posted: **Tue Nov 17, 2009 9:40 pm**

cloc3 wrote:un software instabile

instabile != che non risponde alle proprie esigenze.

Io ho cominciato ad usare KDE4, sin dalla 4.0: ok, fino alla 4.2 c'erano degli aspetti da sistemare, in quanto a stabilità. Ora sto usando la versione 4.3.1 (e la 4.3.3 in un sistema parallelo in testing), e, personalmente, mi funziona tutto egregiamente!

cloc3 wrote:a breve, installare kde3.* diventerà progressivamente più difficoltoso: le dipendenze risulteranno irresolubili e le incompatibilità con altre parti del sistema

Mi sembri eccessivamente pessimista, riguardo a questo aspetto: le ebuild relative a KDE-3.5* (funzionanti) sono stati fisicamente spostati in un repository esterno a Portage, e i pacchetti da cui dipende l'ecosistema KDE-3.5.10 penso resteranno dove sono ora, almeno per un bel pò, x cui non vedo dove sia il problema (se non eventuali problemi di sicurezza o bug esistenti nei programmi del mondo KDE3)

Con questo chiudo la mia diatriba da ex-KDE3 user vs KDE3 disciples

Posted: **Tue Nov 17, 2009 11:59 pm**

oRDeX wrote:[] kde-base/kdelibs-3* e kde-base/arts (10.11)
Continua inesorabile e senza sosta il processo di rimozione di kde:3 e Qt:3 da Portage, in particolare l'obbiettivo su cui gli sviluppatori di Gentoo si stanno maggiormente focalizzando ora è la rimozione di kde-base/kdelibs:3 e kde-base/arts entro la fine dell'anno 2009, compreso il masking della USE arts dai vari profili Gentoo (verrà rimossa definitivamente solo quando tutto kde 3.5.10 sarà stato eliminato). Rimuovere kde:3 e Qt:3 è anche un passo obbligatorio per un motivo molto semplice: tutti questi pacchetti non sono più mantenuti upstream da parecchio tempo e non funzionano con autoconf-2.64; mantenerli in Portage vorrebbe dire determinare una situazione che di fatto si tradurrebbe in un effetto domino catastrofico per tutti gli altri pacchetti presenti in Portage, infatti impedirebbero la stabilizzazione di autoconf-2.64 che a sua volta impedirebbe l'inserimento/stabilizzazione di nuovi pacchetti in Portage. La scelta più sensata quindi è quella di eliminarli da Portage (come stanno già facendo anche altre distribuzioni linux, per esempio Debian).

Vi informo che ho appena messo online la NUOVA guida all'installazione e configurazione di KDE in Gentoo:

http://www.gentoo.org/proj/it/desktop/k ... -guide.xml

che sostituisce la precedente (ora marcata come obsoleta) http://www.gentoo.org/proj/it/desktop/k ... config.xml

E' stato aggiornato di conseguenza anche l'indice della documentazione

Infine è stata rimossa la guida alle ebuild "split" di KDE, in quanto non più utile.

Good night

Posted: **Wed Nov 18, 2009 6:37 am**

Certo che usare bastone e carota con scen è proprio strano, ma tant'è...

bastone:
instabile != che non risponde alle proprie esigenze.

Un software che aggiunge mille eye-candy e poi rimuove funzioni rispetto al suo predecessore ti pare una bella cosa?
Sì, non risponde alla mie esigenze, e ci mancherebbe altro.
Ripeto, a me KDE4 pare tanto un accrocchio "vistoso"!!

carota:
grande! Grazie 1000 per la traduzione del doc!

Detto questo... spero di non beccarmi bastonate sulla testa!

Posted: **Wed Nov 18, 2009 9:18 am**

bandreabis wrote:Un software che aggiunge mille eye-candy e poi rimuove funzioni rispetto al suo predecessore ti pare una bella cosa? Sì, non risponde alla mie esigenze, e ci mancherebbe altro.
Ripeto, a me KDE4 pare tanto un accrocchio "vistoso"!!

giusto per condividere con voi alcuni numeri (io uso KDE4.3.3 minimal) e mettere un po di fine alle leggende metropolitane:
- KDE4 senza semantic desktop (basta levare la USE e disabilitare nepomuk/strigi) e senza plasma/plasmoidi a freddo mi consuma 230MB, dopo 8 ore di utilizzo sono mediamente sui 500/600MB;
- KDE3 a freddo mi consuma 128MB e dopo 8 ore di utilizzo sono mediamente sui 700/800MB;
- gnome2 a freddo mi consuma 400MB e dopo 8 ore di utilizzo sono mediamente sui 700/800MB;
- gnome3 a freddo mi consuma 480MB e dopo 8 ore di utilizzo sono mediamente sui 600/700MB;

il consumo di memoria è quella effettivamente allocata escludendo cache e buffer, non ci sono altri servizi che girano sulla macchina eccetto il DE e ho usato tutti i vari DE nelle medesime condizioni di lavoro: firefox con oltre 40 tab aperti "flashosi" e "javosi", netbeans/eclipse e qualche sporadica utility KDE, per tutto il resto in genere mi basta la console.

Ciò che consuma molto in KDE4 non sono gli "eye-candy" (gli effetti grafici accellerati in OpenGL) come qualcuno sostiene, ma bensì i plasmoidi; l'eye-candy, se l'utente dispone di una decente GPU, è interamente a carico della GPU e della sua RAM (io uso KDE4 su una schifosissima Intel con memoria condivisa e non ho problemi); l'era in cui le Qt consumavano più ram di GTK+ è finita nel lontano 2007, quando è stata rilasciata per la prima volta Qt:4; vi anticipo già che quando verrà rilasciato ufficialmente il branch Qt4.6 potrete beneficiare di un'ulteriore riduzione del consumo di ram pari al 15/30% a seconda dei casi (uso Qt per lavoro da quando esisteva ancora Qt:2 e sono Partner di Trolltech/Nokia dal 2000, quindi ho accesso alle preview molto prima degli altri) e un notevole incremento delle performance generali (se non sarà in Qt 4.6, lo sarà per Qt4.7, cioè si avrà la possibilità di accellerare interamente le UI tramite OpenGL, senza gravare quindi sulla CPU).

Ovviamente KDE4 non è perfetto e tenete bene a mente che se cercate un ambiente di lavoro *sempre* funzionante, affidabile e completo, allora quello è Gnome che è, e continua ad essere, il DE ufficiale per praticamente tutte le distro commerciali/binarie linux (visto che garantisce la retrocompatibilità); come qualcuno ha già detto in precedenza, molto probabilmente bisognerà aspettare kde 4.6 e oltre per avere tutte le feature promesse.

Posted: **Wed Nov 18, 2009 9:47 am**

Oppure tenere KDE3.
Io non ho problemi con eye-candy o con plasmoidi. Uso i secondi e snobbo i primi.
Il problema è solo la ciccia, non il fumo. E della ciccia che trovavo in KDE3, in KDE4 non trovo più nulla (beh, nulla nulla, no).

Posted: **Wed Nov 18, 2009 10:43 am**

Scen wrote:Con questo chiudo la mia diatriba da ex-KDE3

hai ragione.
la diatriba è decisamente sul filo del off-topic.

tuttavia, si discute di una trasformazione importante in un mondo dove i cambiamenti si stanno facendo davvero vertiginosi.
non mi ritengo pessimista ad affermare che, quando un software viene congelato fuori portage per dichiarata quiscenza, sia molto meglio mettersi il cuore in pace.

non è solo kde che si trasforma: sul fronte desktop, i cambiamenti maggiori avvengono in profondità.
a livello server e a livello drivers.
siamo tutti contenti di non doverci più configurare a mano il famigerato xorg.conf, ma ogni piccolo vantaggio ha il suo costo, di cui a volte sfugge l'entità.
lo stesso kernel e gli strumenti di più basso livello mutano quotidianamente. l'altro giorno, ho dovuto rinunciare ad utilizzare un sistema configurato con kernel 2.6.26* perché lo volevo lanciare con un una initramfs costruita per il 2.6.31*.

evoluzione, nel mondo linux, significa anche incremento della complessità. la comunità oramai, non è solo rappresentata dai suoi utenti e dai suoi sviluppatori, ma sono ogni giorno più importanti gli interventi, anche a gamba tesa, delle grandi major multinazionali. così, il sospetto che alcuni sviluppi tacciati per innovazione e progresso siano in parte frutto di imposizioni mirate a interessi diversi da quelli dell'utenza non è polemica sterile, ma spunto di riflessione attiva e concreta.

proprio in questo topic si presenta il progetto di pianificazione degli upgrade di portage e il tema di rispetto delle compatibilità a ritroso. sono sicuro che, se a kde si fosse usata la stessa impostazione dei nostri devel, si sarebbe investito tanto tanto di più sullo split delle kdelibs e sul miglioramento di khtml (o sul passaggio a webkit), prima che sulle feature di kwin o di nepomuk, ovvero (per riprendere un tema a me caro) sull'integrazione di konqueror in kde, piuttosto che sull'affrancamento di kde da konqueror.

ecco, in questa vicenda io non ci vedo solo la mera polemica sul fatto di specie, ma qualcosa che può (o che deve) accadere un po' dovunque nel software libero, di cui è bene parlarsi per restare in campana. forse anche per questo i contributi e le integrazioni tecniche che sono seguite alle nostre provocazioni non sembrano vuote di contenuto.

Posted: **Wed Nov 18, 2009 11:30 am**

bandreabis wrote:Oppure tenere KDE3.
Io non ho problemi con eye-candy o con plasmoidi. Uso i secondi e snobbo i primi.
Il problema è solo la ciccia, non il fumo. E della ciccia che trovavo in KDE3, in KDE4 non trovo più nulla (beh, nulla nulla, no).

Per curiosità, posso sapere cosa usavi in kde3 che non funziona/non trovi in kde4?

Posted: **Wed Nov 18, 2009 11:48 am**

Ora sto sbattendo contro il bluetooth che non mi permette di esplorare il mio cell. Su kde3, kdebluetooth girava "nativamente", kbluetooth no.

Gentoo Forums

GeCHI Weekly Report #1.8

GeCHI Weekly Report #1.8

Re: GeCHI Weekly Report #1.8

Re: GeCHI Weekly Report #1.8

Re: GeCHI Weekly Report #1.8

Re: GeCHI Weekly Report #1.8