Belli miei, ecco il mio capolavoro. Il vecchio ckit con l’implementazione della getopts.
E’ anche cambiata qualcosa nel codice, ho migliorato un pò di cose ed eliminate altre, sempre la solita solfa di quando si fa un programma insomma.
Non mi dilungo in inutili spiegazioni: LINK.
Più che altro ho in previsione di implementare un controllo sugli argomenti in input. Per ora il programma avvia ogni task l’utente voglia, logicamente ci sono argomenti che non ha senso passare insieme. E’ logico poter avviare -BaiA (-B build, -a tira il tarball da AUR, -i installa e -A aggiungi al repo), però non avrebbe senso lanciare un check al termine di un build.
Per il resto limitatevi a dare uno sguardo all’help raggiungibile dal -h o senza argomenti.
Saluti.
Aggiunta roba, migliorata dell’altra ed ecco che una bidonata di ammasso di codice inutile forse inizia a diventare qualcosa di figo: LINK. Ammè mepiasce, lo tengo in uso per un altro pò vediamo come si comporta. Forse la prima versione ufficiale e stabile 1.0 è vicina.
amarok-svn has been replaced by amarok-git from now on.
Cheers.
In maniera molto rudimentale però si va avanti, ho abbozzato un primissimo controllo sul repo uppato. In breve semplicemente lo invio, lo riscarico quindi controllo la dimensione di ciò che avevo e ciò che ho ottenuto segnalando lo stato del db. In caso di esito negativo consiglio l’uso di un restoredb che ripristina il repo allo stato precedente. La cosa va comunque migliorata, per ora è solo un abbozzo.
lftp_put_repo(){
cp "$repo" "$repo"_prev
lftp_run "put $repo" &>/dev/null
wgetrepo
i=$(stat -c%s "$repo")
j=$(stat -c%s "$repo"_prev)
[[ $i = $j ]] && echo " -> Fatto, controllo dimensione ok ($i)." || echo " -> OCCHIO: $i ~ $j! Potresti aver bisogno di restoredb!"
}
Lo stavo facendo con md5sum ma ho avuto noie. LINK.
Serviva un modo per poter aggiornare i pacchetti ottenuti dal check, quindi ho scritto una seconda funzione per la compilazione: build1. LINK.
$ sh CKIT build1
==> CKIT - Construction KIT
==> Ok, azione scelta build1.
==> Processo i pacchetti ottenuti dal check.
==> tilda-cvs: vuoi aggiornare? (y/n) y
-> Vuoi prendere il PKGBUILD da AUR? (y/n) y
-> Ti basta compilare da user? (y/n) y
-> Ok, tilda-cvs fatto 
==> pidgin-facebookchat-svn: vuoi aggiornare? (y/n) n
==> pcmanfm-svn: vuoi aggiornare? (y/n) y
-> Vuoi prendere il PKGBUILD da AUR? (y/n) y
-> Ti basta compilare da user? (y/n) y
-> Ok, pcmanfm-svn fatto
==> minitube-git: vuoi aggiornare? (y/n) y
-> Vuoi prendere il PKGBUILD da AUR? (y/n) y
-> Ti basta compilare da user? (y/n) y
-> Spiacente, il pacco minitube-git non compila 
==> microdia-git: vuoi aggiornare? (y/n) n
==> gnome-do-bzr: vuoi aggiornare? (y/n) y
-> Vuoi prendere il PKGBUILD da AUR? (y/n) y
-> Ti basta compilare da user? (y/n) y
-> Ok, gnome-do-bzr fatto
==> aurget-git: vuoi aggiornare? (y/n) y
-> Vuoi prendere il PKGBUILD da AUR? (y/n) y
-> Ti basta compilare da user? (y/n) y
-> Ok, aurget-git fatto
==> amarok-svn: vuoi aggiornare? (y/n) n
Spendo due paroline per descrivere la funzione. Ho aggiunto nel check due righe che aggiornano un file di testo man mano che trovo pacchetti da aggiornare.
Quindi il build1 va a scansionare questo file, richiedendo di voce in voce se scaricare il PKGBUILD da AUR e se compilare da user o root, mantenendo sempre la filosofia principale del programma. Ho inoltre nascosto l’output del makepkg perchè non è l’operazione predominante, fermo restando che per un uso verboso c’è il “build pacco flag flag”.
Per concludere, le due funzioni di compilazione usano le stesse risorse e sono perfettamente compatibili, è possibile lavorare prima con un build1 generico e successivamente con un build specifico su un pacchetto che, ad esempio, prima non compilava causa dipendenze mancanti o PKGBUILD da sistemare, per poi concludere con un unico add. L’eventuale modifica del PKGBUILD dovrà essere fatta in separata sede ed a mano.
Il programma comunque non è ancora multitasking e dubito lo sarà mai, perchè la compilazione tende ad usare gia di suo l’intera potenza della cpu.
Per ora questo è quanto. Saluti.
Fatto 
LINK
Se sapete risolvere la parte della copia in home mi fate un fischio, c’ho messo dei grezzissimi “echo $blabla”, dove $blabla sono i comandi da dare come user.
If you know how to fix the issue of the copies to the user’s home, leave me feedback.
Stay tuned.
Ovviamente la funzioncina check può volere anche nuovi PKGBUILD, in caso di aggiornamenti, nuove dipendenze o dipendenze non più necessarie. Di default il programma CKIT è fatto per lavorare in locale, però qualcosina che tiri gli aggiornamenti da AUR si mostra utile. Ecco che viene update. LINK.
Forse siamo vicini alla seconda versione stabile di CKIT, ora mi resta solo usarlo e provarlo.
Edit: fixato check
Aggiunto il supporto al controllo delle versioni devel che non seguono AUR, e parametrizzato il codice per una facile prima configurazione. LINK
==> Controllo le versioni dei pacchetti e stampo solo quelli che vanno aggiornati.
--> amarok-svn REPO:991783-1 LOCAL:991783-1 AUR:959419-1 DEVEL:992202-1
--> amsn-svn REPO:11295-1 LOCAL:11295-1 AUR:11176-1 DEVEL:11309-1
--> aurget-git REPO:20090703-1 LOCAL:20090703-1 AUR:20090623-1 DEVEL:20090707-1
--> jabbim-svn REPO:4171-1 LOCAL:4171-1 AUR:4074-1 DEVEL:4172-1
--> minitube-git REPO:20090706-1 LOCAL:20090706-1 AUR:20090704-1 DEVEL:20090707-1
--> pcmanfm-svn REPO:876-1 LOCAL:876-1 AUR:826-1 DEVEL:877-1
--> tilda-cvs REPO:20090704-1 LOCAL:20090704-1 AUR:20080506-1 DEVEL:20090707-1
==> Fine esecuzione CKIT!
Ho sistemato meglio la funzione di controllo, appunto la check. Ora confronta direttamente la versione del repo e quella di AUR senza passare per la versione locale, anche poco utile. LINK
last comments