[Proposta] Ricerca tra i files contenuti nei pacchetti

[targzeta]

Potresti:

• usare wget come ho scritto io con il --header, e quindi usare il -O, ma non il -N
• usare il -N ma non usare il -O e poi una volta scaricato il file in una directory temporanea (ad esempio /tmp) rinominarlo correttamente.

Emanuele

[conraid]

qualcosa come
slacky/MANIFEST.bz2
slackware/MANIFEST.bz2
etc/MANIFEST.bz2

può andare bene?

se sì, usa -N in abbinamento a --directory-prefix

[joe]

usare il -N ma non usare il -O e poi una volta scaricato il file in una directory temporanea (ad esempio /tmp) rinominarlo correttamente

La via con -l'header mi pare la più convincente, perchè mi consente di mantenere una cache unica.
Infatti al file temporaneo avevo pensato anch'io, ma poi?
Dovremmo tenere sia il file temporaneo (per l'aggiornamento successivo intendo) che il file rinominato (per utilizzarlo nella ricerca in locale) e non mi piace....la cache è una e tale deve restare. A meno che non sia possibile una cosa del genere:

- ho nella cache il file slacky-MANIFEST.bz2
- lo copio in tmp/finder-slacky per esempio (directory creata al volo in fase di aggiornamento) chiamandolo nuovamente MANIFEST.bz2 (come il corrispettivo remoto).
- Poi lancio wget -P /tmp/finder-slacky -N $slacky_repourl/MANIFEST.bz2
- Domanda: ma così l'opzione -N fa il suo mestiere oppure, avendo di fatto modificato il file locate va tutto a a gambe all'aria?
- Quindi ricopio l'eventuale nuovo file nuovamente nella cache fissa /var/cache/finder con il nome slacky-M...
- Infine rimuovo la directroy /tmp/finder

Questi passi consentono forse l'opzione -N e l'opzione -O al tempo stesso (dico forse perchè non so come si comporta wget con -N modificando il file locale appena prima del download). Inoltre la rimozione della dir temporanea alla fine garantisce l'assenza di inutili doppioni.
Guardando tutte quelle operazioni però mi sa che è conveniente la via del --header flag.

qualcosa come
slacky/MANIFEST.bz2
slackware/MANIFEST.bz2
etc/MANIFEST.bz2

può andare bene?

Diciamo che funziona ma comporta l'utilizzo di una cache "a sub-directories". Preferivo una cache "a files":
ls /var/cache/finder
slacky-MANIFEST.bz2
slackware-MANIFEST.bz2
ecc ecc

Tirate le somme per il momento direi che l'opzione --header di wget sembra la privilegiata.
Se però mi confermate che il metodo del file temporaneo dreato al volo funziona con l'opzione -N in modo corretto, allora anche quella potrebbe essere un'alternativa.

[targzeta]

...Dovremmo tenere sia il file temporaneo (per l'aggiornamento successivo intendo) che il file rinominato (per utilizzarlo nella ricerca in locale) e non mi piace....la cache è una e tale deve restare.

Ma a che ti serve il file temporaneo? Una volta scaricato lo devo sostituire al file originale che hai in cache. L'aggiornamento successivo lo rifai sempre e solo con il file in cache.

A meno che non sia possibile una cosa del genere:

- ho nella cache il file slacky-MANIFEST.bz2
- lo copio in tmp/finder-slacky per esempio (directory creata al volo in fase di aggiornamento) chiamandolo nuovamente MANIFEST.bz2 (come il corrispettivo remoto).
- Poi lancio wget -P /tmp/finder-slacky -N $slacky_repourl/MANIFEST.bz2
- Domanda: ma così l'opzione -N fa il suo mestiere oppure, avendo di fatto modificato il file locate va tutto a a gambe all'aria?
- Quindi ricopio l'eventuale nuovo file nuovamente nella cache fissa /var/cache/finder con il nome slacky-M...
- Infine rimuovo la directroy /tmp/finder

Devi solo copiare il file preservando il time-stamping (ora non sono su linux e non ricordo l'opzione, ma '-a' dovrebbe andare).

Guardando tutte quelle operazioni però mi sa che è conveniente la via del --header flag.

Anche secondo me, usi sempre e solo il file in cache e non se ne parla più.

Emanuele

[teox99]

Ciao ragazzi,

sono lieto di annunciarvi che sono riuscito a creare un motore di ricerca per estrarre il corrispettivo pacchetto che include il file cercato.
"Find Parent Package"
http://www.teoxonline.com/utils/sse/

il lavoro non è stato semplice dato la difficoltà di agire su file molto grandi e con particolari restrizioni frustranti di aruba.it il tutto coronato dall'uso del solo php.
vi ricordo che questa ricerca è possibile solo nei repo di slacky.eu (dove si trova il file MANIFEST). inserite l'esatto nome del file che cercate (e.s. aqhbci.so.0.0.0 ecc...)

spero sia di vs gradimento, io mi sono divertito un mondo...
un abbraccio

[joe]

Ma a che ti serve il file temporaneo? Una volta scaricato lo devo sostituire al file originale che hai in cache. L'aggiornamento successivo lo rifai sempre e solo con il file in cache.

Ma quello in cache ha un altro nome rispetto al file remoto e l'opzione -N come fà a funzionare?
cioè tu dici:

- primo aggiornamento (non ci sono files nella cache)

Codice: Seleziona tutto

wget -N -P $TMPDIR $SLACKY_URL/MANIFEST.bz2
mv -a $TMPDIR/MANIFEST.bz2 $CACHE/slacky-MANIFEST.bz2

- aggiornamento successivo al primo

Codice: Seleziona tutto

wget -N -P $CACHE $SLACKY_URL/MANIFEST.bz2

???
Ma in questo caso cosa farà wget?
chi gli dice di scaricare il file remoto che si chiama MANIFEST.bz confrontandolo proprio con quello locale che si chiama slacky-MANIFEST.bz2? Tanto più che in cache ci saranno anche altri file chiamati in modo simile... linuxpackages-MANIFEST.bz2 per esempio.
Per questo pensavo mi servisse ricopiare il file locale targato slacky- (per es.) in una dir temporanea rinominandolo con lo stesso nome del file remoto.

Quindi l'aggiornamento successivo al primo pensavo dovesse essere qualcosa come:

Codice: Seleziona tutto

mdkir -p $TMP
cp -a $CACHE/slacky-MANIFEST.bz2 $TMP/MANIFEST.bz2
wget -N -P $TMP $SLACKY_URL/MANIFEST.bz2 || exit 1
mv $TMP/MANIFEST.bz2 $CACHE/slacky-MANIFEST.bz2 || exit 1
rm -rf $TMP

Insomma qualcosa del genere...altrimenti come fai senza ricopiare il file locale in $TMP ?

PS: questo solo per chiarire....poi direi che l'opzione --header è meno problematica, almeno se funziona come la -N e permette anche il controllo del nome del file locale.

[EDIT]
Inizio a ringraziarti io per il lavoro, sicuramente sarà una funzionalità apprezzata da chi utilizza il sito
Saluti

[targzeta]

Ripendansoci mi sa che hai ragione, e mi sa che --header non funziona con -O, o meglio funziona, ma il -O da quanto dice il manuale tronca immediatamente il file, e quindi non servirebbe uguale.

Io farei così, una directory di cache in cui ci metti tutti i manifest come hai detto tu, più un file (ad esempio casa.txt) con all'interno in ogni riga, "URL nome-locale", ad esempio:

Codice: Seleziona tutto

http://repository.slacky.eu/gnome-slacky-12.0/MANIFEST.bz2 gnome-slacky-12.0-MANIFEST.bz2
http://repository.slacky.eu/gnome-slacky-12.1/MANIFEST.bz2 gnome-slacky-12.1-MANIFEST.bz2

Quindi eseguirei uno script del genere ad esempio casa.sh:

Codice: Seleziona tutto

TMPDIR=$(mktemp -d -p /tmp); 
IFS=$'\n'; 
for riga in $(<casa.txt); do 
  repos=${riga% *}; 
  manifest=${riga#* }; 
  cp -p $manifest ${TMPDIR}/MANIFEST.bz2
  wget -N -P $TMPDIR $repos
  cp -p -f ${TMPDIR}/MANIFEST.bz2 $manifest
done
rm -rf $TMPDIR

Provalo con:

Codice: Seleziona tutto

sh casa.sh

se lo esegui due volte la seconda volta non scarica niente e i file originali vengono mantenuti.
NOTA: che nel for ci ho messo il nome del file, che nel mio caso era casa.txt!

Se non ti è chiaro chiedi pure,
Emanuele

[joe]

Già, capisco...allora il file temporaneo "ce lo dobbiamo tenere". Del tuo esempio non ho capito (cioè non conosco il significato dei simbili) % e # per la inizializzazione delle variabili riga e repos. Anche io avevo già impostato lo script così per fare l'upgrade anche se avevo usato un'altra forma sia per il file contente i repo che per lo script:

in pratica pensato il file "repos" contente un nome locale e indirizzo remoto del MANIFEST.bz2 del tipo:

Codice: Seleziona tutto

slacky repository.slacky.eu/blabla/MANIFEST.bz2
linuxpackages repository.linuxpackages.net/blabla/MANIFEST.bz2

in pratica poi nella cache i file assumerebbero il nome:

$NOME-MANIFEST.bz2
Quindi avevo pensato più o meno come te ad una cosa del genere:

Codice: Seleziona tutto

while read name url
do
  cp -p $CACHE/$name-MANIFEST.bz2 $TMPDIR/MANIFEST.bz2
  wget -N -P $TMPDIR $url
  cp -p -f $TMPDIR/MANIFEST.bz2 $CACHE/$name-MANIFEST.bz2
done < $repos
rm -rf $TMPDIR

Il concetto non cambia quindi.
Solo per capire meglio:

- cosa potrebbe cambiare in termini di prestazioni tra il mio "while read" e il tuo "for riga in"?
- quando si ricopia il file aggiornato nella cache hai usato cp -p -f: il flag -p preserva tra le altre cose il timestamp che è ciò che ci interessa, mentre il flag -f? è necessario pesantemente o è una sicurezza?

Detto questo...volendo fare un discorso così tanto per:
Il limite di questa procedura sta nella dimentione del file MANIFEST.bz2, in particolare quello di slacky è particolarmente corposo visto che per la 12.2 sono circa 3.5 MB.
Personalmente mi ritrovo una connessione piuttosto medievale via cellulare (15/20KB/s in download)...per questo mi rendo bene conto che: se ogni volta che voglio cercare un file mancante dovessi fare l'update del MANIFEST....conviene cercare ancoraa via google forse o usare il motore di ricerca che state mettendo in piedi sul sito.
Ovviamente, proprio per questo nello script chemi stavo costruendo (chiamiamolo repofind) ho predisposto delle opzioni da passare in modo che di default non fa l'update ma lavora solo in locale, e poi ogni tanto con comodo lo lancio con "repofind -u" e fà l'aggiornamento (oltre volendo a d eseguire la ricerca).
Questo schema lo manterrei perchè garantisce una rapidità molto comoda.
Ma sarebbe bello poter aggiornare scaricando un file di dimensioni molto più piccole...non penso sia fattibile, intravedo problemi di gestione che non giustificano l'impresa....Ma tanto per dire:
avete presente il meccanismo delle patch:
in locale ho un grosso file vecchio e lo trasformo nella versione nuova applicando una patch che è un file di dimensioni molto ridotte rispetto al malloppo che ho in locale. Quindi l'idea potrebbe essere quella di pubblicare il MANIFEST.bz2 come ora e successivamente i files Manifest-1.diff.gz Manifest-2.diff.gz eccecc.
Così si dovrà scaricare il MANIFEST grosso solo la prima volta ed in seguito per aggiornarlo basterà la patch, o le patch.
Si potrebbe pensare ad un'organizzazione stile backup, cioè un meccanismo differenziale (no...forse il termine è sbagliato... forse anche prograssivo, insomma una cosa mista), va bè mi spiego con un esempio:
- creo il MANIFEST.bz2 a fine mese, meglio dire 30 giorni (quindi una volta al mese è disponibile un nuovo file MANIFEST completo).
- a fine di ogni 10gg creo una patch con le differenze tra la situazione a fine settimana e l'inizio della settimana stessa. Quindi uno schema progrssivo.
- alla fine di ogni giorno creo una patch con le differenze dall'inizio dei 10gg.

In pratica avrei alla fine dei trenta giorni:

MANIFEST.bz2 (pubblicato alla fine dei trenta giorni precedenti)
manifest-1.diff.gz
manifest-2.diff.gz
manifest.3.diff.gz

In questo modo chi aggiorna da connessioni lente è molto avvantaggiato perchè se ha già il MANIFEST.bz2 del mese precedente, basta che scarichi le patch, e a seconda dei casi magari non servono neanche tutte, al limite anche solo l'ultima...
Io ho fatto l'esempio di 1 mese, ma si potrebbero dilatare un po' i tempi (calcolando che una release di slackware avviene circa ogni 10 mesi).
Oppure si potrebbe decidere di tenere sempre il MANIFEST originale anzi quello del primo mese che avrà assunto dimensioni considerevoli e da lì mantenre solo patch di 10 giorni aggiornando l'ultima di giorno in giorno. Quindi si avrebbe dopo dieci mesi:

MANIFEST.bz2
manifest-1.diff.gz
manifest-2.diff.gz
.....
manifest-29.diff.gz
manifest-30.diff.gz

Riassumendo una politica di patches dal MANIFEST.bz2 eggiornato ai primi 30 gg.
- con le patch a 10 gg bassate su politica incrementale (ecco, m'è venuto in mente)
- e l'ultima, quella dei 10 giorni correnti, basata su politica differenziale in relazione all'aggiornamento della fine dei 10 gg precedenti.

========
Non so se sia possibile introdurre anche questa procedura alla gestione del repository, perchè penso che il MANIFEST.bz2 così com'è, completo ed aggiornato ogni giorno costituisca una sorta di standard e sa necessrio anche ad altri tool (non conosco swaret o slaptget...ma può darsi che ne abbiano bisogno). Questo problema è facilmente aggirabile: basta mantenere il MANIFEST.bz2 così come è ora e semplicemente aggiungere un directory del repo con un file first-MANIFEST.bz2 relativo ai primi 30 gg di sviluppo del repo di una nuova versione slackware per esempio, o comunque relativo alla siituazione attuale. E aggiungere man mano le patch sempre in quella directory. Così il repo resta "inalterato" e viene aggiunta solamente una funzionalità non invasiva.

Un problema allora sarebbe l'aumento della occupazione files del repo: non penso che questo sia veramene un grosso problema: se il MANIFEST.bz2 occupa 3.5 MB, anche la nuova directory da ospitare sarà su per giù di quella dimensione, forse qualcosa in più..mettiamo 10 MB per dire un numero...per ogni ramo mantenuto...facciamo un 100 MB in più rispetto d ora? Non so...potrebbe essere anche un problema, forse, a meno chè alcuni rami non vengano più mantenuti, non so.

Altro problema occorre predisporre in aggiunta all'attuale aggiornamento quotidiano del MANIFEST.bz2 anche la creazione dell'ulitma patch.
Non so come viene fatto l'aggiornamento del Manifest, che linguaggi ci siano di mezzo o cosa insomma, tanto più che non sono un programmatore, ma partendo dai comandi shell.. gzip e diff, la creazione delle patch non è certo cosa difficile...tuttavia ignorando le modailtà di gestione del repository non mi pronuncio sulla fattibilità dell'introduzione di queste procedure.

Insomma, concludendo diciamo che sono solo idee che avevo in testa e ho pensato di condividerle con voi. Potrebbe essere un punto di partenza per dar vita realmente ad una funzionalità alternativa al repository, potrebbe restare solo un idea. In ogni caso mi piacerebbe sapere cosa ne pensate.
Sono andato lungo eh? Mi spiace...è che mi sembra di spiegarmi meglio con degli esempi, che purtroppo però comportano righe di post in più.
Saluti e grazie per la consueta disponibilità.

[teox99]

il file manifest è un listato di tutti i files con i relativi pacchetti che li includono, compresso in bzip2
ciò significa che comunque bisogna decomprimere il file (circa 50mb) in stdout o su hdd per farne una ricerca al suo interno.
l'aggiornamento con le patch può essere un alternativa ma non mi sembra una soluzione anzi... il processo diventerebbe più macchinoso.

secondo me e per ovvi motivi questa procedura è più indicata per essere eseguita lato server.
inutile quindi andare a mettere mano e a complicare la gestione e/o aggiornamento dei manifest.
come puoi vedere dal mio script php ti basta inserire il nome del file esatto ed il server non fà nient'altro che

- connettersi al srv specificato
- scaricare il file MANIFEST.bz2 (solo se aggiornato)
- decomprimere il MANIFEST
- cercare la stringa al suo interno
- individuare il pacchetto contenente la stringa

+ invio del pacchetto trovato al motore di ricerca
- scarico FILELISTS (solo se aggiornato) del repo
- individuazione della path del pacchetto sul srv
- restituzione del url da dove scaricare il pacchetto che include il file che stai cercando.
----------
il tutto avviene in remoto aspettando qualche secondo.

credi ancora nelle patch?

[joe]

Ciao, si ho visto il tuo tool e mi pare ottimo.
Se devo fare un appunto: forse sarebbe il caso di migliorare la situazione consentendo anche le ricerche inesatte, a pattern generici.

Note: "Parent pkg Search" is useful only with the exact file name and with Slacky.eu Repos.

Non so quali problematiche coinvolga, ma mi sembra una possibilità interessante. Al limite se il pattern è contenuto in più di un pacchetto bè allora verrà restituito più di un pacchetto.
Inoltre proprio per migliorare la ricerca per pattern, si potrebbe mostrare anche il percorso del files cui apparterrebbe il pattern tipo /usr/lib/libtorrent.so.9 per fare un esempio.

Ripeto, la butto lì. E aggiungo che in effetti, questo motore di ricerca mi induce ad abbandonare il discorso delle patch.
Anzi, senza nulla togliere al tuo lavoro, direi che il discorso delle patch viene meno proprio per la tua spiegazione circa la necessita di scompattare il file di 50 MB...
Se questo problema non vi fosse, allora anche l'approccio a la patch non sarebbe da scartare. Perchè?
Perchè e comunque un alternativa che percorre un altra strada per raggiungere lo stesso obiettivo.

Il motore di ricerca remoto ha un approccio "on line": delocalizza il lavoro di calcolo, sfruttando il server sui cui è implementato e questo è un bene. Fa risparmiare spazio sul nostro disco, e anche questo è un bene.
Ma ha il limite che se il server è down, o il motore subisse qualche problema saremmoa piedi e dovremmo ricorre a google.

Il discorso di scaricare il MANIFEST in locale e usare lo script di spina, ha un altra filosofia, molto meo "on line" e molto più "dialup".
Ovvero scarico tutto il necessario e lavoro offline. La soluzione delle patch avrebbe potuto ottimizzare la fase di download in locale del necessario.
Se il repo è down, uso il tuo motore di ricerca, o nella improbabile casualità che entrambi siano down o comunque non funzionanti correttamente, uso lo script prendendo il MANIFEST da un mirror.

Insomma, vedo le due vie come complementari...anche perchè ho osservato che l'estrazione del MANIFEST è un processo noioso intermini di tempo, se si vuole stampare a video il contenuto: bunzip -c MANIFEST.bz2.
Ma se si redirige l'output su un file, o semplicemente si estrae su file, allora i tempi si accorciano moltissimo, rivalutando l'operazione di estrazionee di conseguenza anche l'applicazione di eventuali patch. Sta sera magari provo a scaricare il manifest di oggi: in locale ho quello di qualche giorno fa....mi hai fatto venire la curiosità. Proverò ad eseguire un diff, creando di fatto una patch da applicare al vecchio per farlo diventare come il nuovo...tanto per vedere anche quanto risulterebbe grande una patch di pochi giorni.
Poi magari provo anche ad applicarla per vedere se l'aggiornamento è palesemente lento o ci può stare.
Ad ogni modo complimenti di nuovo per il lavoro che hai fatto e grazie anche per avermi dato spunti di riflessione.

[teox99]

ciao joe,
prima di tutto ti ringrazio,

e poi vorrei consigliarti di non perdere di vista il problema che inizialmente era quello di cercare il file necessario e quindi specifico che manca all'esecuzione di un'applicazione, ricercando il pacchetto che lo contiene.
Cercare pattern generici in MANIFEST è alquanto inproduttivo ed esoso data la grandezza del file.

comunque mi piacerebbe avere dei riscontri dalle tue prove in locale, tienimi aggiornato anche su i tempi di esecuzione degli script di ricerca.

[joe]

Sì, in efffetti hai ragione....sarà che vedere ad occhio /usr/lib/libblabla.so.01 dava una certa sicurezza. Ma non è un problema, l'importante è il pacchetto.
Comunque ti rimando al link che avevo postato al primo post della ormai lunga discussione. se fai una ricerca per pattern ottieni risultati che esplicitano diversi record comprendenti appunto il pattern. Se non sono stato chiaro chiedi pure. Insomma intendo che potresti prendere uno spunto anche da lì.

Ad ogni modo vorrei ripetere, il più direi che è fatto in effetti se manca una libreria ci viene ammonito cno un errore che specifica il nome esatto del file mancante...

Per le prove di ricerca in locale, dopo provo. Farò sapere. Anzi se altri vogliono provare per incrociare le osservazioni....fate pure, più ce ne....

[joe]

Ho eseguito la prova:

- creata un directory in cui vi ho messo un MANIFEST.bz2 di qualche giorno fa e quello di ieri sera rinominato MANIFEST.new.bz2.
- ho fatto uno script che stampa la data all'inizio, dopo la creazione della patch e alla fine del processo di patching.
- essenzialmente lo script crea la patch che trasforma il MANIFEST.bz2 in MANIFEST.new.bz2. Porta la directory ad uno stato in cui contiene solamente la patch new.diff.gz e il MANIFEST.bz2 vecchio. Poi applica la patch al file MANIFEST.bz2 (ovviamente, lo estrae, applica, ricomprime).
Ecco lo script:

Codice: Seleziona tutto

#!/bin/bash

echo $(date)
echo running...
bunzip2 -c MANIFEST.bz2 > MANIFEST
bunzip2 MANIFEST.new.bz2
diff -u MANIFEST MANIFEST.new > new.diff
gzip new.diff
rm MANIFEST.new MANIFEST
echo
echo patch creation finished!
echo $(date)
echo
echo
echo try to patch old MANIFEST
echo running....
bunzip2 -c MANIFEST.bz2 > MANIFEST
zcat new.diff.gz | patch -p0
rm MANIFEST
echo
echo process finished!
echo $(date)

E qui ecco il risultato con i tempi in gioco.
Non so se c'è qualche altro modo per ottenere meglio il tempo impiegato per l'esecuzione di una parte di script...

Codice: Seleziona tutto

Wed May 20 08:23:58 CEST 2009
running...

patch creation finished!
Wed May 20 08:24:14 CEST 2009


try to patch old MANIFEST
running....
patching file MANIFEST

process finished!
Wed May 20 08:24:27 CEST 2009

Niente di rapidissimo, come si può vedere, poi dipende anche dalle risorse hardware, a parte il primo pezzo che è eseguito lato server.
Va bè. Fate pure sapere le vostre opinioni.
Magari si può anche ottimizzare lo script in modo da rendere la procedura più rapida, se ne siete a conoscenza dite pure.

[joe]

Leggendo la recente discussione sui formati di compressione e la convenienza della decisione di passare ai pacchetti .txz, ho adocchiato il comando "time" che è stato usato da alcuni utenti per testare appunto le differenze tra i vari metodi di compressione.
Così ho deciso di modificare il mio script del post precedente al fine di ottenre i tempi della creazione della patch (quindi l'impegno eventuale del server) e i tempi dell'applicazione della patch, che coinvolge in prima persona l'utenza...lato client diciamo.
Ecco lo script:

Codice: Seleziona tutto

#!/bin/bash

makediff()
{
  bunzip2 -c MANIFEST.bz2 > MANIFEST
  bunzip2 MANIFEST.new.bz2
  diff -u MANIFEST MANIFEST.new > new.diff
  gzip new.diff
} 

updatemf()
{
  bunzip2 MANIFEST.bz2
  zcat new.diff.gz | patch -p0
  bzip2 -z MANIFEST
} 

echo "Making patch:"
time makediff
echo
rm MANIFEST.new MANIFEST
time updatemf
echo

Alcune indicazioni ovvie: lo script va lanciato da una directory contente due file MANIFEST:
MANIFEST.bz2
MANIFEST.new.bz2

La prima funzione crea la patch portando la directory a contenre solamente:
MANIFEST.bz2
new.diff.gz

Da questa situazione si parte ad applicare la patch per giugere ad avere:
MANIFEST.bz2 (patchato, quindi aggiornato).

Ok, ho lanciato lo script preceduto dal comando time: in tal modo si vedono i tempi:
- della creazione della patch (time applicato alla funzione makediff)
- della della applicazione della stessa (time applicato alla funzione updatemf)
- il totale impiegato per l'esecuzione dell'intero script

Vediamo allora l'output:

Codice: Seleziona tutto

$ time ../patchcreate.sh
Making patch:

real    0m15.741s
user    0m13.287s
sys     0m1.085s

patching file MANIFEST

real    0m58.686s
user    0m50.044s
sys     0m1.029s


real    1m15.364s
user    1m3.343s
sys     0m2.195s

Non mi piace: se il tempo effettivo impiegato è la voce real, il processo d'update è troppo lungo: 1 minuto e 15 secondi... no, non mi piace.
Andando a vedere ho notato che il grosso dell'operazione sta nella ricompressione del file MANIFEST patchato. Ovvero, per ricollegarmi al topic sui formati di compressione dei pacchetti, in questo caso ci si scontra con bzip2 che impiega parecchio tempo a comprimere un file effettivamente grande.

Rinunciare in toto alla compressione del manifest locale significherebbe mantenere occupati 50 MB di HD... Ci può anche stare ma a me non piace, anche se andando a vedere, effettivamente per usare il tool, 50 MB liberi servono in ogni caso.
Ok, allora mi sono chiesto....e gzip quanto impiegherebbe a comprimere il file?
Così ho modificato lo script sostituendo alla compressione via bzip2 quella via gzip.
Ecco l'output:

Codice: Seleziona tutto

$ time ../patchcreate.sh
Making patch:

real    0m15.178s
user    0m13.348s
sys     0m1.057s

patching file MANIFEST

real    0m13.946s
user    0m10.071s
sys     0m0.968s


real    0m29.217s
user    0m23.429s
sys     0m2.109s

Disarmante: il tempo necessario per applicare la patch e ricomprimere il MANIFESTè diventato 1/4.
insomma gzip in questo caso sarebbe ottimo, perchè da una parte riduce il file a 4.5 MB (contro 3.5 di bzip2) per cui trattandosi di un file da usare in locale, 1 MB di differenza non è neanche rilevante. D'altra parte consente di risparmiare 50 MB che altrimenti resterebbero sempre occupati, infine in fase d'utilizzo dello script dovrebbe essere discretamente piùrapido anche nella decompressione del "MANIFEST.gz".

Per scrupolo, ho provato anche a saltare la ricompresione a piè pari e ne mostro i risultati:

Codice: Seleziona tutto

$ time ../patchcreate.sh
Making patch:

real    0m15.478s
user    0m13.859s
sys     0m1.206s

patching file MANIFEST

real    0m12.415s
user    0m6.494s
sys     0m0.938s


real    0m28.710s
user    0m20.365s
sys     0m2.258s

In pratica la compressione via gzip mangia un secondo alla procedura di patch (funzione updatemf).
Ok. direi che gzip si può tranquillamente coinvolgere nella procedura.

Ricapitolando: in questo post ho descritto alcuni tests circa la pesantezza della procedura di creazione/apllicazione di ipotetiche patch volte all'aggiornamento del MANIFEST.bz2. Non ho chiarito il funzionamento dell'intero eventuale tool di aggirnamento, ma solamente aggiunto altri aspetti a quanto s'era già affermato in precedenza.
Vorrei solo far notare che, se il MANIFEST remoto per 3.5 MB, e la banda si paga (come faceva notare conraid in altro post), bè allora scaricare un file di testo di cui gran parte si possiede già in locale mi pare un grosso spreco.
La soluzione del motore di ricerca remoto è validissima. Ma come ho già detto, anche un toll che lavori offline potrebbe essere una valida alternativa da affiancargli.

Detto questo, si potrebbe pensare all'impostazione, sempre ipotetica, della creazione e pubblicazione delle patch al manifest.bz2 remoto.
Io avevo fatto un'esempio alcuni post fà:
un MANIFEST.bz2 di partenza, bello grosso (diciamo ad 1 mese dalla creazione del ramo di slackware oppure quello relativo alla situazione attuale).
Questo file resterà sempre uguale sul repo remoto: lo si scarica una volta sola e in locale si potrebbe anche convertire in formato compresso .gz, in modo che sia più maneggevole in fase di utilizzo (ricerca records, aggiornamento).
Poi, io ho accennato all'utilizzo di una serie di patchs pubblicate con politica differenziale giornalmente, e con politica incrementale ogni 10 giorni. Sia chiaro che è solo un esempio (spero comunque ragionevole) poi chi gestisce il repository saprà meglio di me trovare la giusta politica di rilascio.
Ecco, in base alla politica scelta, sarà possibile definire nel dettaglio il funzionamento dell'update del file MANIFEST locale.
Sempre nel post precedente avevo cercato di sottolineare come sarebbe possibile aggiungere questa funzionalità al repository senza apportare modifiche e cambiamenti invasivi:
- si lascia tutto com'è col MANIFEST.bz2 classico aggiornato girnalmente così come e dove è adesso: in tal modo gli eventuali tool che ne fanno uso non subiscono cambiamenti e la gestione attuale è comunque garantita.
- si predispone semplicemente una nuova directory nel repo del tipo "repository.slacky.eu/slackware-versione/manifest". Al suo interno sarà presente il MANIFEST.bz2 originale e le varie patches, delle quali l'ultima, la più recente sarà aggiornata giornalmente sul server. In modo tale che il client valuta le versioni locali delle patch già applicate e scarica solo quelle necessarie per aggiornare il MANIFEST locale (questo è facilmente implementabile nel client, o mantenedo in cache una dir sincronizzata con la directory "manifest" remota, oppure registrando su un file la versione dell'ultima patch applicata...sono solo esempi).

Mi pare di avere detto anche troppo, e anzi mi scuso per l lunghezza di questo post.
Ogni parere ed opinione è benvenuto.
Saluti

[targzeta]

Offtopic: Occhio perchè se esegui 'time' molto probabilmente non esegui il comando /usr/bin/time, ma il comando 'time' interno a bash. Prova facendo

Codice: Seleziona tutto

type time

e se ti risponde qualcosa del genere "time is a builtin command" allora quello che esegui è il comando 'time' interno alla shell, il suo manuale (come tutti quelli relativi ai comandi interni della shell) lo trovi con:

Codice: Seleziona tutto

help time

[/offtopic]
Rientrando in topic, come ben sai stiamo cercando di aggiornare il motore di ricerca dei pacchetti, una volta fatto ci sarà la possibilità di cercare un pacchetto anche attraverso il nome dei file che installa. Quindi, anche se ammiro la tua caparbietà...

Emanuele