[Non Risolto] debmirror e accumulo di pacchetti

[pmate]

Ciao a tutti,
ho creato su hard-disk esterno un mirror di repository debian utilizzando debmirror. La comodità è portarmi dietro il piccolo hard-disk avendo con me più di 18000 pacchetti anche in situazioni in cui mi è impossibile accedere ad internet.
Il problema è questo: al momento in cui rilancio lo script per aggiornare i repository, mi aggiunge le versioni nuove senza eliminare quelle vecchie. Se ad esempio ho xclock-2.10.deb, dopo l'aggiornamento mi ritrovo xclock-2.20.deb e xclock-2.10.deb con ovvio (ed inutile) aumento dello spazio utilizzato.
Ho guardato fra i vari parametri da passare all'istruzione debmirror ma (cecità) non ho visto niente che facesse al caso mio.
Sul web poi (ariecco la cecità...) non sono riuscito a trovare delucidazioni in merito.
Consigli?

[HomerCube]

Io faccio la stessa identica cosa, ma a me le versioni vecchie vengono ripulite, anche se nel tempo.
Mi spiego: con istruzioni come questa:

Codice:

debmirror /root/debian/ \
-p -v --nosource --pdiff=none --passive \
-h=ftp.it.debian.org --method=http -r debian/ \
--dist=testing,unstable --section=main,contrib,non-free --arch=i386 \
--ignore-missing-release --ignore-release-gpg --ignore-small-errors

tengo aggiornato un repository locale delle sole componenti testing ed unstable delle sezioni main/contrib/non-free, leggendo dal mirror italiano del repository ufficiale. Ora, se il pacchetto pippo è in versione 0.65 in testing e 0.67 in unstable, nel repository li avrò entrambi; al momento in cui la 0.67 passa in testing ed in unstable finisce la 0.73, al primo update debmirror mi scarica la 0.73 e mi rimuove l'ormai obsoleta 0.65, il che è coerente con la logica con cui li prelevo.
In altri termini, è giusto che cancelli i pacchetti quando sono sorpassati per il criterio con cui li stai scaricando, non prima. Se il tuo script governa simultaneamente più livelli di stabilità come faccio io, il fatto che non vengano rimossi subito ha un senso.

[pmate]

Il problema è che io ho solo il ramo testing da governare. Per questo mi sembra strano. Fossero, come nel tuo caso, testing e unstable sì che avrebbe senso, ma solo con testing... boh?
Magari mantengono due versioni dello stesso pacchetto solo temporaneamente e poi "purgano" in seguito. Vediamo cosa succede.

p.s. ho eliminato il parametro --pdiff=none, tu invece lo utilizzi. I .pdiff non sono i files che tengono traccia delle differenze? Cosa comporta utilizzare o meno questo flag?

[HomerCube]

p.s. ho eliminato il parametro --pdiff=none, tu invece lo utilizzi. I .pdiff non sono i files che tengono traccia delle differenze? Cosa comporta utilizzare o meno questo flag?

Francamente non lo ricordo. Ho composto le istruzioni di scarico molto tempo fa prendendo a modello degli esempi in Rete, e dato che funziona tutto a meraviglia non ho approfondito (sai, come quel detto sullo spogliarello: "non stare a chiederti come lo fanno, ma goditi i risultati" ).

[pmate]

(sai, come quel detto sullo spogliarello: "non stare a chiederti come lo fanno, ma goditi i risultati" ).

eheheheh  ,
e chi se lo chiede mai???

[GipPasso]

Da "man debmirror":

--pdiff=use|mirror|none
           If the Release file contains entries for pdiff files then debmirror will atempt to update the Packages and Sources files with them but will not include them in the mirror. This is the default ’use’ behaviour and avoids having time consuming pdiff files for a fast local mirror. Specifying --pdiff=mirror will include the downloaded
           pdiff files in the mirror while specifying --pdiff=none will completly ignore pdiff files.

Io lascerei il comportamento predefinito; risparmia un po' di banda e tempo. Per essere chiaro, non mi preoccupo della vostra banda e tempo, dei quali fate quello che volete (e ci mancherebbe!), ma di quelli di ftp.it.debian.org.
Cerco di adottare sempre i comportamenti che lo fanno lavorare solo quanto è necessario, non di più. Temo però che di fronte a un'operazione grossa come l'aggiornamento di un mirror intero, la differenza sia poca: credo che scarichi i file differenza per i file Release, Packages e Sources (quest'ultimo è facile che non lo abbiate neanche).

GipPasso.

[pmate]

Da "man debmirror":
Io lascerei il comportamento predefinito; risparmia un po' di banda e tempo.
GipPasso.

Presumo che avendo tolto completamente il flag, il comportamento sia quello predefinito.
Giusto osservare che è meglio "rispettare" l'utilizzo di banda.
Rimane (per me) il mistero dell'accumulo di pacchetti...  pazienza... :'(

[GipPasso]

Prova ad aggiungere

Codice:

--cleanup

o

Codice:

--postcleanup/code]e guarda se fa il dovuto (nel primo caso prima di scaricare i pacchetti, nel secondo dopo averli scaricati).

GipPasso

[pmate]

ho letto da più parti che --cleanup agisce, grosso modo, come apt-get autoclean e quindi tira via molta più roba di quella che vorresti.
Forse la soluzione potrebbe essere rsync -r --delete   ma aspetto notizie da qualcuno che l'ha già utilizzato. Tra l'altro rsync mi restituisce errorini. Devo vedere meglio stasera, cin calma...

[pmate]

visto che non ne sono venuto comunque a capo... ho scelto di provare apt-mirror: la prima impressione è favorevole. Con un solo file (simile a sources.list) si gestisce tutto senza dover passare decine di flag ai comandi.
Vedremo...