Cercherò di spiegare alla meglio l’utiità delle cartelle e dei log usati in ckit. Ammetto che è una pecca non aver fornito in alcun modo uno straccio di documentazione su queste cose quindi inizio dal semplice blog per poi elaborare meglio per un futuro wiki con la speranza che ci si riduca ai minimi termini sull’uso delle risorse.
Comincio dalle cartelle:
mkdir -p "$builddir" "$repodir" "$cachedir"
$builddir è il workspace vero e proprio, conterrà le cartelle con i PKGBUILD dei programmi ossia le loro $startdir, solo per i casi di pacchetti devel conterrà anche i sorgenti.
$repodir è una cartella di transito, ckit copierà i pacchetti man mano che compila, vedere post_build(). Questa cartella in più conterrà anche i log che probabilmente starebbero più comodi in una ~/.ckit, magari più in la sposteremo, per ora 0.58 stanno ancora qui dentro.
$cachedir è la cartella deposito, ad ogni add() ckit sposterà i pacchetti __$aggiunti__ al repo (dove per aggiunti intendo un livello di astrazione su repo-add ed upload con rimozione versione precedente). Questa cartella __NON__ verrà mai svuotata in automatico perché non si può prevedere quando un pacchetto si compila ma “non funziona”, in tal caso sarà disponibile al volo la cache ma si dovrà procedere a mano per copiare dentro $builddir ed inserire il pacchetto nel lista dei build fatti, di questa lista ne parlerò tra brevissimo. L’unico modo per svuotare questa cache sarà con ckit -H e SOLO quando lo sviluppatore ne riterrà opportuna l’azione.
Parliamo dei log, esistono 4 log, dei quali 2 fissi e 2 volatili. I due log volatili sono quelli più usati ossia il $buildlog e $checklog mentre i due log fissi sono $deletelog ed $updatelog.
$buildlog è valorizzato dalla build() in particolare post_build(), e contiene la lista dei pacchetti presenti nella $repodir quindi i pacchetti prossimi ad essere aggiunti. Se pensate che è ridondanza vi do ragione, è proprio così infatti c’è in progetto l’eliminazione ma per ora 0.58 esiste. La potenza di ckit è data anche da questo log, hai la possibilità di dare sempre makepkg a mano per cavoli tuoi, puoi farlo fare ad un amico te lo giri via rete o con penna un modo qualsiasi, l’importante è che lo copi in $repodir e __PER_ORA__ inserire il nome in $buildlog a mano in un posto qualsiasi purché a capo di una riga vuota e seguito da un Invio (credo carrage return e line feed nell’atto pratico) quindi dare ckit -A che man mano che __$aggiunge__ (n.b. sul significato di aggiungere spiegato poco sopra) sposterà i pacchetti nella cache e solo al termine eliminerà il log, che non servirà più evidentemente.
$checklog è valorizzato dalla check() e contiene i pacchetti ottenuti dalla funzione stessa, ossia i pacchetti che necessitano aggiornamento perché outdated. Non ci sarà differenza tra stabili e devel, non a livello di log certo, ma a livello di check(). Per come è progettato ckit la check() non terrà conto dei pacchetti devel che non sono presenti nel workspace, perché questo? Si tenga d’occhio che i pacchetti stabili hanno un riscontro immediato da AUR, e sebbene ciò può tecnicamente avvenire anche per i devel questo non è affidabile. Come risolve ckit? Bene, ad ogni check() lui esegue questo controllo:
if [[ "$develcheck" == "0" ]] && is_devel "$pkg" && [[ -d "$builddir/$pkg" ]]; then
dove il primo argomento indica l’espresso consenso dello sviluppatore nel voler processare i pacchetti devel, il secondo indica l’effettiva presenza della versione devel mentre il terzo indica l’effettiva presenza della cartella nel workspace. In questo modo si consente esplicito consenso nel seguire l’andamento della versione devel, quindi ckit provvederà a __capire__ lo stato del repository dei sorgenti con un makepkg a vuoto che sincronizzerà il repository remoto
makepkg -o 2>&1 | awk -v "pkg=$pkg" '$0 ~ pkg {print $6}'
Nel caso sia presente un ipotetico pacchetto “voluminoso” quale un xbmc-svn con ben 5 giga di sorgenti, lo sviluppatore potrà non seguirne l’andamento semplicemente non avendone la cartella, o eliminandola, in workspace. Lo sviluppatore potrà cominciare a seguire quel pacchetto semplicemente __$installando__ nel suo workspace la cartella con il PKGBUILD di quel pacchetto con ckit -U xbmc-svn. Con questa particolare speigazione sono uscito un pelo fuori traccia, ma penso sia stato utile per capire il fatto delle cartelle del workspace.
Passiamo ai due log fissi, questi log sono stati introdotti con lo scopo di colmare lacune di ckit. Ebbene si, ckit ha lacune, ma che non sono proprie dello script quanto dei pacchetti. Servono ad intridurre elasticità sui PKGBUILD, in realtà è più una falla dei PKGBUILD fatti male che limitano l’effettivo lavoro di building, quindi ckit prevede che ci possono essere PKGBUILD fatti coi piedi e si prepara a superare questa lacuna.
$deletelog contiene alcuni pacchetti inseriti __SOLO__ manualmente dallo sviluppatore che necessitano di essere svuotati dei sorgenti. Ad esempio, amule-devel è devel quindi ckit non gli segherà i sorgenti però ha un carattere stabile a snapshots notturni ed ogni archivio è standalone quindi è inutile conservare l’archivio dei sorgenti della release precedente. In tal caso lo si potrà scrivere nel $deletelog per poi dare ogni tanto a discrezione dello sviluppatore ckit -DL (o anche ckit -D amule-devel). Altro problema l’ho notato a suo tempo su gnome-do-bzr, il PKGBUILD fatto coi piedi non riusciva a superare alcune copie ed un modo efficace era rimuovere a mano alcune robe, detto a spiccioli bastava anche un makepkg -c ad ogni build() ma questo comportava inserire un paramertro delegando allo sviluppatore mentre un modo per farlo in automatico (o semi-automatico) era mediante $deletelog (o in alternativa sempre ckit -D foo-bar-baz). Ho subito notato una possibilità di far cooperare -D e -B ma di primo acchito ho notato conflitti nell’uso delle risorse, magari prossimamente si potrebbe risolvere.
$updatelog viene sempre e __SOLO__ scritto a mano dallo sviluppatore, e contiene i pacchetti che necessitano di un aggiornamento manuale da AUR. Questo viene in soccorso per colmare la lacuna dei PKGBUILD non proprio fatti male, ma che sono devel e conservano un carattere stabile, ad esempio xbmc-svn che nonostante sia devel viene aggiornato solo a commit che compilano saltando i commit intermedi. Altro esempio è su gnome-do-bzr che a mio parere è proprio un pacchetto fatto coi piedi e conserva tutte le lacune previste, sia per la sincronizzazione dei sorgenti che per la compilazione. Ma non ho intenzione di correggere PKGBUILD, ne tantomeno si richiede che vengano corretti. ckit accetta tutto volente o nolente semplicemente si adatta e amen, quindi in questi termini la check() verrebbe sempre lanciata con -ULCd o -ULC (n.b. i riferimenti ai PKGBUILD per lo meno di gnome-do-bzr sono relativi al periodo di quando ho iniziato a seguirne lo sviluppo, attualmente non so come procede se hanno migliorato o peggiorato non mi importa ho iniziato così ho notato irregolarità quindi frega niente, si va avanti così male non fa e questo non implica l’utilità dei log fissi se ce n’è / ce n’è stato almeno uno, ce ne possono essere altri quindi i log possono servire sempre).
Questo è quanto, vorrei solo concludere con una nota sull’ultima funzione aggiunta relativa alla manutenzione del workspace. Dopo un po di tempo, mesi o settimane, aggiungendo o droppando pacchetti si potrebbe raggiungere un certo livello di occupazione su disco del workspace. In tal caso nasce un problema, se do un bel rm -rf /foo/bar/baz/workspace poi mi tocca ricordarmi tutti i pacchetti devel che seguivo per averne le cartelle? La risposta ovviamente è si, ma ho introdotto proprio di recente una nuova interfaccia -S che chiama aurdevelsync(), che scorre la lista dei pacchetti saltando quelli stabili, di volta in volta verrà chiesto foo-devel: update? (y/n) quindi si potrà procedere alla __$installazione__ nel workspace per procedere con i successivi check().
Detto ciò, chiudo. Saluti.
brè