GeCHI Weekly Report #1.13

[Elbryan]

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

===

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

[1] KDE Meeting (17.12)
Lo scorso 17 dicembre si è tenuto il meeting mensile tra gli sviluppatori del Gentoo KDE Project per discutere i seguenti punti:
[*]nuovi sotto-profili desktop - è proseguita la discussione sui sotto-profili desktop (vedere GWR #1.05) e tutti i membri del team KDE sono concordi sulle modalità della loro implementazione, quindi hanno dato il via libera ai lavori;[*][*]dipendenze opzionali e kde-base/kdebase-runtime-meta - discussione rimandata per mancanza di presenze;
[2] Qt Meeting (17.12)
Lo scorso 17 dicembre si è tenuto il meeting mensile tra gli sviluppatori del Gentoo Qt Project per discutere i seguenti punti (gli argomenti strettamente tecnici sono stati filtrati per brevità):
[*]eclass status - una nuova eclass chiamata: qt4-r2 è stata ultimata e inserita in portage; tutti i pacchetti presenti in portage riguardanti applicazioni Qt4 verranno convertiti alla nuova eclass;[*]split ebuild vs. monolithic ebuild - come nel precedente meeting (vedere GWR #1.05) sull'argomento in questione non si è raggiunto un compromesso soddisfacente tra i vari membri del team, quindi si è deciso di spostare l'intero onere al team di sviluppo di Portage; se il team di Portage non riuscirà a fornire entro un tempo ragionevole una soluzione alle lacune di emerge, gli sviluppatori del team Qt riesumeranno gli ebuild di tipo monolitico per risolvere il problema;[*]rimozione applicazioni Qt3 - per gennaio 2010 è prevista la rimozione di kde-base/kdelibs:3.5 e delle ultime applicazioni Qt3 rimaste in portage (vedere bug report #283429);
[] Opzioni di portage che non molti conoscono [EXTRA]
Lo sviluppatore Gentoo Patrick Lauer ha scritto un interessante articolo in cui spiega alcune opzioni di Portage che generalmente non sono molto note tra gli utente finali della distribuzione Gentoo.

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

# Diego E. Pettenò (flameeyes [at] gentoo.org) (17 Dec 2009)
# Multiple build failures (bug #246374, #259331, #285726,
# #288124), no releases upstream.
media-video/cinepaint

# Diego E. Pettenò (flameeyes [at] gentoo.org) (16 dic 2009)
# Fails to build with glibc 2.10 (bug #297210), ignores flags
# (bug #241982), lacks a Gentoo maintainer, never bumped
# since its adding in 2005, substandard ebuild QA-wise
# (does not die on _any_ failure).
sys-apps/compare

# Diego E. Pettenò (flameeyes [at] gentoo.org) (16 dic 2009)
# No upstream release since 2005, unused in Gentoo, smaller
# QA issues and some worrisome warnings from X11 functions.
dev-ruby/ruby-xlib

# Jonathan Callen (abcd [at] gentoo.org) (14 Dec 2009)
# Old Qt3-only version of qca, unused in tree
=app-crypt/qca-1*
app-crypt/qca-tls

# Diego E. Pettenò (flameeyes [at] gentoo.org) (14 Dec 2009)
# Fails to build since October 2008 (bug #239811). Multiple
# QA concerns.
media-gfx/giram

# Diego E. Pettenò (flameeyes [at] gentoo.org) (13 Dec 2009)
# Pre-strip files (bug #241534), ignore flags (bug #241556),
# misplaces documentation (bug #241560), bump request open
# since August 2008 (bug #235888).
x11-wm/ion

# Diego E. Pettenò (flameeyes [at] gentoo.org) (13 Dec 2009)
# Fails to build since at least November 2008 (bug #245506),
# open bump request since January 2006! (bug #117892).
net-irc/ptlink-services

# Diego E. Pettenò (flameeyes [at] gentoo.org) (13 Dec 2009)
# Installs in the old /usr/X11R6 path (bug #248593),
# unmaintained in Gentoo (last version bump in 2005), uses
# imake that is being deprecated.
x11-misc/xse

# Diego E. Pettenò (flameeyes [at] gentoo.org) (12 Dec 2009)
# Fails to build, bug #228175 open in June 2008.
sys-auth/nsvs

# Rémi Cardona (remi [at] gentoo.org) (13 Dec 2009)
# ttmkfdir had multiple QA issues and bugs (bugs #209616, #235354 and #262945)
# xfs is completely useless, even on thin clients
# and xfsinfo is useless if xfs goes
x11-apps/ttmkfdir
x11-apps/xfs
x11-apps/xfsinfo

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

[cloc3]

[1] KDE Meeting (17.12)

ottimo il lavori degli sviluppatori gentoo.
ma quello che servirebbe realmente, sarebbe una collaborazione più intensa con gli sviluppatori di kde, che porti a uno split delle kdelibs.
esistono prospettive di questo tipo?

interessante articolo

per caso, hai leggermente cannato il link?

[!equilibrium]

ma quello che servirebbe realmente, sarebbe una collaborazione più intensa con gli sviluppatori di kde, che porti a uno split delle kdelibs.

argomento già discusso, non è compito dei devel Gentoo fare il lavoro di upstream, e upstream ha già detto che non c'è bisogno dello split di kdelibs "perchè su debian le librerie sono già splittate", quindi semmai, se volete questa feature, siete voi utenti che dovete chiederla a gran voce upstream.

per caso, hai leggermente cannato il link?

mi pare corretto, a me si apre

[cloc3]

argomento già discusso,

lo so. ma il tempo passa e le cose possono (devono?) cambiare.

questa di debian non la avevo capita bene.
chi ha effettuato lo split delle kdelibs per debian?
perché non è utilizzabile dalle altre distribuzioni?

mi pare corretto, a me si apre

anche a me, ma punta a un capitolo interno sbagliato: THE MISTERY OF SWAPPINESS.

[!equilibrium]

lo so. ma il tempo passa e le cose possono (devono?) cambiare.

lo ripeto anche qui, magari vi viene utile: se volete farvi ascoltare upstream dovete trovare un gruppo di utenti desiderosi di fare lo split di kdelibs, radunarvi con uno o più devel ufficiali di KDE che condividono la vostra idea e stendere una dettagliata relazione del perchè è importante questa modifica delle librerie, quali vantaggi porta, ma soprattutto fornire una roadmap completa dei tempi e delle modalità di implementazione; fatto questo, sottoponete il tutto al core team di KDE, difficilmente vi diranno di no.

a parte dire "splittiamo le kdelibs", qualcuno ha fatto qualcosa?
la risposta ve la potete immaginare da soli e fin quando gli "utonti" non faranno la prima mossa, upstream non muoverà mai un dito.

punto di riflessione per tutti: quanto è utile scrivere in un forum "le cose possono/devono cambiare" ?

questa di debian non la avevo capita bene.
chi ha effettuato lo split delle kdelibs per debian?
perché non è utilizzabile dalle altre distribuzioni?

mai usato una distro binaria? kdelibs è un pacchetto monolitico, si compila tutto quanto in un unico processo, ma poi viene distribuito nelle distro binarie come tanti componenti separati: kde-core, kde-gui, kde-network ecc ecc; siccome la maggioranza dei devel del core team di KDE usa debian per sviluppare, ogni volta che un utonto esce dal coro e dice: "voglio le kdelibs splittate" viene zittito con: "su debian sono già splitted, il problema non si pone".

anche a me, ma punta a un capitolo interno sbagliato: THE MISTERY OF SWAPPINESS.

non saprei, a me apre "Awesome portage options".

[cloc3]

punto di riflessione per tutti: quanto è utile scrivere in un forum "le cose possono/devono cambiare" ?

io ho solo posto una domanda, perché pensavo che, con il trascorrere del tempo, fosse accaduto qualche cosa: allo scopo di ricevere una informazione.
le condizioni che tu poni perché quel qualcosa possa accadere non sono nelle mie corde.
hai identificato dei comportamenti percorribili solo da uno sviluppatore.
a me, se apro un baco, me lo chiudono come wontfix.

l'unico contributo che posso dare è una osservazione da utente finale (lo so, la ho già espressa altrove, ma in un forum non c'è divieto assoluto di ripetizioni): per usare konqueror sono costretto a installare dolphin. io odio dolphin. quando, per qualche mistero della fede, mia moglie, eseguendo una operazione che prima era gestita da konqueror, si vede partire dolphin, le prende un coccolone. e non ti dico mia figlia. mi pare strano che gli sviluppatori upstream non vedano da soli queste cose. più che segnalare i miei piccoli problemi di usabilità, cosa ti posso fare? non prenderlo come una polemica, solo come una osservazione personale.

quanto al discorso debian, sono troppo utonto e continuo a non capirlo .

non saprei, a me apre "Awesome portage options".

diavolo. se clicco con konqueror si apre sbagliato, se clicco con firefox si apre giusto.
sarà che ho le traveggole, non c'è che dire...

[grifone87]

quanto al discorso debian, sono troppo utonto e continuo a non capirlo .

Se ho capito bene: prima compilano tutto il pacchetto delle kdelibs, poi le librerie ottenute vengono raggruppate in altri pacchetti: le librerie fondamentali in kde-core, quelle che riguardano l'interfaccia, in kde-gui e così via.

non saprei, a me apre "Awesome portage options".

diavolo. se clicco con konqueror si apre sbagliato, se clicco con firefox si apre giusto.
sarà che ho le traveggole, non c'è che dire...

Ho provato ad aprire il link con konqueror (uso firefox): se clicco il link dalla pagina della discussione anche a me porta a THE MISTERY OF SWAPPINESS; invece, copiando l'indirizzo aprendolo direttamente ottengo la pagina giusta! Quindi, non hai le traveggole!

[devilheart]

quanto al discorso debian, sono troppo utonto e continuo a non capirlo .

i dev di kde lavorano su debian e dato che debian gli fornisce già i pacchetti di kdelibs splittati, loro se ne sbattono se su altre distro non è così. ne deduco che il messaggio subliminale è "se volete kdelibs splittato usate debian"

[Apetrini]

@cloc3: non so se ho capito bene, dici di aver bisogno di dolphin per usare konqueror ?!?! Non mi risulta, puoi benissimo vivere senza dolphin e questo non ha nulla a che fare con le kdelibs.

Infatti se provo a disinstallare dolphin, ottengo:

Code: Select all

These packages will be uninstalled:

* kde-base/kdebase-meta-4.3.4:4.3::installed requires <kde-base/dolphin-4.3.4:4.3::installed>
* kde-base/mplayerthumbs-4.3.4:4.3::installed requires <kde-base/dolphin-4.3.4:4.3::installed>
* kde-base/dolphin-4.3.4:4.3::installed

A parte questa parentesi su dolphin, secondo me qui nessuno ha capito il punto fondamentale del discorso...

Il problema è fondamentalmente che portage non ha un meccanismo efficace per assicurare/gestire un vincolo del tipo "se hai il programma X che consta di 10 moduli/split ed è a una certa versione, se aggiorni la versione di X o di un suo modulo, ogni altro modulo che è installato deve essere aggiornato alla stessa versione"

Banale vero???
Attualmente portage gestisce questo caso con un odioso workaround (sarebbe meglio dire con un accrocchio); tralascio i dettagli del workaround, ma è poi quello che porta in quelle strane situazioni in cui per aggiornare le qt(per esempio) bisogna prima rimuovere le vecchie e poi installare le nuove. Il tutto fermato da un fastidioso blocco!! Sarebbe più immediato pensare che l'aggiornamento venga eseguito automaticamente e senza problemi visto che le qt sono sullo stesso slot e la versione maggiore dovrebbe semplicemente "aggiornare" quella minore (come avviene con una moltitudine di altri pacchetti). Eppure per rispettare il vincolo sopra descritto, portage forza questo tipo di comportamento e fa schiantare i newbe... che si trovano spaesati di fronte al blocco!!!!

Ora, alla luce dei fatti sopra esposti, mi dite che senso ha richiedere lo split delle kdelibs (io in realtà non sono favorevole allo split, ma se proprio è sentito per me si puo fare) se poi portage non è in grado di gestire questo tipo di pacchetti??? (faccio notare che le kdelibs splittate in modo adeguato avrebbero gli stessi problemi delle qt splittate).

Perché secondo voi, come ultima spiaggia, si è proposto il ritorno delle qt monolitiche ? Perché a causa della non gestione del vincolo sopra esposto, si cominciano ad avere parecchie grane.

Notate bene che il problema è un attimino più complicato di come l'ho esposto io, ma dovrebbe rendere l'idea.

Sto aspettando che si trovi un modo per far gestire a portage queste cose da tanto tempo oramai; spero che finalmente si prenda la situazione di petto e si cerchi di fare qualcosa. Cercare di dribblare gli ostacoli all'infinito non credo porti beneficio.

Mi rammarico un pochino perché ho la sensazione che "quelli di gentoo... quelli di portage etc..." non vogliano mai parlare in maniera troppo esplicita (e troppo pubblica) dei limiti/problemi del portage (limiti dei quali loro sono ben consci). Secondo me mostrare queste problematiche agli utenti puo fare solo bene e di certo non è segno di lavoro svolto male.

[!equilibrium]

Il problema è fondamentalmente che portage non ha un meccanismo efficace per assicurare/gestire un vincolo del tipo "se hai il programma X che consta di 10 moduli/split ed è a una certa versione, se aggiorni la versione di X o di un suo modulo, ogni altro modulo che è installato deve essere aggiornato alla stessa versione"

Banale vero???

la questione di kdelibs splitted non ha nulla a che vedere con portage;
kdelibs splitted = voglio solo compilare e installare il core di kdelibs --> "configure --build=core && make && make install"

banale vero? purtroppo ad oggi questa possibilità non esiste perchè il build system di kdelibs compila tutti i moduli di kdelibs in un colpo solo, indipendente che tu lo voglia o meno, quindi indipendentemente dalla volontà di portage.

Attualmente portage gestisce questo caso con un odioso workaround (sarebbe meglio dire con un accrocchio); tralascio i dettagli del workaround, ma è poi quello che porta in quelle strane situazioni in cui per aggiornare le qt(per esempio) bisogna prima rimuovere le vecchie e poi installare le nuove. Il tutto fermato da un fastidioso blocco!! Sarebbe più immediato pensare che l'aggiornamento venga eseguito automaticamente e senza problemi visto che le qt sono sullo stesso slot e la versione maggiore dovrebbe semplicemente "aggiornare" quella minore (come avviene con una moltitudine di altri pacchetti). Eppure per rispettare il vincolo sopra descritto, portage forza questo tipo di comportamento e fa schiantare i newbe... che si trovano spaesati di fronte al blocco!!!!

stai facendo di tutte le erbe un fascio: Qt non è KDE ne tanto meno è kdelibs;
va premesso che le Qt sono splitted by design e portage non ha bisogno di nessun workaround per gestirle, lo dimostra il fatto che in portage esistono i pacchetti qt-core, qt-gui, qt-network ecc ecc; mentre il workaround di cui parli è la questione che Qt per funzionare richiede che tutti i suoi moduli siano installati con la stessa build release, cioè non puoi usare qt-core-4.3.2 con qt-gui-4.3.3. Ma ciò è questione esclusiva di Qt (e di un paio di altri pacchetti meno importanti), tutti gli altri 15.000 pacchetti di portage non hanno questo difetto; resta pure vero che è un limite di portage e che, come ho scritto in questo GWR e in un altro precedente, se non verrà risolto, il team di KDE passerà agli ebuild monolitici, ma non perchè questo sia il modo corretto di gestire il problema, ma perchè ci sono tantissimi segnalazioni di utonti che non sanno come installare CORRETTAMENTE i singoli moduli di Qt. Quindi o sei un utilizzatore di Qt e sai come gestirti/installarti i vari moduli o finisci in un intricato groviglio di block. Qui più che essere un limite di portage, è un limite di utonto (ma ben vengano scorciatoie per facilitare la vita agli utonti)

Ora, alla luce dei fatti sopra esposti, mi dite che senso ha richiedere lo split delle kdelibs (io in realtà non sono favorevole allo split, ma se proprio è sentito per me si puo fare) se poi portage non è in grado di gestire questo tipo di pacchetti??? (faccio notare che le kdelibs splittate in modo adeguato avrebbero gli stessi problemi delle qt splittate).

lo split serve per due motivi molto semplici: libertà di scelta (io non voglio le parti di kdelibs che non uso con kde:4, e sono più della metà della libreria) e cosa più importante evitare di installarsi porcate come mysql-embedded quando l'utente finale non lo usa.

Perché secondo voi, come ultima spiaggia, si è proposto il ritorno delle qt monolitiche ? Perché a causa della non gestione del vincolo sopra esposto, si cominciano ad avere parecchie grane.

le grane esistono solo per Qt e per chi non sa come funzionano e come installarle, mentre per kdelibs il discorso è diverso, fa parte ed è usato solo da kde:4 quindi sarà il team di KDE di Gentoo a modificare tutti gli ebuild di kde:4 affinchè il problema delle build release non colpisca gli utenti di kde:4 (non sono sicuro, ma kde4 dovrebbe essere esente dal problema delle build release perchè tutti i software di kde vengono rilasciati assieme e quindi sei obbligato ad aggiornarli tutti assieme).

Notate bene che il problema è un attimino più complicato di come l'ho esposto io, ma dovrebbe rendere l'idea.

veramente è l'opposto, è un tantinello più semplice di come l'hai messa giù tu.

Sto aspettando che si trovi un modo per far gestire a portage queste cose da tanto tempo oramai; spero che finalmente si prenda la situazione di petto e si cerchi di fare qualcosa. Cercare di dribblare gli ostacoli all'infinito non credo porti beneficio.

teoricamente non dovrebbe nemmeno essere un problema di portage, è un problema di upstream perchè le librerie NON andrebbero rilasciate in questo modo e visto che kde ha copiato la stessa filosofia di Qt2 e Qt3, si porta dietro gli stessi identici problemi (giusto per dover di cronaca, Nokia ha promesso che per la versione di Qt5 il problema delle build release non sussisterà più, ha senso patchare emerge solo per Qt? e avrà ancora più senso mantenere tali feature quando Qt4 non sarà più in portage?)

Mi rammarico un pochino perché ho la sensazione che "quelli di gentoo... quelli di portage etc..." non vogliano mai parlare in maniera troppo esplicita (e troppo pubblica) dei limiti/problemi del portage (limiti dei quali loro sono ben consci). Secondo me mostrare queste problematiche agli utenti puo fare solo bene e di certo non è segno di lavoro svolto male.

In genere i devel di portage sono ben propensi al dialogo e nessuno sta nascondendo i limiti dello stesso, solo che il punto di discussione dei problemi e delle nuove feature è tramite la mailing list, il bugzilla o IRC, non il forum o il bar sotto casa; che poi l'utente medio Gentoo non voglia seguire il planet, la mailing list o altro, questi sono problemi esclusivi degli utenti, non è di certo un problema dell'infrastruttura di Gentoo.

La "tua sensazione" non ha riscontro con la realtà (Ciaranm ti sta facendo il SUO lavaggio mentale), basta che vai a vederti le discussioni riguardanti EAPI, il Gentoo Council, la mailing ecc ecc ... non ho per caso scritto in un recente GWR che Gentoo/Prefix è entrato in Portage? Guarda che Gentoo/Prefix è la creazione di un ex sviluppatore italiano di Gentoo, nato come progetto a parte per sopperire ai limiti di portage e quando è diventato stabile è stato incluso senza problemi. Nessuno ha nascosto nulla e nessuno ha mai detto che Portage è esente da problemi; ciò che molti percepiscono come limiti/difetti di portage spesso sono solo problemi generati da altri ambienti al di fuori di Gentoo (vedi la questione che ho appena spiegato delle Qt) oppure sono limiti già noti e in corso di risoluzione o addirittura già risolti nella versione testing (come quando qualche anno fa la gente si lamentava dei difetti di --depclean e si indignava qui sul forum della scarsa serietà degli sviluppatori che non prestavano attenzione alle lamentale dei poveri utenti, sei mesi dopo, sempre qui sul forum, gli stessi personaggi lodavano ed osannavano l'effecienza di --depclean )

meno lagne, più buon senso.

[Apetrini]

Non credo di essere stato capito fino in fondo. Probabilmente a causa del modo con cui ho esposto le cose, ma anche tu però... fa uno sforzo per capire...o cambia sfera di cristallo!!

...
la questione di kdelibs splitted non ha nulla a che vedere con portage;
kdelibs splitted = voglio solo compilare e installare il core di kdelibs --> "configure --build=core && make && make install"
...

Che fosse un problema di build mi sembrava fosse ovvio, ma io ero già uno step più avanti(col discorso, beninteso)!!

Cerco di spiegarmi meglio:
Assumete per un istante che le kdelibs siano già splitted(come possbilità di build).
Ora come ora le kdelibs-pippo kdelibs-pluto etc... avrebbero le stesse identiche rogne (coi blocchi) delle attuali qt splitted.
Se gli sviluppatori come ultima spiaggia vogliono tornare alle qt monolitiche, che senso ha richiedere (per quanto riguarda gentoo) lo split delle kdelibs in upstream se poi per le solite rogne(le stesse delle qt) si tornerà a kdelibs monolitoco(come con le qt) ???

va premesso che le Qt sono splitted by design e portage non ha bisogno di nessun workaround per gestirle, lo dimostra il fatto che in portage esistono i pacchetti qt-core, qt-gui, qt-network ecc ecc; mentre il workaround di cui parli è la questione che Qt per funzionare richiede che tutti i suoi moduli siano installati con la stessa build release, cioè non puoi usare qt-core-4.3.2 con qt-gui-4.3.3. Ma ciò è questione esclusiva di Qt (e di un paio di altri pacchetti meno importanti), tutti gli altri 15.000 pacchetti di portage non hanno questo difetto; resta pure vero che è un limite di portage e che, come ho scritto in questo GWR e in un altro precedente, se non verrà risolto, il team di KDE passerà agli ebuild monolitici, ma non perchè questo sia il modo corretto di gestire il problema, ma perchè ci sono tantissimi segnalazioni di utonti che non sanno come installare CORRETTAMENTE i singoli moduli di Qt. Quindi o sei un utilizzatore di Qt e sai come gestirti/installarti i vari moduli o finisci in un intricato groviglio di block. Qui più che essere un limite di portage, è un limite di utonto (ma ben vengano scorciatoie per facilitare la vita agli utonti)

Intendevo dire che portage usa un workaround per "gestire" le qt splitted proprio per il fatto che "usa dei blocchi" per "assicurare" che tutti gli split siano alla stessa versione. (mi sembra ovvio che in portage ci siano già le qt splitted e che siano installabili, ci mancherebbe altro)

Siamo perfettamente d'accordo sul fatto che è un limite di portage(solo che io la questione di mettere dei blocchi come sono ora per assicurare la coerenza delle versioni la chiamo workaround).

A questo punto, viste le nostre divergenze di pensiero, devo chiarire una questione di fondo.
Un vincolo del tipo "se aggiorni un modulo splitted devi aggiornare anche tutti gli altri che hai installati alla stessa versione" ha perfettamente senso a mio parere. Questo vincolo portage non riesce a renderlo in maniera efficace(per cui hanno pensato di usare i blocchi come sono oggi).

Il fatto che per ora sia poco usato(da pochi pacchetti) non è certamente un buon motivo per metterci una pezza, ma IMHO va risolto implementando in portage la capacità di rendere(nel modo giusto) questo vincolo(che è sensato, anche se raro).

Io sono il primo che si rompe le scatole per tutti gli utonti che a malapena riescono a capire che scheda grafia stanno usando, ma secondo me qui non è colpa dell'utonto(dire che sia un problema dell'utonto invece del portage è imbrogliare).

Il concetto è molto semplice: "se tutte le implicazioni della finalità di un azione sono note a priori, è il portage che deve fare il lavoro sporco". Cosi almeno la vedo io, ma è solo un opinione.

Quando si vuole aggiornare un pacchetto è molto chiara la finalità che si vuole raggiungere: " si vuole avere la nuova versione del pacchetto" (ovviamente va detto che come presupposto c'è il fatto che non ci siano blocchi/incompatibilità con altri pacchetti).

Ora l'utonto, ma anche io(perche è un operazione che potrebbe fare il portage), si aspetta che se ha avuto le qt-4.5.1(con tutti i modulini che usa alla stessa versione) e vuole aggiornare alle qt-4.5.3, il portage aggiorni il tutto come fa con una miriade di altri pacchetti: ovvero si aggiornino tutti i modulini alla stessa versione(senza rompere le scatole all'utonto). Che senso ha chiedere all'utonto di rimuovere a mano le vecchie qt per installare le nuove ??? Quando mai si è chiesto per un qualsiasi generico pacchetto all'utonto di disinstallare la versione vecchia per poter mettere quella nuova(ovviamente parliamo di roba sullo stesso slot e tutto il resto)...questa cosa è sempre stata fatta dal portage(lasciamo perdere roba basilare per il boot del sistema).

Anche perché vorrei precisare che:
sistema_con_pacchetti+qt-4.5.1(con tutti i moduli)---->(dopo aver fatto a mano disinstalla/installa per le nuove qt)-->sistema_con_pacchetti+qt-4.5.3(con tutti i moduli)


Come vedete non c'è nulla che blocchi realmente nulla, le qt sono semplicemente aggiornate.

In genere i devel di portage sono ben propensi al dialogo e nessuno sta nascondendo i limiti dello stesso, solo che il punto di discussione dei problemi e delle nuove feature è tramite la mailing list, il bugzilla o IRC, non il forum o il bar sotto casa; che poi l'utente medio Gentoo non voglia seguire il planet, la mailing list o altro, questi sono problemi esclusivi degli utenti, non è di certo un problema dell'infrastruttura di Gentoo.

La "tua sensazione" non ha riscontro con la realtà (Ciaranm ti sta facendo il SUO lavaggio mentale), basta che vai a vederti le discussioni riguardanti EAPI, il Gentoo Council, la mailing ecc ecc ... non ho per caso scritto in un recente GWR che Gentoo/Prefix è entrato in Portage? Guarda che Gentoo/Prefix è la creazione di un ex sviluppatore italiano di Gentoo, nato come progetto a parte per sopperire ai limiti di portage e quando è diventato stabile è stato incluso senza problemi. Nessuno ha nascosto nulla e nessuno ha mai detto che Portage è esente da problemi; ciò che molti percepiscono come limiti/difetti di portage spesso sono solo problemi generati da altri ambienti al di fuori di Gentoo (vedi la questione che ho appena spiegato delle Qt) oppure sono limiti già noti e in corso di risoluzione o addirittura già risolti nella versione testing (come quando qualche anno fa la gente si lamentava dei difetti di --depclean e si indignava qui sul forum della scarsa serietà degli sviluppatori che non prestavano attenzione alle lamentale dei poveri utenti, sei mesi dopo, sempre qui sul forum, gli stessi personaggi lodavano ed osannavano l'effecienza di --depclean )

Peccato per il bar sotto casa...

meno lagne, più buon senso.

Ma va, ti vuoi realmente annoiare sul forum gentoo ?

[Onip]

Code: Select all

Lebowsky ~ # eix -Ic --only-names qt > qTest
Lebowsky ~ # cat qTest 
x11-libs/qt-core
x11-libs/qt-dbus
x11-libs/qt-gui
x11-libs/qt-script
Lebowsky ~ # mv qTest /etc/portage/package.keywords/
Lebowsky ~ # emerge -DuNav world

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild     U ] x11-libs/qt-core-4.6.0 [4.5.3-r2] USE="glib iconv ssl -debug -doc -optimized-qmake% -pch -qt3support" 152,031 kB
[ebuild     U ] x11-libs/qt-script-4.6.0 [4.5.3-r1] USE="iconv -debug -pch" 0 kB
[blocks b     ] <x11-libs/qt-script-4.6.0 ("<x11-libs/qt-script-4.6.0" is blocking x11-libs/qt-core-4.6.0, x11-libs/qt-dbus-4.6.0, x11-libs/qt-gui-4.6.0-r1)
[ebuild     U ] x11-libs/qt-dbus-4.6.0 [4.5.3-r1] USE="-debug -pch" 0 kB
[blocks b     ] <x11-libs/qt-dbus-4.6.0 ("<x11-libs/qt-dbus-4.6.0" is blocking x11-libs/qt-core-4.6.0, x11-libs/qt-script-4.6.0, x11-libs/qt-gui-4.6.0-r1)
[blocks b     ] >x11-libs/qt-gui-4.5.3-r9999 (">x11-libs/qt-gui-4.5.3-r9999" is blocking x11-libs/qt-dbus-4.5.3-r1, x11-libs/qt-core-4.5.3-r2, x11-libs/qt-script-4.5.3-r1)
[ebuild     U ] x11-libs/qt-gui-4.6.0-r1 [4.5.3-r2] USE="cups dbus glib gtk mng tiff -accessibility -debug -nas -nis -pch -qt3support -raster -xinerama" 0 kB
[blocks b     ] >x11-libs/qt-script-4.5.3-r9999 (">x11-libs/qt-script-4.5.3-r9999" is blocking x11-libs/qt-dbus-4.5.3-r1, x11-libs/qt-core-4.5.3-r2, x11-libs/qt-gui-4.5.3-r2)
[blocks b     ] <x11-libs/qt-gui-4.6.0 ("<x11-libs/qt-gui-4.6.0" is blocking x11-libs/qt-core-4.6.0, x11-libs/qt-script-4.6.0, x11-libs/qt-dbus-4.6.0)
[blocks b     ] >x11-libs/qt-core-4.5.3-r9999 (">x11-libs/qt-core-4.5.3-r9999" is blocking x11-libs/qt-dbus-4.5.3-r1, x11-libs/qt-gui-4.5.3-r2, x11-libs/qt-script-4.5.3-r1)
[blocks b     ] >x11-libs/qt-dbus-4.5.3-r9999 (">x11-libs/qt-dbus-4.5.3-r9999" is blocking x11-libs/qt-core-4.5.3-r2, x11-libs/qt-gui-4.5.3-r2, x11-libs/qt-script-4.5.3-r1)

Total: 4 packages (4 upgrades), Size of downloads: 152,031 kB
Conflict: 7 blocks

Would you like to merge these packages? [Yes/No]

a me sembra proprio che, a parte l'esplicitazione dei blocchi, portage "se la smazzi" da solo: esattamente come fa con (quasi tutti) gli altri blocchi.
@Apertini: o è un po' che non usi emerge oppure io non ho capito quello che intendi.

[cloc3]

lo split serve

ecco detta così, da uno sviluppatore, sembra proprio una cosa interessante.
sia pure uscita da un bar.

se serve, speriamo che si possano creare le condizioni per farla.
è vero. in un bar, queste condizioni non si potranno creare mai. ma intanto, si butta l'idea.

[!equilibrium]

se serve, speriamo che si possano creare le condizioni per farla.
è vero. in un bar, queste condizioni non si potranno creare mai. ma intanto, si butta l'idea.

non ho contestato il fatto di parlare del problema, ho contestato il fatto di parlarne in *questo bar* quando è un argomento dell'*altro bar* (upstream)

[Apetrini]

a me sembra proprio che, a parte l'esplicitazione dei blocchi, portage "se la smazzi" da solo: esattamente come fa con (quasi tutti) gli altri blocchi.
@Apertini: o è un po' che non usi emerge oppure io non ho capito quello che intendi.

Non sempre va a buon fine (mi è giunta voce che ha piu di qualche rogna).

Comunque prova, senza aggiornare tutto il world, ad aggiornare solo le qt, tipo "emerge -uav qt-core"(vedi se gestisce bene il tutto).

@!equilibrium, cloc3: biliardino, biliardino !!!!

[devilheart]

a me sembra proprio che, a parte l'esplicitazione dei blocchi, portage "se la smazzi" da solo: esattamente come fa con (quasi tutti) gli altri blocchi.

prova con

Code: Select all

emerge -uDNav qt-core

dopo lo smascheramento

[riverdragon]

Io ho fatto una prova rapida col sistema di onip e la compilazione è partita senza problemi, non so come vada la fase di installazione perché ho interrotto emerge (le qt 4.6 non mi interessano, per quello che mi serve tengo il ramo stabile).

[Onip]

Comunque prova, senza aggiornare tutto il world, ad aggiornare solo le qt, tipo "emerge -uav qt-core"(vedi se gestisce bene il tutto).

Effettivamente in questo caso portage(stabile) se ne esce col suo solito messaggio sui blocchi e tocca dargli un "aiutino". Ad ogni modo credo che l'update del world copra una buona fetta degli use cases.