Debian Etch con punte di Lenny, via "pinning" ...o "aptitude"-way

[mrx65]

Salve...

Visti i frequenti mutamenti della versione testing, che a volte creano qualche problema, viste le mie esigenze "desktop-casalingo" con la maggiore stabilita' possibile, e data la configurazione hardware del mio pc desktop, anch'essa a volte causa di problemucci, avrei deciso di installare su questa macchina la "stable" (sia pure con una certa riluttanza), riservando la "testing" pura al portatile, che tutto sommato ha caratteristiche hardware piu' compatibili con debian e linux in generale...

Per l' installazione della stable-release ho scelto la via "netinstall" e per installare tutto il necessario senza  dimenticare qualcosa che puo' essermi necessario, mi sono limitato a lasciare le categorie di pacchetti predefinite, vale a dire "ambiente desktop (gnome)" e "sistema di base (o simile)". Purtuttavia avrei bisogno di dotare la etch di ntfs-3g, e gia' che ci sono mi piacerebbe dotarla anche del kernel della lenny...

La via scelta, su segnalazione di utente del forum, potrebbe essere quella del "pinning", e svelto svelto mi sono buttato sulla lettura della relativa guida

Ho seguito tutti i passi ivi indicati e la procedura sembrerebbe funzionare ...almeno finche' non vado ad installar e dai repo di testing oltre ai pacchetti del kernel 2.6.24-1-amd64 con gli headers, anche il pacchetto ntfs-3g, e sopratutto quando vado ad installare da tty1 (ctrl+alt+pf1 -> login utente -> login root -> /etc/init.d/gdm stop) con sh il *.run dei driver grafici nvidia (171.06.01)...

Ecco, in questo caso vengono fuori i problemi, perche' l' installazione di ntfs-3g riporta errori per librerie/pacchetti credo incompatibili, mentre l'installazione del *.run nvidia richiede la presenza dei pacchetti "gcc" e "libc" io ho provato ad installarli, sempre dai repos di testing, con la tecnica del pinning ...ma a quanto pare viene fuori un bordello ...perche' il driver grafico non funziona vengono rilevate incompatibilita' con pacchetti/librerie e viene consigliato il comando

Codice:

apt-get -f install

per tentare di risolvere
in realta' pero' tale comando provvede a disinstallarmi i pacchetti libc6, locales, ed altri, provocando nell' intero sistema il passaggio alla lingua di default di debian, l' inglese (niente di traumatico ...pero'...), intanto i driver proprietari nvidia continuano a non funzionare...

Sono il solo a cui e' capitato, o trattasi di cosa risaputa?
E' possibile ottenere una etch con i componenti di testing da me richiesti, con la tecnica del pinning, o trattasi di operazione troppo drastica e quindi causa di problemi irrisolvibili?

Se invece la cosa e' possibilissima (come credo che sia) ...dove ho sbagliato? Forse e' l'ordine di installazione dei componenti "importati"? Altrimenti cosa?

Sono stato volutamente scarno con i dettagli dei messaggi di errore e l'indicazione dei pacchetti incriminati, per non rendere illeggibile il post, ma se serve, posso essere piu' preciso...

Ciao e grazie

[tindal]

il pinning è una gran cosa, ma secondo me non è esattamente quello che ti serve

mi spiego:
il pinning sostanzialmente lega alcuni pacchetti a determinati repository e imposta una gerarchia di repo per la risoluzione delle dipendenze, ma questo è utile principalmente quando sai in partenza che, per es., il pacchetto amule lo vuoi prendere dal repo del progetto e non da quello debian... voglio dire: se non sai ancora cosa prenderai da ogni repo il pinning diventa macchinoso

in realtà apt è perfettamente in grado di mixare 2 o più release senza usare il pinning (io lo faccio ormai da anni): ti basta impostare la default release a stable (nel tuo caso) e poi usare aptitude per installare pacchetti dalla release che vuoi tu

2 note:
l'opzione "-t", sia per apt-get che per aptitude, ti imposta, momentaneamente, la default release a quella specificata subito dopo nella linea di comando, e questo non è quello che vuoi: tu devi solo installare un pacchetto da testing e le sue dipendenze, se possibile da stable, altrimenti da testing, mentre con "-t" ti installerebbe tutto da testing senza pensarci un attimo

personalmente uso solo aptitude, e temo che queste cose si possano fare solo con lui (in particolare, mi sa che synaptic non le può fare) e solo usandolo con l'interfaccia: in questo caso è possibile, per ogni pacchetto, vedere tutte le versioni disponibili (in base ai repo attivati) e installare quella preferita lasciando sistemare a lui le dipendenze, quando può, oppure correggerle a mano (è più semplice di quello che si può immaginare)

ciao
tindal

[mrx65]

Grazie per l' eccellente risposta

Mi hai suggerito un diverso ed autorevolissimo (visti i tuoi titoli) punto di vista circa il mio "problema"

Se ho ben capito anche secondo la "tua via" e' possibile inserire in "sources.list" sia i repos di etch che quelli di lenny, per poi decidere per ogni singolo pacchetto da quale ramo attingere, o sbaglio?
Nel caso, continuo ad aver bisogno dei files "apt.conf" e "preferences"

Circa aptitude ...ammetto di averlo snobbato alla grande finora (mi appare troppo complicato...) preferendogli i classici comandi testuali di apt (quei pochi che conosco... ;P) oppure synaptic.

Se pero' dici che e' lo strumento che piu' potrebbe essermi utile ...vado subito a documentarmi su come usarlo

Ciao e grazie...

[tindal]

Se ho ben capito anche secondo la "tua via" e' possibile inserire in "sources.list" sia i repos di etch che quelli di lenny, per poi decidere per ogni singolo pacchetto da quale ramo attingere, o sbaglio?

corretto

Nel caso, continuo ad aver bisogno dei files "apt.conf" e "preferences"

solo apt.conf: devi definire la default release, altrimenti anche aptitude non sa su che base decidere

Circa aptitude ...ammetto di averlo snobbato alla grande finora (mi appare troppo complicato...) preferendogli i classici comandi testuali di apt (quei pochi che conosco... ;P) oppure synaptic.

Se pero' dici che e' lo strumento che piu' potrebbe essermi utile ...vado subito a documentarmi su come usarlo

aptitude è lo strumento principe per la gestione dei pacchetti, anche nella debian-reference lo consigliano al posto di apt-get perchè è più bravo nella risoluzione delle dipendenze

ciao
tindal

[gmc]

Riguardo a Synaptic:

in questo momento ho nel mio sources circa una decina (o poco più) di repository diversi, e di questi alcuni con pinning.

Per ora sono riuscito a gestire tutto con Synaptic con abbastanza tranquillità: probabilmente non è così intelligente come aptitude, soprattutto sulle dipendenze di pacchetti con pinning.

Ad esempio più volte mi è successo che mi dicesse che il pachhetto xx non fosse installabile perché dipende dal pacchetto yy fermo alla versione 1. Ma in realtà è sufficiente andare sul pacchetto yy e obbligarlo (ctrl+e) alla versione 2. Dopodiché il pacchetto xx è installabile tranquillamente.

Penso che soprattutto all'inizio synaptic sia più amichevole. Però presa la mano con aptitude probabilmete si va molto più spediti.

Penso però che in una cosa synaptic sia imbattibile: sulla visione dei pacchetti tutti insieme, cioè nel girovagare a caso fra le descrizioni per vedere un po' che cosa si trova in decine di gb di pacchetti.

i miei centesimi,
Peppe

[tindal]

Ad esempio più volte mi è successo che mi dicesse che il pachhetto xx non fosse installabile perché dipende dal pacchetto yy fermo alla versione 1. Ma in realtà è sufficiente andare sul pacchetto yy e obbligarlo (ctrl+e) alla versione 2. Dopodiché il pacchetto xx è installabile tranquillamente.

si, questo succede anche con aptitude, ma in modo leggermente diverso:
se tu marchi per l'installazione il pacchetto xx diciamo proveniente da sid, che dipende da un pacchetto yy anch'esso proveniente da sid, ma la tua default release è lenny aptitude lo marca, ma ti dà anche errore, errore che risolvi marcando manualmente per l'installazione il pacchetto yy

in effetti, se ci si pensa il comportamento è più che sensato: se la default release è testing, aptitude (o synaptic) non può sapere in partenza se hai sbagliato a marcare per l'installazione il pacchetto xx o se vuoi anche il pacchetto yy: restituendo errore lascia decidere all'utente

Penso che soprattutto all'inizio synaptic sia più amichevole. Però presa la mano con aptitude probabilmete si va molto più spediti.

Penso però che in una cosa synaptic sia imbattibile: sulla visione dei pacchetti tutti insieme, cioè nel girovagare a caso fra le descrizioni per vedere un po' che cosa si trova in decine di gb di pacchetti.

è un punto di vista interessante

personalmente posso dire che anch'io inizialmente ho trovato aptitude disorientante, ma con l'abitudine anch'io girovago abitualmente tra le descrizioni dei pacchetti senza difficoltà

il vantaggio di aptitude sta nel fatto di non dipendere dalla grafica: lo puoi usare per sistemare aggiornamenti malriusciti di xorg o anche via ssh per amministrare un pc remoto

ciao
tindal

[mrx65]

Non ho abbandonato il topic... ho letto attentamente le vostre considerazioni ed ho tentato di documentarmi un po' sull' argomento "aptitude", che come gia' detto finora non mi e' stato molto simpatico...

Ferme restando le mie esigenze originali, vale a dire avere una etch condita con kernel e ntfs-3g prelevati da lenny, sulla quale piazzare il *.run dei driver proprietari per la scheda video nvidia, ho strutturato cosi' il mio sources.list:

Codice:

# deb cdrom:[Debian GNU/Linux 4.0 r3 _Etch_ - Official amd64 NETINST Binary-1 20080218-14:10]/ etch contrib main

# deb cdrom:[Debian GNU/Linux 4.0 r3 _Etch_ - Official amd64 NETINST Binary-1 20080218-14:10]/ etch contrib main


deb http://debian.fastweb.it/debian/ stable main contrib non-free
deb-src http://debian.fastweb.it/debian/ stable main contrib non-free

deb http://debian.fastweb.it/debian/ testing main contrib non-free 
deb-src http://debian.fastweb.it/debian/ testing main contrib non-free 


deb http://security.debian.org/ stable/updates main contrib non-free
deb-src http://security.debian.org/ stable/updates main contrib non-free

deb http://security.debian.org/ testing/updates main contrib non-free 
deb-src http://security.debian.org/ testing/updates main contrib non-free 


deb http://www.debian-multimedia.org/ stable main

deb http://www.debian-multimedia.org/ testing main

e questo e' il file /etc/apt/apt.conf, preso pari pari dalla guida per il pinning

Codice:

APT::Default-Release "stable";
APT::Cache-Limit 15000000;
APT::Get::Purge;
APT::Clean-Installed;
APT::Get::Fix-Broken;
APT::Get::Fix-Missing;
APT::Get::Show-Upgraded "true";

...anzi, a dire il vero lo ho dovuto riscrivere a manina, perche facendo copia-incolla dalla pagina della guida non funzionava...

Il file /etc/apt/preferences lo ho rinominato, visto che optando per aptitude non dovrebbe servire, se ho ben capito quanto scritto da tindal...

Mi restano comunque molte domande sia sull' uso pratico di aptitude, sia sull' uso di questo strumento per il pinning...

Al momento non mi trovo molto con la funzione cerca ("/"), che pare adattarsi alla tipologia di pacchetti sulla quale si e' posizionati... in pratica se inizio la ricerca quando il cursore e' su "pacchetti installati", la ricerca si limita a questi.  Mentre se ho ben capito, la ricerca puo' essere ulteriormenta ristretta, non ho trovato il modo di allargare tale ricerca a tutte e tipologie di pacchetti...

Mi e' inoltre capitato un piccolo inconveniente ...volendo installare "vlc", ho erroneamente installato "vic", con una serie di pacchetti da lui dipendenti ...la mia vista non e' piu' quella di un tempo
Ora, il problema e' che ho rimosso (con "_") il pacchetto "vic" a me inutile ...ma non so come individuare le sue dipendenze installate anch' esse per errore, che mi occupano spazio per niente...

Inoltre non ho ben capito se aptitude ha la possibilita' di sfruttare funzionalita' simili ai comandi...

Codice:

apt-get autoclean
e
apt-get autoremove

che normalmente userei per manutenere il sistema ...anche se quest' ultimo comando, usato da terminale, mi da questo errore

Codice:

:~$ apt-get autoremove
E: Operazione non valida autoremove
:~$

che sia dovuto al sources.list "misto" Oppure e' un comando assente in etch?
Forse l' equivalente di questi comandi in aptitude si trova sotto il menu "Azioni", alle voci "Pulisci la cache dei pacchetti" e "Cancella i file vecchi"...?

In ultimo, in un ottica di "pinning", aptitude ragiona in modo poi cosi' diverso da apt-get? Perche' se ho capito bene, qualora i "rami" inseriti in sources.list siano "stable" e "testing" come nel mio caso, se voglio installare un pacchetto attingendo dai repos di lenny, devo comunque lanciare aptitude con il comando

Codice:

aptitude -t testing

...non e' vero?

Buon w-end lungo  a tutti...

Ciao e grazie

[tindal]

... sulla quale piazzare il *.run dei driver proprietari per la scheda video nvidia, ho strutturato cosi' il mio sources.list ...

è sempre preferibile usare i pacchetti debian per installare i driver nvidia, a meno che non vuoi proprio installare una versione recentissima che non è ancora pacchettizzata

dal sources.list, togli le righe deb-src, a meno che tu non voglia metterti a compilare i pacchetti prima di installarli

...e questo e' il file /etc/apt/apt.conf ...

se aggiungi dei repository 15 MB di file di cache potrebbero non essere sufficienti: se un giorno ottieni un "Error: Dynamic MMap ran out of room" aumenta il Cache-Limit

Mi restano comunque molte domande sia sull' uso pratico di aptitude, sia sull' uso di questo strumento per il pinning...

veramente il pinning è quello descritto nella guida, quello che suggerisco non è pinning, ma un altro modo per gestire una distribuzione mista

Al momento non mi trovo molto con la funzione cerca ("/"), che pare adattarsi alla tipologia di pacchetti sulla quale si e' posizionati... in pratica se inizio la ricerca quando il cursore e' su "pacchetti installati", la ricerca si limita a questi.  Mentre se ho ben capito, la ricerca puo' essere ulteriormenta ristretta, non ho trovato il modo di allargare tale ricerca a tutte e tipologie di pacchetti...

no, senti, questa è una cosa che faccio quasi tutti i giorni da anni, e funziona perfettamente
solo che inizia a cercare dal punto in cui ti trovi nell'albero dei pacchetti

...ma non so come individuare le sue dipendenze installate anch' esse per errore, che mi occupano spazio per niente...

non hai bisogno di cercarle: se hai installato dei pacchetti come dipendenze di un pacchetto xx, e poi togli il pacchetto xx, le dipendenze vengono rimosse automaticamente (ma prima di farlo te lo fa vedere), a meno che tu non abbia installato qualcos'altro che ha bisogno di quei pacchetti, naturalmente

comunque, per vedere da quali pacchetti dipende il pacchetto xx ti basta selezionarlo e premere invio

Forse l' equivalente di questi comandi in aptitude si trova sotto il menu "Azioni", alle voci "Pulisci la cache dei pacchetti" e "Cancella i file vecchi"...?

quelle due voci equivalgono, rispettivamente, a "aptitude clean" e "aptitude autoclean" (o anche "apt-get clean" e "apt-get autoclean")

aptitude non ha bisogno di un comando "autoremove", perchè lo fa già da solo automaticamente

In ultimo, in un ottica di "pinning", aptitude ragiona in modo poi cosi' diverso da apt-get? Perche' se ho capito bene, qualora i "rami" inseriti in sources.list siano "stable" e "testing" come nel mio caso, se voglio installare un pacchetto attingendo dai repos di lenny, devo comunque lanciare aptitude con il comando

Codice:

aptitude -t testing

...non e' vero?

no.
se premi invio dopo aver selezionato un pacchetto, trovi un sacco di cose utili sul pacchetto, e in fondo anche le versioni disponibili: puoi installare quella che preferisci

ribadisco: questo è molto diverso dall'uso di "-t testing", perchè nel primo caso la default release è ancora stable, e anche se marchi per l'installazione un pacchetto in testing, aptitude cerca di risolvere le dipendenze usando pacchetti da stable, e se non ci riesce dà errore

l'errore non è un male: ti permette di vedere quali sono le dipendenze non presenti in stable (con "b") e decidere se installare le versioni in testing (con il metodo descritto prima) o rinunciare all'installazione del pacchetto che crea problemi

con "-t testing" non dovresti mai (o quasi) avere errori: la default release diventa testing e le dipendenze vengono tutte prese da lì

ciao
tindal

[mrx65]

Circa i driver proprietari per la scheda video, ho scelto il *.run perche' ad es in testing, il pacchetto nvida-kernel-source,  non e' presente...

...
se aggiungi dei repository 15 MB di file di cache potrebbero non essere sufficienti: se un giorno ottieni un "Error: Dynamic MMap ran out of room" aumenta il Cache-Limit

Grazie x il consiglio ...in verita' questo valore lo ho preso pari-pari dalla guida al pinning... quale potrebbe essere un valore che pone al riparo da eventuali e futuri problemi? 20Mb, 25 ...30 ...io non ne ho proprio idea 

veramente il pinning è quello descritto nella guida, quello che suggerisco non è pinning, ma un altro modo per gestire una distribuzione mista
...
ribadisco: questo è molto diverso dall'uso di "-t testing", perchè nel primo caso la default release è ancora stable, e anche se marchi per l'installazione un pacchetto in testing, aptitude cerca di risolvere le dipendenze usando pacchetti da stable, e se non ci riesce dà errore

l'errore non è un male: ti permette di vedere quali sono le dipendenze non presenti in stable (con "b") e decidere se installare le versioni in testing (con il metodo descritto prima) o rinunciare all'installazione del pacchetto che crea problemi

con "-t testing" non dovresti mai (o quasi) avere errori: la default release diventa testing e le dipendenze vengono tutte prese da lì

Si ...e' vero  ...in effetti oggi, ripensandoci, avevo intuito che ci sono delle differenze tra i due procedimenti... il tuo procedimento ricorda di piu'

Codice:

apt-get install "pacchetto"/testing

anziche'

Codice:

apt-get install -t testing "pacchetto"

...solo che viene fatto usando aptitude 

no, senti, questa è una cosa che faccio quasi tutti i giorni da anni, e funziona perfettamente
solo che inizia a cercare dal punto in cui ti trovi nell'albero dei pacchetti

Buono a sapersi! Resta il fatto che spesso con la funzione di ricerca non riesco a trovare, ad esempio, pacchetti installati, o comunque pacchetti! Tanto per capire, avendo su i repos sia di stable che di testing, ed avendo installati  sia il kernel 2.6.18 (etch) per amd64, sia il kernel 2.6.24 (lenny) sempre per amd64, se faccio una ricerca ("/")  usando come parole chiave "linux" e "image", mi aspetterei di ottenere, tra gli altri, sia il pacchetto linux-image-2.6.18-6-amd64 sia il pacchetto linux-image-2.6.24-1-amd64 ...ma in realta' mi riporta solo il secondo
Gia' che sono in tema, giusto ora, per passare un po' il tempo, da aptitude ho aggiornato la lista dei pacchetti ("u") e dopo pochi secondi update-notifier mi ha avvisato della possibilita' di aggiornare pacchetti installati ...casualmente trattasi proprio del kernel 2.6.24-1 che passa dalla "5" alla "6" ...ho controllato aptitude certo che avrebbe evidenziato anche lui questa cosa, in qualche modo ...ed invece ...niente! Perche'?

...edit: forse in tema di ricerca ho fatto un errore; solo ora ho scoperto la funzione "n" ...che mi fa vedere anche gli altri risultati, e non solo il primo fornito   
...resta pero' il fatto che aptitude non mi ha avvisato che era disponibile la versione aggiornata di un pacchetto installato dal ramo testing...

non hai bisogno di cercarle: se hai installato dei pacchetti come dipendenze di un pacchetto xx, e poi togli il pacchetto xx, le dipendenze vengono rimosse automaticamente (ma prima di farlo te lo fa vedere), a meno che tu non abbia installato qualcos'altro che ha bisogno di quei pacchetti, naturalmente

comunque, per vedere da quali pacchetti dipende il pacchetto xx ti basta selezionarlo e premere invio
quelle due voci equivalgono, rispettivamente, a "aptitude clean" e "aptitude autoclean" (o anche "apt-get clean" e "apt-get autoclean")

aptitude non ha bisogno di un comando "autoremove", perchè lo fa già da solo automaticamente

Ottimo! veramente ottimo! Gia' questo basta ed avanza per convertirmi definitivamente ad aptitude!!! 

...Resta solo da impratichirmi nella ricerca dei pacchetti ...e nel capire se e quando posso dare "U" 

Ciao e grazie, infinite!

[tindal]

Circa i driver proprietari per la scheda video, ho scelto il *.run perche' ad es in testing, il pacchetto nvida-kernel-source,  non e' presente...

certo che c'è
hai attivato anche il ramo non-free?

quale potrebbe essere un valore che pone al riparo da eventuali e futuri problemi? 20Mb, 25 ...30 ...io non ne ho proprio idea 

io uso 32MB, ma ho anche sid tra i repo (ora che ci penso ho ne anche un altro paio)
comunque, non succede nulla di grave: puoi anche fregartene finchè non ti capita

Gia' che sono in tema, giusto ora, per passare un po' il tempo, da aptitude ho aggiornato la lista dei pacchetti ("u") e dopo pochi secondi update-notifier mi ha avvisato della possibilita' di aggiornare pacchetti installati ...casualmente trattasi proprio del kernel 2.6.24-1 che passa dalla "5" alla "6" ...ho controllato aptitude certo che avrebbe evidenziato anche lui questa cosa, in qualche modo ...ed invece ...niente! Perche'?

non è che non ti avverte: te li mette tra i "pacchetti aggiornabili"
se vuoi aggiornare tutti i pacchetti aggiornabili ti basta un "+" sulla riga dei "pacchetti aggiornabili", con in più il vantaggio che prima di installare ti fa vedere cosa sta per fare e anche se ci sono errori

questo è un po' come un dist-upgrade, ma più avanzato, perchè preserva la release di ogni pacchetto: quelli che sono in stable ci restano, e vengono aggiornati solo se in stable c'è una nuova versione disponibile; idem per quelli che sono in testing se avessi attivato anche i repo di sid: se non sei tu a deciderlo esplicitamente aptitude non ti aggiorna mai un pacchetto da una release ad un'altra

in più, in caso di errori, un dist-upgrade a linea di comando mette in moto una routine che fa di tutto per correggerli calcolando diverse soluzioni e attribuendo a ciascuna un punteggio: vince quella con il punteggio più alto e l'installazione prosegue

se invece usi l'interfaccia, puoi comunque scegliere di lasciar fare a lui (premendo "g"), oppure puoi correggere a mano gli errori

"correggere a mano" suona spaventoso, ma in realtà quasi sempre è una cosa banale, ed è l'unico modo per fare esattamente quello che vuoi, perchè per quanto aptitude sia molto avanzato di certo non può leggerti il pensiero, e certe cose devi essere tu a stabilirle, lui non può sapere in partenza cosa vuoi fare

mi fa piacere che ci stai prendendo gusto, vedrai che se prendi confidenza con aptitude l'amministrazione dei pacchetti diventa una passeggiata

ciao
tindal

[Brunitika]

Ciao! Innanzi tutto, grazie mille di questa discussione! Sto cercando ora di utilizzare unicamente aptitude per la gestione dei pacchetti e mi sto rendendo conto di quanto apt-get faccia moltissimo in modo automatico. In ogni caso, il controllo del sistema con aptitude è... wow ! Facendo "pulizia", o meglio, "passeggiando" per le liste di aptitude, ho notato che in "pacchetti obsoleti o creati localmente" si trova il pacchetto "frostwire", che effettivamente ho installato con dpkg scaricando il pacchetto .deb (non essendo più presente nei repository). Il pacchetto menzionato, "domandando" (-> d) ad aptitude, dipende da sun-java5-bin e sun-java5-jre. Avendo però installato java6 i due pacchetti risultano rossi (= dipendenza non soddisfatta). Il programma funziona però benissimo anche con java6. A questo punto, è possibile "dire" ad aptitude di dare come dipendenza a frostwire i pacchetti sun-java6-bin e sun-java6-jre al posto dei due pacchetti precedenti? Non che sia importante, ma come detto precedentemente, il controllo è tutto .

PS: questa settimana sarò via fino a sabato... mi scuso di non farmi vivo fino ad allora...

[GipPasso]

Mi sembra che le dipendenze siano scritte dentro il file DEBIAN/control dentro l'archivio pacchetto.deb.
Se in esso c'è scritta un'informazione falsa, aptitude la riporta com'è, senza fare "prove".

Non so se aptitude può cambiare la sua base dati per cambiare una delle informazioni che il pacchetto porta con se nei vari file dentro la cartella DEBIAN. A occhio direi di no. Faccio una ricerchina...

GipPasso.

[Brunitika]

Dunque, se aptitude non può cambiare l'informazione legata al pacchetto, ammesso di voler risolvere il "problema" dovrei aprire l'archivio .deb, trovare il file DEBIAN/control e modificare le dipendenze "sun-java5-jre..." dando al suo posto "sun-java6-jre..."? Sebbene inutile, potrebbe funzionare? Se trovo un po' di tempo più tardi ci provo e faccio sapere.

P.S.: GipPasso, complimenti per la promozione