# GeCHI Weekly Report #1.8

## oRDeX

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:

```

# /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 FeedsLast edited by oRDeX on Sun Nov 15, 2009 1:58 pm; edited 1 time in total

----------

## riverdragon

 *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.

 *Quote:*   

> 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?

 *Quote:*   

> [] 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?

----------

## Apetrini

 *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)...

----------

## !equilibrium

 *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   :Laughing:  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).

----------

## riverdragon

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.

----------

## devilheart

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

----------

## riverdragon

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!   :Very Happy: 

----------

## lucapost

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   :Laughing: 

----------

## bandreabis

 *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...   :Twisted Evil: 

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

----------

## !equilibrium

 *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  :Rolling Eyes: 

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   :Laughing:  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à   :Rolling Eyes: 

----------

## bandreabis

 *!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!    :Wink: 

Ma contro KDE4.

I devel Gentoo sono i miei preferiti da taaanti anni!   :Cool: 

----------

## Scen

 *bandreabis wrote:*   

> Non so cloc3, ma anche io sono molto incazz per la rimozione di kde3

 

Ma non viene RIMOSSO!  :Evil or Very Mad: 

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  :Twisted Evil:   :Twisted Evil:   :Twisted Evil: 

un'ex utente KDE3  :Cool: 

----------

## bandreabis

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.

----------

## lordalbert

 *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

----------

## cloc3

 *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   :Sad: 

----------

## xdarma

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.

----------

## cloc3

 *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.

 :Exclamation: 

----------

## Scen

 *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   :Cool: 

----------

## Scen

 *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/kde/kde4-guide.xml

che sostituisce la precedente (ora marcata come obsoleta) http://www.gentoo.org/proj/it/desktop/kde/kde-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  :Cool: 

----------

## bandreabis

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

bastone:

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

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!   :Very Happy: 

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

----------

## !equilibrium

 *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.

----------

## bandreabis

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).

----------

## cloc3

 *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.

----------

## lordalbert

 *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?

----------

## bandreabis

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

----------

## !equilibrium

 *bandreabis wrote:*   

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

 

... e guarda caso, entrambi non fanno parte della suite KDE4 ne tanto meno sono sotto il controllo di KDE eV  :Rolling Eyes: 

----------

## devilheart

 *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!  

 intendevo, chi è quel matto che non aggiorna da più di 3 anni e pretende che l'aggiornamento funzioni sempre e comunque?

 *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!
> 
> Ma lasciare Gentoo è un passo che non mi sognerei mai di fare. Per ora...   

 beh, non puoi di certo restare su un sistema quando non sono più mantenuti né il sistema ne le librerie per farlo andare

 *!equilibrium wrote:*   

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

 se è una questione di mettere delle guide per l'aggiornamento non vedo quale sia il problema di adottare bash4. se i vecchi bash non saranno utilizzabili con i nuovi ebuild la guida semplicemente riporterà il passaggio per aggiornare bash

 *Quote:*   

> 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!
> 
> 

 ce lo possiamo permettere perché una retrocompatibilità del genere ci è inutile   :Razz: 

 *cloc3 wrote:*   

>  *xdarma wrote:*   Certi che 'sti piagnoni di KDE3 sono proprio monotoni  
> 
>  
> 
> un software instabile viene imposto in sostituzione di uno stabile e collaudato, con danni precisi per gli utenti.
> ...

 semmai incompleto ma assolutamente non instabile. kde 4.3.1 è stabile per gentoo, e se è stabile per gentoo...

----------

## bandreabis

Va beh.

Attendiamo sviluppi di kde e dei programmi di contorno.

Per velocizzare il raggiungimento del mio obbiettivo, usiamo kde4 ~x86.

E viva Gentoo.

----------

## xdarma

 *cloc3 wrote:*   

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

 

Imposto? Danni? Ma qualcuno ti obbliga a digitare "emerge --sync && emerge -uDN world"? Se non ti funziona ark (per dirne uno) fallisce la ditta?

 *cloc3 wrote:*   

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

 

Ma tutto questo dopo la venuta dei 4 cavalieri dell'apocalisse ma prima che il mare incominci a bollire?  :-P

 *cloc3 wrote:*   

> ma lasciaci questa la libertà di lagnarci apertamente. :!:

 

Ti dovrebbero cambiare il level da "Veteran" a "Rex Piagnorum"  :-D

E credo di sapere perchè sei tanto restio ad abbandonare KDE3: adesso con KDE4 devi cambiare nickname in cloc4  :-D

 *!equilibrium wrote:*   

> ...si avrà la possibilità di accellerare interamente le UI tramite OpenGL, senza gravare quindi sulla CPU.

 

Questo mi sembra molto interessante.

 *bandreabis wrote:*   

> E viva Gentoo.

 

Sempre viva!

----------

## lucapost

 *xdarma wrote:*   

> 
> 
>  *cloc3 wrote:*   ma lasciaci questa la libertà di lagnarci apertamente.  
> 
> Ti dovrebbero cambiare il level da "Veteran" a "Rex Piagnorum"  
> ...

 

ROTFL!!!

[ot]

qui urge un gpub udinese!

[/ot]

----------

## cloc3

 *devilheart wrote:*   

> semmai incompleto ma assolutamente non instabile.

 

in verità, sono troppo nubbio per distinguere tra un software incompleto e un software instabile.

oggi, per stampare con okular il pdf del mio compito in classe, ho pigiato 23 volte ctrl-p invio.

il pannello della userlist di kdm è così brutto che è stato rimosso dalla penultima versione del layout di default, e non compare neppure se imposti l'opzione UserList=true.

adoro l'editor integrato con supporto read-write del nuovo konqueror e non penso a kde4 come a un accrocchio informe, ma a uno splendido giocattolo.

solo non me la sento di farne un uso professionale, mentre kde3 è privo di supporto upstream e fuori portage.

chiamatemi pure re dei piagnoni, ma l'onestà intellettuale di dire quello che vedo non può venirmi meno per questo.

@lucapost

il gpub udinese sarebbe una splendida idea. ma sono un po' compresso.

facciamo a dicembre avanzato?

aprite i contatti via email o via messaggio privato.

ma sia chiaro, di invitare xdrama non se ne parla.

 :Cool: 

----------

## !equilibrium

 *devilheart wrote:*   

> se è una questione di mettere delle guide per l'aggiornamento non vedo quale sia il problema di adottare bash4. se i vecchi bash non saranno utilizzabili con i nuovi ebuild la guida semplicemente riporterà il passaggio per aggiornare bash

 

non si può fare l'upgrade di bash alle versioni che si desiderano come se fosse una normale dipendenza, portage smette di funzionare, cosa non ti è chiaro di questa frase? esempio: siamo nel 2014 ma abbiamo un'installazione vecchia del 2009 e la vogliamo aggiornare, in locale c'è bash3 e facciamo "emerge --sync"; ora grazie a @devilheart tutti gli ebuild presenti in /usr/portage/* sono scritti in bash5 e se lanciamo "emerge -auDNv world" otteniamo un simpatico syntax error perchè il nostro bash3 locale non è in grado di leggere la nuova e fiammeggiante sintassi di bash5 (non puoi, non è retrocompatible). siccome per avere un portage funzionante bisogna aggiornare app-shells/bash alla versione 5, non possiamo perchè sys-apps/portage smette di funzionare perchè trova in locale app-shells/bash:3, creando un loop infinito da cui non si può uscire (in realtà un'uscita di emergenza ci sarebbe, ma non è utonto-proof). chiaro ora? o ti devo fare un disegnino   :Rolling Eyes:  ?

 *devilheart wrote:*   

> ce lo possiamo permettere perché una retrocompatibilità del genere ci è inutile  

 

lo è per te, non per gli altri, Gentoo non è solo tua.

rileggiti le motivazioni che ho spiegato in precedenza. io ho dei server Gentoo che non voglio aggiornare/mantenere perchè sennò finirei per amministrare per 12 ore al giorno i server anzichè lavorare; mi paghi tu le bollette poi?   :Laughing: 

(non è solo una questione di aggiornare portage e qualche manciata di pacchetti alla settimana e basta, la situazione è un pelo più complessa di come la state mettendo voi, quindi se dovete fare commenti, fateli almeno seri altrimenti sono inutili)

----------

## devilheart

 *!equilibrium wrote:*   

> non si può fare l'upgrade di bash alle versioni che si desiderano come se fosse una normale dipendenza, portage smette di funzionare, cosa non ti è chiaro di questa frase? esempio: siamo nel 2014 ma abbiamo un'installazione vecchia del 2009 e la vogliamo aggiornare, in locale c'è bash3 e facciamo "emerge --sync"; ora grazie a @devilheart tutti gli ebuild presenti in /usr/portage/* sono scritti in bash5 e se lanciamo "emerge -auDNv world" otteniamo un simpatico syntax error perchè il nostro bash3 locale non è in grado di leggere la nuova e fiammeggiante sintassi di bash5 (non puoi, non è retrocompatible). siccome per avere un portage funzionante bisogna aggiornare app-shells/bash alla versione 5, non possiamo perchè sys-apps/portage smette di funzionare perchè trova in locale app-shells/bash:3, creando un loop infinito da cui non si può uscire (in realtà un'uscita di emergenza ci sarebbe, ma non è utonto-proof). chiaro ora? o ti devo fare un disegnino   ?

 disegnino? il problema è sempre stato chiaro. quello che dicevo io è mettere nella guida un passo per aggiornare bash3 ad un qualsiasi bash successivo dopo aver fatto un sync con gli ebuild con la nuova sintassi. tipo uno scriptino che usando solo bash3 è in grado di aggiornare bash stesso all'ultima versione, magari usando una tarball di bash precompilata ed estraendola in / (avendo cura di rimuovere i rimasugli della vecchia bash non sovrascritti). poi si può ricompilare come di solito. può essere un dirty hack ma l'alternativa è ritrovarci tra 20 anni ancora con la sintassi di bash3. nessuno ci garantisce che bash5 supporterà ancora la sintassi di bash3

 *Quote:*   

> lo è per te, non per gli altri, Gentoo non è solo tua.

 chiaramente mi riferivo a tutti quelli che si lagnano

----------

## riverdragon

Devilheart non ha tutti i torti: se ho capito bene, la retrocompatibilità che si vuole costruire da ora in poi andrà bene solo fino a quando bash sarà retrocompatibile con se stesso; quel giorno (qualora arrivasse, è bene ricordare che si parla molto in astratto) gentoo si troverebbe a decidere se bloccare la nuova versione di bash, se buttare alle ortiche gli anni di retrocompatibilità costruiti con pazienza o questa eventuale terza via.

Lo stesso python3 non è retrocompatibile, immagino che non fosse possibile ottenere dei miglioramenti senza modificare il funzionamento del linguaggio.

Penso che si potrebbe inoltrare la questione ai "piani alti", anche solo per chiedere un parere agli sviluppatori di bash.

----------

## !equilibrium

@Devilheart, @riverdragon: non è così semplice e le vostre idee sono già state discusse anni fa e rigettate (vedere i Gentoo Council di qualche tempo fa per le spiegazioni); la questione bash si risolve solo in un modo: garantendo la retrocompatibilità di bash a livello di global space, tutto il resto è superfluo.

----------

## riverdragon

 *!equilibrium wrote:*   

> non è così semplice e le vostre idee sono già state discusse anni fa e rigettate (vedere i Gentoo Council di qualche tempo fa per le spiegazioni)

 Ok, non sapevo.

----------

## xdarma

 *cloc3 wrote:*   

> chiamatemi pure re dei piagnoni, ma l'onestà intellettuale di dire quello che vedo non può venirmi meno per questo.

 

A parte le battute: condivido parzialmente le critiche che fai e mi sembri corretto e coerente con quello che dici.

Solo che a forza di leggere di gente che si lamenta di KDE4 per tutto (o quasi) e che osanna KDE3 come fosse il paradiso perduto... mi sembra che la situazione scivoli verso il comico.

Manca solo quello che dice "quando c'era KDE3 i treni arrivavano in orario"  :-D

Se ti va, continuiamo il discorso con una birra sul tavolo ;-)

----------

