Allarme: removepkg lento !!! .. quasi [Risolto]

[Luci0]

Il progetto GSlacky, nato dal febbrile lavoro del mitico Gohanz e supportato d Submax82 , e Loris é giunto alla quarta versione (Gnome-Slacky 2.18.2) .
Il CD di installazione si può scaricare con bittorrent http://gnome.slacky.eu/gnome/11.0/2.18. ... in.torrent
o da ftp si monta il CD e si installa dall' installer ... e non ci sono grossi problemi ... l' installazione di tutti i pacchetti prende al massimo 1 ora con un PC non di ultimo grido ...
A questo punto mi direte ... ma qual' é il problema .. ???
Il problema viene fuori se si aggiorna la versione precedente con la nuova, il tempo necessario è di 4 o 5 ore.
Tutto questo tempo in più é dovuto al fatto che per aggiornare i pacchetti lo script di istallazione utilizza il comando

Codice: Seleziona tutto

upgradepkg --install-new

che a sua volta richiama

Codice: Seleziona tutto

removepkg

che impiega in genere un 50/60 secondi sul mio PC per controllare se può cancellare i file deliberatamente o se sono utilizzati da altri pacchetti ... e questo lo fa per circa 400 volte ovvero per il numero dei pacchetti che sono presenti nel CD e questo spiega perché se per un installazione basta un ora per l' upgrade ce ne vogliono 4 o 5...
Le soluzioni sono due, cercare di migliorare le performance di removepkg oppure accorpare molti pacchetti in un megapacchetto ... io con questo post getto solo il sasso nello stagno perché oltre l'analisi del tipo di problema non credo di essere in grado di fare altro
Altre info su questo argomento le potete trovare negli ultimi post qui ... viewtopic.php?t=19300&start=15&postdays ... highlight=

[submax82]

io ripeto

per come la penso non modificherò mai removepkg di slackware per gnome-slacky ... sarebbe una cosa assurda visto che non deve essere intrusivo...

al contrario potrei anche modificarlo e proporre le modifiche a Pat ma non penso di migliorare una cosa che è anni che resiste inalterata... (dal 2001)

comunque non includerei mai una modifica del genere in gnome-slacky ...

e aggiungo che si si potrebbero fare mega-pacchetti ma l'aggiornamento da una versione precedente lascerebbe in /var/log/packages i pacchetti della vecchia versione e il mega pacchetto nuovo che include i pacchetti vecchi aggiornati ... cioè mi sono spiegato male

esempio:

megapack1 1.0= pippo 1.1 + pluto 2.0 + paperino 2.1

dopo l'aggiornamento in /var/log/packages rimane

megapack1 1.0
pippo 1.0
pluto 1.9
paperino 2.0

capito?! ... inoltre se voglio aggiornare un pacchetto per mille motivi non è facile capire che versione ho installato sul sistema perchè avrò solo

megapack1
megapack2

ecc...

oltre al fatto che non si capisce quali pacchetti installa gnome-slacky perchè non rispecchierebbero i tarball dei rilasci ecc....

insomma anche questa soluzione è da scartare

[Luci0]

Submax82 tu sei in grado di capirci qualcosa in removepkg ... io no !! ... la mia intenzione era solo quella di sollevare il problema ... non di risolverlo ... sono già contento che tu abbia risposto !!
Sta di fatto per fare l'aggiornamento di Gnome-Slacky o di un intera Slackware occorrono tempi geologici e in effetti come afferma lo stesso Gohanz si fa prima a formattare ed installare ex novo la Slackware + Gnome-Slacky, in un ora mezza ci si riesce ... contro quattro per l'aggiornamento ... il problema causato da removepkg, posto in questi termini é evidente ..

[algol]

Beh, oltre alla fondamentale problematica sollevata da submax82, bisogna pensare che upgradepkg si va a leggere tutti i file in /var/log/packages alla ricerca di conflitti e condivisioni; quindi, mi domando, se ci sono tre file con 50 voci ciascuno, che accorpati diventano un file con 150 voci, lui comunque se le va a controllare, essendo lento uguale, no?

A.

[Luci0]

Se ci fosse un sort più veloce o comunque trovare il modo di velocizzare il sorting si migliorerebbero le prestazioni di removepkg ...

[mauro]

Dopo aver letto questo post mi sono messo a giocare un po' con removepkg.

Ho fatto qualche prova: se al posto di valutare tutti i pacchetti da rimuovere individualmente li si considerano tutti insieme (modificando remove_packages()), ovvero gli si fa fare un listone di file da rimuovere e lo si `sorta' e confronta una sola volta al posto di fare tanti piccoli sort e confronti a me risulta piu' veloce (piu' o meno il doppio, ma l'ho provato solo con -warn e dandogli in pasto una decina di pacchetti per volta). Non ho ancora controllato come poi removepkg venga richiamato da upgradepkg ne' se il mio tentativo possa in qualche caso fare casino.

[Luci0]

Ho fatto un pò di ricerche (=google) se esistono alternative al comando sort ... e ho trovato questo rsort http://jeenyus.net/~budney/linux/softwa ... .10.tar.gz che promette di essere sicuramente 10 volte più veloce di gnu sort e in alcuni casi 25 volte... sarà vero ???
Ma sopratutto é utilizzabile ... in removepkg??

Sort viene utilizzato all' interno di removepkg con le opzioni sort -u e sort -r che credo siano diverse da quanto fa rsort ... comunque credo che qualche prova si possa fare ... quantomeno tirare giù uno script con un pacchetto di test per fare dei benckmark per su removepkg ...

[absinthe]

credo che le uniche modificha fattibili siano di tipo logico. negli algoritmi voglio dire. Pat fa una religione di scrivere i tool di gestione in ash e utilizzando il numero minore di applicativi possibile! così da rendere fortenete compatibili i tool con qualsiasi shell e riducendo al minimo i programmi necessari (le core utils sed grep e niente più mi pare...)

più che altro il fatto è che uprgadepkg prima fa un'installazione temporanea poi rimuove un eventuale pacchetto e poi reinstalla ancora se ben ricordo!

M

[Luci0]

Testare rsort non per vedere se é utilizzabile non dovrebbe essere così difficile ... poi bisogna vedere se effettivamente é utile per removepkg ...
... insomma mi sembra che qualcuno si stia stia fasciando la testa prima di essersela rotta ...
Ripeto come coder in una scala da 1 a 10 io valgo 1/2 ... ma sono molto testardo

[B4sH]

io di programmazione ho competenze pari allo 0,00% ma un po leggendo di quà e di là mi era venuto in mente che per velocizzare l'operazione di removepkg non potrebbe essere usato un database dei pacchetti installati? O comunque qualcosa del tipo, scrivere in un file di testo tutti i pacchetti installati e cercare in tale file, piuttosto che nella directory /var/log/packages ?
Forse ho detto troppe idiozie, chiedo perdono

[mauro]

scrivere in un file di testo tutti i pacchetti installati e cercare in tale file, piuttosto che nella directory /var/log/packages ?

questo viene gia' fatto da removepkg prima di iniziare con i vari sort e comm, comunque non porta via tanto tempo (a me un cat /var/log/packages/* > daqualcheparte/qualchefile prende 1 sec. circa)

[Luci0]

Rsort non compila ... fine delle trasmissioni !! per ora ...

[mauro]

l'idea di rimuovere i pacchetti in un colpo solo limitando i sort sembra funzionare (esperimento con i primi 40 pacchetti in ordine alfabetico)

Codice: Seleziona tutto

root@slackino:~# time ./multi_removepkg -multi -warn 3ddesktop-0.2.9-i486-3sl aaa_base-11.0.0-noarch-2 aaa_elflibs-11.0.0-i486-9 acl-2.2.39_1-i486-1 acpid-1.0.4-i486-2 alsa-lib-1.0.11-i486-1 alsa-utils-1.0.11-i486-2 apache-1.3.37-i486-2 ash-0.4.0-i386-1 atk-1.10.3-i486-2 attr-2.4.32_1-i486-1 autoconf-2.60-noarch-1 automake-1.9.6-noarch-1 bash-3.2.017-i486-1_slack11.0 bin-11.0-i486-3 bin86-0.16.15-i486-1 binutils-2.15.92.0.2-i486-3 bison-2.1-i486-1 boost-1.33.1-i686-3as bsd-games-2.13-i486-8 bzip2-1.0.3-i486-3 cairo-1.0.4-i486-1 conky-1.4.5-i486-1sl coreutils-5.97-i486-1 cpio-2.5-i386-1 cxxlibs-6.0.3-i486-1 cyrus-sasl-2.1.22-i486-1 dcron-2.3.3-i486-5 dejavu-ttf-2.10-noarch-1 devs-2.3.1-noarch-25 diffutils-2.8.1-i486-3 doxygen-1.4.7-i486-1 e2fsprogs-1.38-i486-2 etc-11.0-noarch-2 file-4.20-i486-1_slack11.0 findutils-4.2.28-i486-1 flex-2.5.4a-i486-3 fluxbox-1.0rc2-i486-1 fontconfig-2.4.2-i486-2_slack11.0 freetype-2.3.4-i486-2_slack11.0 > /dev/null

real    0m27.173s
user    0m20.313s
sys     0m4.172s
root@slackino:~# time removepkg -warn 3ddesktop-0.2.9-i486-3sl aaa_base-11.0.0-noarch-2 aaa_elflibs-11.0.0-i486-9 acl-2.2.39_1-i486-1 acpid-1.0.4-i486-2 alsa-lib-1.0.11-i486-1 alsa-utils-1.0.11-i486-2 apache-1.3.37-i486-2 ash-0.4.0-i386-1 atk-1.10.3-i486-2 attr-2.4.32_1-i486-1 autoconf-2.60-noarch-1 automake-1.9.6-noarch-1 bash-3.2.017-i486-1_slack11.0 bin-11.0-i486-3 bin86-0.16.15-i486-1 binutils-2.15.92.0.2-i486-3 bison-2.1-i486-1 boost-1.33.1-i686-3as bsd-games-2.13-i486-8 bzip2-1.0.3-i486-3 cairo-1.0.4-i486-1 conky-1.4.5-i486-1sl coreutils-5.97-i486-1 cpio-2.5-i386-1 cxxlibs-6.0.3-i486-1 cyrus-sasl-2.1.22-i486-1 dcron-2.3.3-i486-5 dejavu-ttf-2.10-noarch-1 devs-2.3.1-noarch-25 diffutils-2.8.1-i486-3 doxygen-1.4.7-i486-1 e2fsprogs-1.38-i486-2 etc-11.0-noarch-2 file-4.20-i486-1_slack11.0 findutils-4.2.28-i486-1 flex-2.5.4a-i486-3 fluxbox-1.0rc2-i486-1 fontconfig-2.4.2-i486-2_slack11.0 freetype-2.3.4-i486-2_slack11.0 > /dev/null

real    3m23.131s
user    2m27.337s
sys     0m32.034s
root@slackino:~# 

provato ancora solo con -warn, mai ``per davvero''. Poi andrebbe fatta anche una versione modificata di upgradepkg per richiamare il removepkg modificato passandogli tutti i pacchetti contemporaneamente.

[mauro]

riprovato da casa (i post di oggi erano in pausa a lavoro su un pc di prova).

ho preso 120 pacchetti a caso (ma sempre gli stessi nei tre test, sempre -warn e reindirizzando l'output su file)
1a prova: multi_removepkg : 26 secondi
2a prova: removepkg : 4min e 24 secondi
3a prova: multi_removepkg: 8 secondi

suppongo (conoscendomi) di aver scritto qualche vaccata nella funzione modificata, ma confrontando gli output il risultato sembra giusto.
Se qualcuno vuole dare una controllata batta un colpo che posto il 'removpkg' di prova (o la patch).

[Luci0]

posta la patch ... che provo a fare disastri ... !!
Se funziona forse si può agganciare Gnome-Slacky ...
Comunque con rsort non finisce lì ... ho intenzione di provare con un altro compilatore ... ho provato il gcc 3.4.6 della 11.0 e il 3.3.4 della 10.1 ... entrambe non compilano ...... credo che dovrò installare una 8.1 o una 9.0 per vedere l' effetto che fa ...