Regole del forum
1) Citare in modo preciso il nome del pacchetto.
2) Specificare se discussione/suggerimento o richiesta d'aiuto.
3) Leggere attentamente le risposte ricevute
4) Scrivere i messaggi con il colore di default, evitare altri colori.
5) Scrivere in Italiano o in Inglese, se possibile grammaticalmente corretto, evitate stili di scrittura poco chiari, quindi nessuna abbreviazione tipo telegramma o scrittura stile SMS o CHAT.
6) Appena registrati è consigliato presentarsi nel forum dedicato.
La non osservanza delle regole porta a provvedimenti di vari tipo da parte dello staff, in particolare la non osservanza della regola 5 porta alla cancellazione del post e alla segnalazione dell'utente. In caso di recidività l'utente rischia il ban temporaneo.
Non bastavano Amarok, KipiPlugins e altre applicazioni KDE4, adesso ci si mette pure il nuovo Stellarium 0.10.3 che sulla 13 non compila in quanto richiede almeno le Qt 4.6; la cosa assurda poi è che, come ammettono a volte persino gli stessi sviluppatori di queste applicazioni, l'uso di librerie più nuove non porta alcun beneficio.
Possiamo stare certi che, quando uscirà la Slackware 13.1 con KDE 4.4 e le Qt 4.6, i vari Amarok, Stellarium & C richiederanno KDE 4.5 e le Qt 4.7!
P.S. Tanto per cambiare, avevo già segnalato Stellarium 0.10.3 su PkgReports prima di scoprire questa ennesima fregatura.
Non vorrei dire una stupidaggine, ma credo che ci siano anche altri motivi.
Uno e' che le nuove 4.6.* introducono alcune comodissime funzionalita' per le OpenGL e molto altro (guardate la roadmap http://qt.nokia.com/developer/qt-roadmap).
percoco2000 ha scritto:Ma non sarebbe possibile compilare un pacchetto "static" , alla stregua di skype? (O dell'installer windows . ) Si eviterebbero tanti sbattimenti...
Si eviterebbero sbattimenti solo per chi scarica il pacchetto, non per chi lo crea. Inoltre se si facesse questo per tutte le applicazioni qt4, avremmo cloni del toolkit ogni dove, cosa non buona e soprattutto - per ragioni se non altro di spazio - deleteria. Le qt4 sono abbastanza corpose.
Effettivamente Nokia sta spingendo molto per aggiungere funzionalità alle QT ma questo porta il vantaggio di avere un prodotto sempre più potente e lo svantaggio che a volte non c'è completa retrocompatibilità.
Per la mia esperienza mi è capitato ultimamente in azienda che per ricompilare in QT4.6 applicazioni sviluppate in QT4.4 ho dovuto modificare alcune righe di codice (principalmente per le parti che riguardavano la grafica).
Secondo me è normale che chi si accinge ad iniziare un progetto o che aggiorni il proprio utilizzi sempre l'ultima versione delle librerie. Anche perché le Qt in ogni versione introducono notevoli migliorie: per esempio nella 4.6 è facilissimo creare animazioni e programmi che si comportano come macchine a stati finiti.
Il problema quindi non è dei programmi che utilizzano l'ultima versione ma di quelli che non lo fanno. Alla fine ricompilare e cambiare due righe di codice in caso di qualche piccola incompatibilità non mi pare un grande sforzo. Quindi W le QT e le loro ottime nuove versioni.
Da parte mia le stò scaricando in questo momento le QT 4.6 per vedere che effetto hanno e quali cambiamenti così innovativi possano avere sul sistema grafico.
Più che altro mi spinge la curiosità di vedere come si comportano.
Ho notato anch'io che spesse volte se non sempre, quando esce una nuova release di un programma viene scritto con l'ausilio delle librerie più recenti, a danno molto spesso di chi per vari motivi non fà aggiornamenti sistematici alla propria distribuzione.
Mi trovo in pieno accordo con manublade a riguardo al continuo e spesso mal funzionante incremento delle distribuzioni della serie kubuntu che applicano aggiornamenti corposi e eccessivamente privi di stabilità.
Testando e montando questo genere di distribuzioni su pc di gente neo-linuxiana ho trovato solo problemi.
Non metto in dubbio il fatto che Nokia stia facendo fare passi da gigante alle Qt; il discorso però è un altro. Tempo fa è uscito il nuovo KipiPlugins 1.0.0 che però richiede una versione più aggiornata di KDE4.2; ho scritto allo sviluppatore e mi ha risposto che ai fini della funzionalità di KipiPlugins, effettivamente non c'era alcuna ragione particolare per usare librerie KDE più nuove. Mi ha anche promesso che avrebbe risolto il problema, ma ad oggi non si sa ancora nulla.
A parte questo, immaginatevi una marea di utenti costretti ad aggiornare quasi ogni mese le Qt o KDE solo perché altrimenti non ci gira questo o quel programma ...
Phobos, ti do ragione e qui si impone una importante scelta di base, specialmente per slackware.
Il ramo stable di oggi (vedi 13) mi sembra sia andato troppo oltre la parola stable ed adesso si trova con software immaturi che per essere aggiornati necessitano aggiornamenti corposi di gran parte del sistema (es. le librerie che tu citi).
Io ad oggi preferisco ancora la 12.2.
Poi possiamo vivere "on the edge" nel ramo current e seguire le mode, ma Pat si è messo su una strada difficile con la 13. Vediamo come va a finire, ma non vorrei che slackware perdesse la sua affidabilità e sicurezza in nome delle mode. Siamo (noi di Slackware) una nicchia di Linux, e forse è (era) meglio rimanerci.
Secondo me il problema è un altro: se si usa una distribuzione, in genere quella tende a mantenere la versione di un certo software fino alla successiva release, specie se si tratta di dover aggiornare abissalmente metà sistema; ad esempio, la stessa Ubuntu ha, per la 9.10, KDE 4.3.x, e non aggiorna al 4.4 nei repository principali: se qualcuno vuole l'ultimissima versione, è costretto ad utilizzare un PPA apposito, che ovviamente non garantisce del tutto la stabilità, proprio perchè aggiorna non solo KDE ma anche le Qt (ed aggiunge, ad esempio, Virtuoso).
Stessa cosa con la Slack, no? Se si usa la 13.0 (e non si fa lo switch alla current), non credo ci sarà un aggiornamento alla 4.4 (se ben ricordo non c'è nemmeno la 4.3), quindi dov'è il problema? Se una persona vuole restare bleeding edge, allora deve essere consapevole della necessità di dover aggiornare numerose librerie; allo stesso modo, non è un problema aggiornare tutte le librerie se si parla di software ad uso desktop, sarebbe ben più grave forse una cosa del genere in software di base o lato server.
Inoltre: spesso ci si lamenta dell'immobilismo delle GTK e delle librerie di Gnome, ma poi ci si lamenta quando "dall'altra parte" invece si sviluppa in maniera molto attiva...
... ovviamente, se uno incrementa senza motivo alcuno i requisti del proprio software, effettivamente è una cavolata...