openSUSE:Tutorial su Build Service

Open Build Service

Utente finale - Packager - Sviluppo - Integrazione con KIWI - Installazioni - Collaborazione - Confronto

Questo documento dovrà fornire una panoramica del progetto Build Service e un tutorial su come creare pacchetti per le varie distribuzioni, usando questo eccellente strumento. Cercheremo di mostrare tutte le operazioni da eseguire su un esempio pratico, in modo tale che, per realizzare il proprio pacchetto, sia sufficiente seguire i passaggi.

Prerequisiti

Dovresti avere una conoscenza di base sugli RPM e su come vengono creati. Guarda le linee guida per creare i pacchetti per openSUSE o un documento affine su un altro sistema di pacchettizzazione supportato, come per esempio dpkg. Questo documento non intende sostituire la documentazione per la pacchettizzazione che può essere letta seguendo i collegamenti qui sopra.

Dovresti avere familiarità con l'ambiente del codice sorgente usato dal tuo progetto per generare i pacchetti. Il Build Service è in grado di rimediare ad alcuni errori ricorrenti e cercherà di farti da guida in caso di problemi e tentativi andati a vuoto. Disponiamo di una buildservice-mailinglist che può essere una buona fonte di aiuti e consigli. Comunque la scelta di quali patch applicare, di quali flag del compilatore attivare, etc., spetta in ultima istanza a te.

Requisiti

Per usare tutte le funzionalità del Build Service hai bisogno di fare il login con il tuo account openSUSE/SUSE (come con wiki, bugzilla...). Se ancora non disponi di un account, fai clic sul collegamento "sign up" in cima alla pagina per crearne uno. Tieni presente che, se un giorno tu cambiassi la password, ti sarà necessario modificare anche ~/.oscrc, se ometterai quest'ultimo passaggio ma ciò nonostante lancerai i comandi di osc che implicano di agire sul server, l'account utente potrebbe venir bloccato dopo ripetuti tentativi di accesso con una password sbagliata.

Inoltre, se hai avviato la creazione del pacchetto come utente normale (il che è una buona idea), ti verrà chiesta la password per l'amministratore (root) della tua macchina locale. Puoi evitare questo passaggio aggiungendo il tuo utente a /etc/sudoers con la seguente procedura:

Apri il file di configurazione relativo al tuo utente ~/.oscrc
Aggiungi a quel file la riga qui sotto e poi salvalo:
```
su-wrapper = sudo
```
Esegui il seguente comando:
sudo /usr/sbin/visudo
Aggiungi (o modifica) le righe seguenti alla configurazione di sudo, sostituendo il segnaposto LOGIN col tuo nome di login:
```
LOGIN    ALL = NOPASSWD: /usr/bin/build
LOGIN    ALL = NOPASSWD: /usr/bin/osc
```

Terminologia

Il Build Service è costituito di projects (progetti) (qui puoi vederne un elenco). Ciascun progetto (project) contiene le risorse necessarie per creare uno o più packages (pacchetti, cioè file RPM). Queste risorse includono gli archivi del sorgente, i file delle patch, i file spec, etc. Il risultato di un progetto sono uno o più repositories (i repository, in italiano). Il repository è un vecchio e ben assodato concetto: semplicemente un gruppo di RPM, organizzati in una struttura gerarchica di directory, assieme ad alcuni file di indici e meta-dati che permettono a strumenti utili come zypper di cercare e risolvere le dipendenze in tutta semplicità. I repository, frutto di un progetto, corrispondono alle differenti versioni del sistema operativo (come per esempio openSUSE 11.2, etc.).

Per quanto riguarda i progetti esistenti, sono attivi i progetti "official" (ufficiali) di openSUSE che creano gli RPM che sono forniti nelle distribuzioni standard di openSUSE . Il progetto "factory" è il progetto, continuamente soggetto ad attività di modifica, che diventerà la prossima versione di openSUSE. Esistono anche molti progetti specifici per una singola area, come per esempio Apache e network:telephony. Infine, ogni utente ha il suo progetto personale "playground", il nome del progetto segue lo schema home:username.

I file RPM tendono ad avere molte dipendenze da altri RPM, e spesso questi altri RPM provengono da progetti differenti all'interno del Build Service. Ciò ha due implicazioni importanti:

Primo, se un pacchetto dipende da qualche altro pacchetto al momento dell'esecuzione (voce "Requires"), spesso dipenderà da quegli altri anche nel momento della sua creazione e compilazione (cioè la voce "BuildRequires"). Il Build Service non va automaticamente alla ricerca per trovare le dipendenze al posto dell'utente (oltre a quanto è già incluso nella distribuzione standard per cui si sta compilando). Cosi talvolta dovrai indicare al Build Service dove reperire i pacchetti richiesti.

Secondariamente, un buon obiettivo per un repository è di risultare transitivamente chiuso, ovvero qualsiasi dipendenza di un qualunque pacchetto nel repository è essa stessa nel repository (ad eccezione dei pacchetti nella distribuzione standard). Questo facilita le cose per chi sta installando gli RPM forniti dal tuo progetto. Ma tutto questo non è obbligatorio: gli utenti possono sempre trovare queste dipendenze a mano, usando l'apposita interfaccia di ricerca.

Build Service fornisce alcune modalità operative diverse, al fine di facilitare la gestione di tali dipendenze.

Primo, puoi aggiungere direttamente i pacchetti richiesti (o il pacchetto) al tuo repository. Questo è l'approccio che devi sicuramente seguire se nessun altro progetto fornisce i pacchetti necessari. Di solito, tuttavia, quei pacchetti sono già stati creati da qualche altro progetto. Considera l'eventualità di riutilizzare il loro lavoro.

La seconda opzione è di creare un collegamento tra il repository dell'altro progetto e il tuo repository. Questa operazione è chiamata layering e viene fatta modificando i meta-dati del tuo progetto. Aggiungi l'altro project/repository come un percorso addizionale, questo si va semplicemente ad aggiungere all'elenco dei repository in cui il Build Service cercherà le dipendenze richieste per la compilazione del pacchetto (le dipendenze "BuildRequires") al momento della creazione di quest'ultimo. Questo consente ai pacchetti di essere creati con successo, risolvendo il primo problema, ma non considera affatto l'obiettivo della "chiusura transitiva": gli utenti dovranno recuperarsi da sé i pacchetti richiesti. In ogni caso, questa è una buona scelta qualora il tuo progetto presenti numerose dipendenze verso un altro progetto e, o anche solo, se è molto probabile che gli utenti avranno attivato e preleveranno da entrambi i repository, in ogni caso.

La terza possibilità si chiama linking ed è un modo che consente al tuo progetto di riutilizzare un pacchetto che è già presente in un altro progetto. Quando si crea un collegamento ad un pacchetto all'interno del proprio progetto, sarà possibile creare i pacchetti dipendenti da esso, e il pacchetto comparirà anche nel repository del proprio progetto, risolvendo così entrambi i problemi descritti sopra senza duplicare alcun lavoro.

Esistono due tipi di collegamento (linking): link (collega) e aggregate (aggrega). Quando si collega (ovvero si usa la modalità link), è possibile anche modificare il modo in cui viene creato il pacchetto. Si possono aggiungere patch e abilitare la compilazione per i repository aggiuntivi. Il build del file RPM del pacchetto avrà un numero di build diverso da quello del build del progetto originale per lo stesso pacchetto. Si noti che questo potrebbe generare confusione tra gli utenti, dato che, a tutti gli effetti, stai creando una versione diversa di un pacchetto con lo stesso nome.

Tranne il caso in cui sia necessario modificare il pacchetto richiesto, dovresti sempre aggregare, ricorrendo ad aggregate invece che collegare, con link. Quando si usa aggregate, si esegue la creazione di un collegamento "read-only". Il pacchetto non viene creato all'interno del tuo progetto, al contrario il pacchetto, già creato e pronto, viene copiato all'interno del tuo progetto dal suo progetto di origine. Così lo stesso RPM (con lo stesso build number) sarà presente in entrambi i progetti. Questo crea meno confusione dal lato utente, dato che i file RPM sono identici.

Il Build Service rileva automaticamente le modifiche apportate ai pacchetti collegati e fa sì che ogni pacchetto dipendente da quelli venga creato nuovamente.

Sequenza delle operazioni

I passi seguenti illustrano la normale sequenza delle operazioni per creare un progetto e aggiungervi dei pacchetti. Naturalmente in un caso pratico potresti trovarti bloccato in qualche passaggio e doverlo ripetere finché non restituisce più errori. Quanto riportato è solo uno schema per darti un'idea di quello che ci apprestiamo a realizzare.

Ti saranno mostrati due modi diversi di procedere, ove possibile:

la modalità con il Client web
la modalità con il Client da riga di comando
Un metodo alternativo è la modalità con il client MonoOSC, un tutorial è già disponibile qui, quindi non è necessario duplicare i contenuti.

Passo Uno - Login e configurazione una tantum del Local Project

Questo è il passaggio più facile, se già disponi di un Account openSUSE.

Client web: Apri http://build.opensuse.org/ e usa il collegamento al login in alto a destra per accedere al tuo account. Dopo di ché la tua home project è disponibile cliccando sul tuo nome utente.

Riga di comando:

Devi dapprima installare il Client per la riga di comando sulla tua macchina. Puoi trovare i pacchetti di osc per varie distribuzioni nel repository di download software openSUSE-Tools (è anch'esso un Build Service Project). Usa il tuo gestore di pacchetti preferito per installare il pacchetto osc.

Successivamente fai "cd" nella directory che vuoi usare per i file del tuo progetto. A questo punto chiunque pratico di SVN si sentirà "a casa": esegui il checkout della tua home project usando

 cd <directory_contenente_il_project_root>
 osc checkout home:<username>
 cd home:<username>

(sostituisci <username> con quello del tuo login). Ti verranno richiesti i tuoi username e password — dopo di ché osc cercherà di fare il checkout dei pacchetti nella tua home project e creerà una nuova directory chiamata home:<username>. Puoi modificare le impostazioni nel file ~/.oscrc.

Passo Due - Creare e scaricare i pacchetti

Puoi usare la tua home project come "campo prove" per testare i pacchetti che verranno trasferiti ad altri, più visibili, progetti, se tutto andrà bene.

Client web: Fai clic sul tuo nome utente per aprire la tua home project, fai poi clic su "create new package" (crea un nuovo pacchetto) nella scheda dei pacchetti (packages). Dovresti completare i seguenti tre campi testuali: "Name" (obbligatorio) (Nome), "Title" (Titolo) e "Description" (Descrizione). Semplicemente usa il nome del pacchetto per il campo "Name", il riepilogo del pacchetto come "Title" e la descrizione del pacchetto come "Description".

Dopo aver creato il pacchetto, vai alla scheda "Sources" (sorgenti) per aggiungere i file per il tuo pacchetto. Sarà necessario caricare il codice sorgente del tuo pacchetto ed almeno un file spec (vedi anche openSUSE:Linee guida per la creazione dei pacchetti).

Riga di comando:

osc meta pkg -e home:<username> <packagename>

osc aprirà un file template in xml nel tuo editor preferito (in base alla variabile d'ambiente EDITOR) e ti sarà possibile aggiungere semplicemente gli stessi dati (nome, titolo e descrizione. Ovvero Name, Title e Description), come descritto sopra.

Richiama ora il comando

osc up home:<nomeutente>

e otterrai una nuova directory con il nome del tuo nuovo pacchetto. Per aggiungere i file tramite la riga di comando, fai semplicemente 'cd' nella nuova cartella e copia i file rilevanti (solitamente un archivio tar.gz e i file di supporto).

Per i pacchetti RPM di openSUSE le istruzioni per la loro compilazione sono contenute nel file spec. Per una guida su come creare questo file, si vedano le linea guida per la creazione dei pacchetti. Un approccio più facile consiste nel copiare e adattare un file spec preso da un pacchetto simile, o direttamente dal tar-ball dei sorgenti, se è presente nell'archivio. Quando i file saranno pronti potrai richiamare il comando

osc add *

questo segnerà i file nella directory per il successivo invio. Per inviare i file e applicare le modifiche, usa

osc commit

Il commit darà automaticamente inizio al processo di creazione del pacchetto. È possibile che tu voglia ritardare il commit fino al momento successivo a quello un cui avrai compilato con successo il pacchetto in locale, vedi sotto.

Passo Tre - Scegliere i target della creazione pacchetti

A questo punto dovrai selezionare le distribuzioni (p.es. openSUSE 11.3, Ubuntu 10.04, etc.) per le quali desideri che vengano creati i pacchetti.

Client web: Vai alla scheda "Repositories" relativa al tuo progetto, fai clic su add repositories e scegline una tra le distribuzioni e architetture disponibili.

Riga di comando: ottieni dapprima l'elenco dei repository disponibili

osc ls

modifica quindi i metadati del tuo progetto:

osc meta prj -e home:<username>

e aggiungi il repository in questo modo:

 <repository name="openSUSE_Factory">
   <path project="openSUSE:Factory" repository="standard" />
   <arch>x86_64</arch>
   <arch>i586</arch>
 </repository>

in cui project può essere openSUSE:Factory, openSUSE:11.3, SUSE:SLE-11:SP1 e così via. La voce repository="standard" è solo per estensioni future (i fork di un repository).

Passo Quattro: Creare il pacchetto

Il pacchetto viene incluso nell'elenco dei pacchetti da creare automaticamente dopo che ne è stato fatto il commit o dopo che è stato modificato qualche file. Se un pacchetto richiesto viene ricostruito, anche il tuo pacchetto verrà automaticamente ricostruito.

Puoi anche avviare una ricostruzione del pacchetto manualmente, se necessario:

osc rebuildpac <project> <package> [<repo> [<arch>]]

Con gli argomenti opzionali <repo> e <arch>, si può limitare la ricostruzione ad alcuni repository o architetture.

Supponendo che il nome del tuo progetto sia home:username, puoi trovare il tuo progetto all'indirizzo http://download.opensuse.org/repositories/home:/username/

Creare il proprio pacchetto in locale

Talvolta potrebbe essere più veloce creare il proprio pacchetto sulla propria macchina locale invece di attendere i risultati dal Build Service. osc supporta la creazione locale dei tuoi pacchetti, se l'architettura locale del tuo hardware la supporta (su x86_64 puoi compilare per i586 e x86_64, su i586 solo per i586).

Controllare di avere gli ultimi sorgenti disponibili

Utilizza osc checkout (osc co) or osc up per assicurarti di avere l'ultima versione dei sorgenti.

Se il progetto (project) già esiste in locale non si deve usare checkout:

cd <tua_obs_working_dir>;
osc co <project> <package>

oppure

cd <tua_obs_working_dir>/<project>;
osc co <package>

oppure

cd <tua_obs_working_dir>/<project>/<package>;
osc up

Eseguire la build locale

 osc build <platform> <arch> <specfile> [--clean|--noinit]

per esempio

~/obs/home:user/project # osc build openSUSE_11.4 x86_64 project.spec

osc si connetterà al server del repository OBS e scaricherà tutti gli RPM necessari in /var/tmp/osbuild-packagecache/piattaforma/repository/architettura, usandola come directory cache. Se si vuole evitare traffico di rete è possibile riempire preventivamente la cache con gli rpm da un DVD o immagine iso. A questo scopo, dovrai copiare gli rpm dal DVD alla directory cache.

Per esempio, per il repository openSUSE_12.1 puoi usare l'immagine iso del DVD, come mostrato qui sotto:

 mount openSUSE-12.1.iso /mnt/ -o loop
 mkdir -p /var/tmp/osbuild-packagecache/openSUSE\:12.1/standard
 cp -r /mnt/suse/* /var/tmp/osbuild-packagecache/openSUSE:12.1/standard

Aggiusta ora i permessi, dato che il DVD non è accessibile in scrittura, ma osc avrà bisogno di scrivere dati nella cache:

 find /var/tmp/osbuild-packagecache/openSUSE:12.1 -type d -exec chmod 755 {} \+
 find /var/tmp/osbuild-packagecache/openSUSE:12.1 -type f -exec chmod 644 {} \+

Si possono ora creare i pacchetti localmente, in questo modo:

 osc build openSUSE_12.1 i586 <nome-di-un-pacchetto>.spec

osc creerà un ambiente di chroot in /var/tmp/osc-build-root/ e avvierà la creazione del tuo pacchetto. Se hai apportato soltanto delle modifiche minori puoi evitare di creare nuovamente il build environment con l'opzione --noinit. Se sospetti che l'ambiente di chroot sia danneggiato puoi dare il via ad una ricostruzione completa (rebuild) con l'opzione --clean. Hai la possibilità di configurare la directory del chroot: vedi i commenti nel file ~/.oscrc.

osc si rifiuterà di installare i pacchetti dai progetti che il tuo sistema non considera fidati. Questo può succedere quando per il tuo pacchetto è stato creato un collegamento ad un progetto di sviluppo (development project) e il tuo sistema non è configurato per usare quel repository. Puoi aggiungere la chiave GPG necessaria eseguendo il comando:

sudo rpm --import - <<_END_KEY
$(osc signkey progetto-problematico)
_END_KEY

Dopo che i pacchetti sono stati creati nel precedente ambiente di chroot, troverai i pacchetti risultanti in /var/tmp/build-root/home/abuild/rpmbuild/RPMS/ (le vecchie versioni di rpmbuild usano /usr/src/packages/RPMS/).

Se il tuo pacchetto usa un servizio di scaricamento via indirizzo web (URL), è probabile che dovrai prima eseguire il seguente comando:

zypper ar -r http://download.opensuse.org/repositories/openSUSE:/Tools/openSUSE_11.3/openSUSE:Tools.repo

Il file di registro completo del tuo build locale è conservato in /var/tmp/build-root/.build.log.

Correzione Errori durante il Processo di Creazione pacchetti

Il motivo principale per cui potresti aver bisogno di compilare un nuovo pacchetto per openSUSE, o qualsiasi altra distribuzione, è per affermarne la compatibilità nel caso in cui il tuo pacchetto non sia stato ancora compilato per la versione, e rilascio, del tuo sistema operativo. Comunque, in questo modo, potresti imbatterti in nuovi errori nel corso del processo di creazione, che hanno bisogno di essere corretti. Il modo più facile di correggere degli errori è di fare chroot nell'ambiente di build e creare ed applicare là le correzioni. Potresti voler utilizzare openroot, al posto di chroot, al fine di avere accesso a X11 e a tutte le altre directory necessarie, già montate.

 osc chroot openSUSE_12.1 x86_64

oppure con lo scomodo e antiquato

 chroot /var/tmp/build-root/
 cd /home/abuild/rpmbuild/BUILD/dir-tuo-pacchetto
 ls
 oppure:
 openroot /var/tmp/build-root/ 'cd /home/abuild/rpmbuild/ILD/dir-tuo-pacchetto; ls; bash'
 ...
 exit

Dipendenze

Se durante la creazione del tuo pacchetti dovessi ricevere un errore di dipendenza, aggiungi una linea con le dipendenze per il build, come in questo esempio:

BuildRequires: cmake libkde4-devel

In questo caso, prima che il tuo pacchetto venga creato, saranno installati cmake e libkde4-devel.

Installare pacchetti extra nel build root

Per finalità di debug, potrebbe rendersi necessario installare dei pacchetti extra nella tua build root locale, per problemi legati al debug e alla correzione del processo di creazione del pacchetto. Questo si può fare con la modifica del file ~/.oscrc e la variabile extra-pkgs. Per esempio:

extra-pkgs = vim gdb strace valgrind

Privilegi per installare

Se ricevi un messaggio d'errore simile a questo:

error: Bad exit status from /var/tmp/rpm-tmp.qrRAn2 (%install)

significa che il tuo passo di %install non è andato a buon fine (ma tutti gli altri prima sono andati bene). Questo può essere dovuto alla mancanza dei privilegi di scrittura, se hai cercato di installare nel posto sbagliato. In questo caso aggiungi il seguente comando di make install al tuo file spec:

make install DESTDIR=%buildroot

submit del tuo lavoro su OBS

Una volta che hai modificato il contenuto della directory <package> in base ai tuoi desideri, usa i comandi qui sotto per fare il submit del tuo lavoro su OBS.

aggiungere un nuovo file al pacchetto

osc add

rimuovere un file dal pacchetto

osc rm

aggiornare il log delle modifiche (cioè i *.changes)

osc vc

submit dei tuoi file aggiornati in OBS

osc commit

Patch

Se intendi creare la patch ad un file, copia quest'ultimo in un file .orig prima di modificarlo, riprova il passo desiderato nel processo di creazione del pacchetto fin quando termina con successo e poi crea una patch per esso. Per avere maggiori informazioni durante il processo di creazione, potrebbe esserti utile inserire la stringa "set -x" nel tuo specfile facendo sì che bash riporti tutti i comandi eseguiti (set +x disabiliterà successivamente la ripetizione).

diff -Pdpru /var/tmp/build-root/home/abuild/rpmbuild/BUILD/dir-tuo-pacchetto/Makefile.orig \

           /var/tmp/build-root/home/abuild/rpmbuild/BUILD/dir-tuo-pacchetto/Makefile \
           >/osc/home:user/dir-tuo-pacchetto/my.patch

Aggiungi ora la patch al file .spec aggiungendo all'elenco "Patch67: my.patch" nell'intestazione (o header) e poi provvedi che venga applicata durante il processo di creazione del pacchetto, inserendola nella sezione appropriata (di solito %setup), mediante la stringa "%patch67 -p7" (-p7 rimuove 7 livelli di directory, se non hai modificato manualmente il percorso dei file nell'intestazione (l'header) del file patch.).

Qualcuno potrebbe trovare più facile usare un programma speciale per la generazione automatica delle patch, come quilt:

osc co yourproject/yourpackage cd yourproject/yourpackage quilt setup -v *spec cd yourpackage-*/ quilt push -a # applica le vecchie patch quilt new yourpackage-version_fixbuild.patch quilt edit src/foo.c quilt refresh

Verrà automaticamente creato il file foo-fixbuild.patch nella directory genitore. Se si lavora su un pacchetto che non ha ancora ricevuto patch bisongo ricordarsi di copiare la patch dalla direcotory della patch alla directory del pacchetto. Eseguire di nuovo quilt setup per ottenere una patch iniziale. Per rimuovere patch dalla propria copia personale quando risulta funzionante, si può usare quilt pop.

Ecco un file .quiltrc modello:

# Opzioni passate a GNU diff mentre si generano le patch
QUILT_DIFF_OPTS="--show-c-function" 
# QUILT_DIFF_OPTS="" 
# Options passed to GNU patch when applying patches
#QUILT_PATCH_OPTS="--ignore-whitespace --unified-reject" 

# Opzioni da passare ai comandi (QUILT_${COMMAND}_ARGS)
QUILT_PUSH_ARGS="--color=auto" 
QUILT_DIFF_ARGS="--color=auto" 
QUILT_REFRESH_ARGS="--backup -p0"
QUILT_PATCH_OPTS="--unified-reject-files --backup"

Passo Cinque: Controlla i file di registro

Il buildservice produce un solo grande file di registro per ciascun processo di creazione (build) di un pacchetto.

Client web: E' sufficiente fare clic sul collegamento [Build Log] nella pagina di visualizzazione del pacchetto.

Riga di comando: Sono disponibili alcune scelte possibili in base alle proprie esigenze (packagedir è facoltativo se ti trovi nella directory del pacchetto):

osc prjresults [<project>]

Visualizza i risultati aggregati di creazione, per un intero progetto. O puoi impartire:

osc results [<project> <package>]

Visualizza i risultati di creazione di un singolo pacchetto.

osc buildlog <platform> <arch>

Visualizza il file log generato per un pacchetto (devi essere all'interno della directory del pacchetto).

Creare i Pattern

I Pattern sono file che contengono un elenco di pacchetti, assieme alla descrizione di quello per cui sono usati. In aggiunta il Build Service crea dei file .ymp per ogni pattern generato per un dato repository. Questi file .ymp possono essere usati dagli utenti per una Installazione One Click.

In breve, i pattern sono utili per installare un insieme di programmi, per un certo scopo, senza creare dipendenze tra i pacchetti.

Per creare e rendere disponibili dei pattern (Submit) si possono usare o l'interfaccia api, o osc:

per aprire un pattern in $EDITOR (creandolo se ancora non esiste)

osc meta pattern -e <project> <pattern>

per avere un elenco dei pattern esistenti

osc meta pattern <project>

ottenere un pattern esistente

osc meta pattern <project> <pattern>

Puoi anche distribuire e rendere disponibile (submit) un file esistente, come per esempio qui sotto:

osc meta pattern --file <local_file> <project> <pattern>

Per provare: facendo clic sul file .ymp in konqueror dovrebbe avviare l'applicazione di installazione, se konqueror non è installato puoi provare ad eseguire da shell come utente normale:

/sbin/yast2 MetaPackageHandler http://download.opensuse.org/repositories/<project>/<SUSE_Factory o openSUSE_10.2>/<pattern>.ymp

Il file seguente è un esempio di pattern preso dal progetto KDE:KDE4. Puoi vedere il file .ymp, generato da quello, qui.

<pattern
 xmlns="http://novell.com/package/metadata/suse/pattern"
 xmlns:rpm="http://linux.duke.edu/metadata/rpm"
>
    <name>KDE 4 Games</name>
    <summary>KDE 4 Games</summary>
    <description>A number of games for KDE 4.</description>
    <uservisible/>
    <category lang="en">Desktop Functions</category>
    <rpm:recommends>
      <rpm:entry name="kde4-kpat"/>
      <rpm:entry name="kde4-kmahjongg"/>
      <rpm:entry name="kde4-kmines"/>
      <rpm:entry name="kde4-kreversi"/>
      <rpm:entry name="kde4-ksudoku"/>
    </rpm:recommends>
    <rpm:suggests>
      <rpm:entry name="kde4-katomic"/>
      <rpm:entry name="kde4-kbattleship"/>
      <rpm:entry name="kde4-ksquares"/>
      <rpm:entry name="kde4-bovo"/>
      <rpm:entry name="kde4-kiriki"/>
      <rpm:entry name="kde4-kwin4"/>
      <rpm:entry name="kde4-kolf"/>
      <rpm:entry name="kde4-klines"/>
      <rpm:entry name="kde4-ksame"/>
      <rpm:entry name="kde4-lskat"/>
      <rpm:entry name="kde4-kgoldrunner"/>
      <rpm:entry name="kde4-kblackbox"/>
      <rpm:entry name="kde4-kbounce"/>
      <rpm:entry name="kde4-ktuberling"/>
      <rpm:entry name="kde4-knetwalk"/>
      <rpm:entry name="kde4-kjumpingcube"/>
      <rpm:entry name="kde4-kspaceduel"/>
      <rpm:entry name="kde4-konquest"/>
      <rpm:entry name="kde4-kshisen"/>
    </rpm:suggests>
</pattern>

Descrizione di alcuni tag:

Tag	Descrizione
<rpm:requires> <rpm:entry name="example" /> </rpm:requires>	Requires RPM example: questo pacchetto deve essere installato - altrimenti le richieste del pattern non sono soddisfatte.
<rpm:recommends> <rpm:entry name="example" /> </rpm:recommends>	Recommends RPM example: se è disponibile e se tutte le dipendenze di questo pacchetto sono soddisfatte, il pacchetto verrà installato. Se il pacchetto non è disponibile non ci saranno messaggi d'errore. Se le dipendenze del pacchetto non sono soddisfatte il pacchetto sarà visibile ma non installato.
<rpm:suggests> <rpm:entry name="example" /> </rpm:suggests>	Suggests RPM example: verrà mostrato nel pattern, ma non installato per impostazione predefinita.

Esempio completo di una semplice modifica

Esistono almeno altre due pagine wiki in cui è descritta la sequenza delle operazioni di branch, correzione (o fix) e submit di una patch:

L'obiettivo di quanto proposto qui di seguito è di fornire un particolare esempio che possa valere come guida pratica.

DRAFT BELOW, not yet finished or tested

Attenzione! Questa sezione è un abbozzo -non ancora testato-, che riporto dall'articolo in inglese nel caso qualche utente fosse interessato

Un'operazione frequente consiste nel creare un nuovo ramo (branch) di un progetto esistente, applicare una modifica e poi trasferire la modifica al pacchetto originale (submit).

I passaggi fondamentali sono:

Creazione di un nuovo ramo (branch) dal progetto originale del pacchetto originale:
osc branch <progetto_originale> <pacchetto_originale>
. Questo comando crea un nuovo progetto branch, destinato esclusivamente al particolare utente, a cui è assegnato il nome home:<tuo_nome_utente>:branches:<nome_progetto_originale> all'interno del quale crea un nuovo pacchetto con lo stesso nome del pacchetto originale e che risulta sostanzialmente una copia del pacchetto originale.
Checkout del pacchetto nel nuovo ramo privato:
osc checkout home:<tuo_nome_utente>:branches:<nome_progetto_originale>/<nome_pacchetto_originale>
Con questo comando i file sorgenti dal pacchetto branched verranno prelevati dal server e scaricati nella sotto-directory locale chiamata home:<tuo_nome_utente>:branches:<nome_progetto_originale>/<nome_pacchetto_originale>
Spostati in quella sotto-directory locale:
cd home:<tuo_nome_utente>:branches:<nome_progetto_originale>/<nome_pacchetto_originale>
e imposta la solita umask di default con umask 0022
Lavora sulla tua copia locale del pacchetto finché non funziona come vorresti:
1. Modifica i file sorgente locali (p.es. modifica il file spec o crea una patch)
2. Crea una copia locale (o build locale) del pacchetto
3. Esegui l'installazione locale del pacchetto
4. Prova il pacchetto installato localmente (test di funzionamento software, etc.)
Aggiorna i file modificati:
osc vc
Questo comando apre un editor (di solito 'vi') e crea l'intestazione appropriata per una nuova voce nelle modifiche del pacchetto RPM. Se era presente una segnalazione bug, questa deve essere citata come bnc#123456
Se hai aggiunto file nuovi (p.es. nuove pathc) o rimosso dei file (p.es. patch obsolete), aggiorna la situazione del controllo di versione per i file sorgente locali:
osc addremove
e verifica con osc status che non ci siano file che si trovino in una situazione problematica relativamente al controllo di versione, come '?' o '!'
Effettua la revisione (o commit) dei file sorgente locali nel pacchetto nel tuo branch:
osc commit
Questo comando causa l'upload dei file sorgente locali nel pacchetto del tuo ramo sul server e poi attiva una nuova build automatica del pacchetto nel branch.
Verifica (review) dei risultati del build del pacchetto nel branch personale per tutti i repository del build che erano abilitati per il pacchetto originale:
osc results --verbose home:<tuo_nome_utente>:branches:<nome_progetto_originale> <nome_pacchetto_originale>
Per un elenco dei repository del build che risultano abilitati per il pacchetto originale, visualizza i risultati di build del pacchetto:
osc results <nome_progetto_originale> <nome_pacchetto_originale>
Se il ri-build del pacchetto nel tuo branch termina con successo ("succeeded") per tutti i repository di build che sono abilitati per il pacchetto originale, crea una richiesta di submit per aggiornare con il pacchetto nel branch personale il pacchetto originale:
osc submitrequest --message='<un breve messaggio che descriva le modifiche da te introdotte accompagnato da bnc#123456, nel caso un cui esista una corrispondente segnalazione bug>' home:<tuo_nome_utente>:branches:<nome_progetto_originale> <nome_pacchetto_originale> <nome_progetto_originale> <nome_pacchetto_originale>
e annotati il codice di identificazione della richiesta (request ID number).
Controlla di tanto in tanto lo stato di avanzamento della tua richiesta:
osc request show <request_ID_number>
Se hai bisogno di metterti direttamente in contatto con i maintainer del pacchetto originale "osc maintainer <nome_progetto_originale> <nome_pacchetto_originale>" visualizzerà i loro nomi utente e "osc whois <nome_utente>" mostrerà il loro nome completo assieme all'indirizzo email associato all'utente del buildservice.

Si tratta di un certo numero di passaggi, che diventano però una seconda natura dopo un po' di pratica.

Condizione necessaria è che si disponga già di un account su OBS. In caso contrario procedi ad impostarlo alla pagina http://build.opensuse.org/ e usa il collegamento al login in alto a destra per accedere. OBS utilizza lo stesso sistema di autenticazione del resto dell'infrastruttura di openSUSE, ad esempio bugzilla, per cui molto probabilmente avrai già pronto un account, ti basterà eseguire il login per la prima volta e verrà automaticamente creata la home del progetto per l'account su OBS.

Ecco un esempio reale:

Impostazione iniziale da riga di comando (da farsi solo una volta)

sudo zypper in osc
mkdir ~/obs

Devi ora fare il branch su una copia locale del pacchetto preso come esempio.

cd ~/obs
umask 0022
osc branch security sleuthkit
osc co home:<tuo_nome_utente>:branches:security/sleuthkit
cd ~/obs/home:<tuo_nome_utente>:branches:security/sleuthkit

Ora che hai effettivamente il pacchetto a disposizione, il tutto si risolve in:

espandi il tarball ed esegui alcune operazioni preparatorie:
quilt setup sleuthkit.spec
passa alla directory dei sorgenti
cd sleuthkit-3.2.3
applica tutte le patch:
quilt push -a
aggiungi una nuova patch:
quilt new testing.patch
aggiungi un file alla patch:
quilt add nome-file

vi <nome-file>
o in alternativa::
quilt edit <nome-file>
e infine:
quilt refresh -p1
copia la patch su di un livello nella directory del progetto:
cp patches/testing.patch ..
e ora devi lavorare sul file spec:
cd ..

vi sleuthkit.spec
Aggiungi la tua patch al file spec creando una voce Patch0 nella parte dell'intestazione a una riga con %patch0 -p1 nella sezione %prep
informa OBS che il pacchetto contiene ora un nuovo file:
osc add testing.patch
aggiorna il file delle modifiche:
osc vc -m "Fix some typos."
e fai il build del tuo lavoro, installalo e testalo:
osc build
esegui un'installazione locale. In fondo all'output di osc build dovrebbe essere riportato il percorso completo del file RPM:
zypper in -f <percorso_completo_a_rpm>
ripeti a piacere. Torna a quilt edit se non sei soddisfatto.
invia le tue modifiche indietro a OBS:
osc commit
attendi un po' di tempo affinché i nuovi pacchetti vengano creati su OBS
verifica lo stato attuale del build per il pacchetto nel ramo di cui sei proprietario, attraverso l'interfaccia web (WebUI)
Una volta che il file RPM è pubblicamente disponibile, installalo da OBS e testalo di nuovo
invia le tue modifiche al pacchetto originale per il submit. Se nel database di bugzilla ci fosse una segnalazione al riguardo, assicurati di citarla assieme al submit

Vedere anche