I Sorgenti vanno inseriti nella direcotory SOURCES IL FILE .SPEC Innanzitutto le informazioni relative al file sono trobvabili a questi indirizzi: http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/ch-specfiles.html http://www.rpm.org/max-rpm/s1-rpm-build-creating-spec-file.html Lo spec file costituisce il punto focale per la creazione di un rpm, in esso sono riportate tutte le direttive che un file rpm deve posssedere per essere sia funzionale al sistema che conforme alle direttive fedora, è questo file che dice come un rpm deve essere compilato.. Il file spec deve essere innanzitutto redatto secondo una sintassi ben definita ed è costituito da 8 sezione: I commenti esplicativi, che non devono entrare nel processo di compilazione ma solo commentare i passaggi all'interno del file, si inseriscono con un # davanti. In testa allo spec file ci sono tree linee ciascuna inizianti con un cancelletto. Questi sono commenti che possono essere considerati generali per tutto il pacchetto e che contiene una ulteriore descrizione generale per rendere più comprensibile ciò che si fa. TIP: visto che tutte le sezioni comandi partono con un simbolo di percentuale, se il compilatore trova anche nei commenti il simbolo percentuale con la sezione ad esempio %prep, mi ritorna un errore, per evitarlo basta mettere un altro simbolo % davanti, così %%prep nel commento stesso. Il file .spec deve essere inserito, nella gerarchia di filesystem della buildroot all'interno della directory SPECS. Non esiste un ordine per l'inserimento delle direttive. Il Preambolo Il preambolo dovrà contenere tutte quelle informazioni che rispondono alle query di informazioni sul pacchetto e dovrà contenere: - la descrizione del pacchetto contente le macro e la descrizione del pacchetto stesso, praticamente il nome, la versione e la release. Si dovrebbe anche inserire una descrizione più lunga e ovviamente i termini legali. Si devono anche inserire le definizioni dei sorgenti, delle patch e, volendo, anche una icona per l'interfaccia grafica (se trattasi di pacchetto per un DM). esempio: # # Example spec file for cdplayer app... # Summary: A CD player app that rocks! Name: cdplayer Version: 1.0 Release: 1 Copyright: GPL Group: Applications/Sound Source: ftp://ftp.gnomovision.com/pub/cdplayer/cdplayer-1.0.tgz URL: http://www.gnomovision.com/cdplayer/cdplayer.html Distribution: WSS Linux Vendor: White Socks Software, Inc. Packager: Santa Claus %description It slices! It dices! It's a CD player app that can't be beat. By using the resonant frequency of the CD itself, it is able to simulate 20X oversampling. This leads to sound quality that cannot be equaled with more mundane software... Name Il nome definisce come sarà chiamato il pacchetto, meglio usare il nome del sofware, il suo nome sarà incluso nell'etichetta e nel filename. Questa è la parte più importante della descrizione del pckage, la NVR (Name-Version-Release) perchè è quello che consente di comparare le versioni Non dovrà contenere spazi e questo verrà passato nel confronto tra nomi nei programmi. Name: myapp-bella Prefix: /usr Provides: jikes Version Ovviamente occorre inserire in questa linea la versione del software che verrà inclusa nel nome pacchetto e nell'etichetta. Anche in questo caso occorrebbe usare una punteggiatura differente dal trattino (-) usato per il nome, e in genere si applicano i puntini (.) e non devono esserre usati spazi, questo verrà comparato nel confronto tra versioni. Version: 1.1.2 Release La release equivale al numero di volte in cui il software è stato pacchettizzato, che farà parte dell'etichetta del pacchetto e del nome del file. Si può utilizzare questo numero per conteggiare le volte in cui il file spec è stato modificaro. Anch'esso niene specificato nel nome file o pacchetto. Release: 1 License La direttiva licenza è usata per le informazioni di licenza, che per Fedora devono rispettare quanto riportato in (guidelines licenses),la direttiva copyright è deprecata. Group: Questa direttiva permette di inserire il proprio pacchetto all'interno di gruppi di pacchetti in base alla destinazione d'uso, i gruppi disponibili sono elencati in /usr/share/doc/rpm-4.1/GROUPS Devono essere separate da dallo slash. ad esempio Group: System Environment/Shells Source Il compito principale di questa direttiva si divide in due, fornire le informazioni su dove è contenuto il sorgente edare il nome che si può trovare nella directory SOURCE, normalmente si usa inserire in questa direttiva un URL. Questo permette a rpm di avere il nome del sorgente in quanto rpm ignora tutto quanto non è un nome di sorgente, per cui anche scrivendo quel che si vuole nel corpo del testo, viene processato il solo nome del sorgente URL A differenza dell'url indicato nella sesione source, qui viene indicata la url per la documentazione del pacchetto. Distribution Per che distribuzione è progettato il package. Volendo si può omettere Vendor: Il nome della compagnia che crea il pacchetto. Vendor: The Really Cool Company Icon: definisce il nome dell'icona assegnata al pacchetto, deve essere XPM o GIF (.xpm o . gif). Deve essere inserita nella direcotry SOURCES Packager Il packager identifica chi si è occupato della pacchettizzazione che può essere differente dal vendor, si può inserire anche una email per il contatto e la compagnia in cui lavora. Summary La direttiva summary non è altro che una breve desrizione che deve stare su una riga (non più di 50 caratteri). Description La direttiva summary inizia con un segno di percentuale e, a differenza del sommario sta su più di una riga Questa direttiva ci permette di descrivere molto partilarmente il nostro software. Occorre prestare prò particolare attenzione alla formattazione, i salti di interlinea sono visti come paragrafi diversi e non si deve cominciare la descrizione con spazi bianchi. Specifying the Platform Architecture IL file spec può anche definire a quale arcitettura o quale s.o. può essere riferito Excludearch: significa che non è per le architetture ivi inserite (indicare separate da spazi o virgole) Exclusivearch: significa che è stato per le architetture specificate (separati da spazi o virgoli) ExclusiveArch: i386 ia64 alpha The Excludeos: esclude un sistema operativo Exclusiveos: fatto per un sistema operativo specificato Excludeos: windows Exclusiveos: linux Con il preambolo abbiamo fornito parecchie info per le query di info e ricerca, quel che veramente interessa alla costruzione meccanica del package sono il nome, la versione, la release ed i sorgenti Patch(#) In questa sezione devono anche essere elencate le patch (argomento trattato più avanti) che poi vengono inserite per la preparazione nella sezione %prep Patch1: eject-2.1.1-verbose.patch Patch2: eject-timeout.patch BuildRequires Anche l'elenco dei programmi richieste per la build in formato query rpm (senza cioè versione ed estensione) uno per linea. BuildRequires: gettext BuildRequires: libtool %description The eject program allows the user to eject removable media (typically CD-ROMs, floppy disks or Iomega Jaz or Zip disks) using software control. Eject can also control some multi-disk CD changers and even some devices' auto-eject features. Install eject if you'd like to eject removable media using software control. %prep %setup -q -n %{name} %patch1 -p1 %patch2 -p1 %patch3 -p1 %patch4 -p1 %patch5 -p1 %patch6 -p1 %build %configure make %{?_smp_mflags} %install make DESTDIR=%{buildroot} install install -m 755 -d %{buildroot}/%{_sbindir} ln -s ../bin/eject %{buildroot}/%{_sbindir} %find_lang %{name} %files -f %{name}.lang %doc README TODO COPYING ChangeLog %{_bindir}/* %{_sbindir}/* %{_mandir}/man1/* %changelog * Tue Feb 08 2011 Fedora Release Engineering - 2.1.5-21 - Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild * Fri Jul 02 2010 Kamil Dudka 2.1.5-20 - handle multi-partition devices with spaces in mount points properly (#608502) - la sezione Prep Ovviamente prep è una abbreviazione di prepare e definisce i comandi necessari per preparare il pacchetto alla compilazione, se il pacchetto sorgente è un file compresso, quata sezione deve estrarre i sorgenti La sizione prep comincia sempre con un %prep e se devi estrarre files da archivi compressi in formato tar, occorre anche la macro %setup -q La sezione prep è quella che prepara per la compilazione e, ovviamente, deve fare piazza pulita di precedenti build. In realtà la sezione prep accetta anche gli scrip di shell, comprese le variabili definite da RPM %prep rm -rf $RPM_BUILD_DIR/cdplayer-1.0 zcat $RPM_SOURCE_DIR/cdplayer-1.0.tgz | tar -xvf - In questo caso operiamo un delete ricorsivo nella directory di build per poter pulire il filessytem della build, dopodichè viene decompresso il file passato come argomento e inserito nella directory build specificata. Molto spesso i sorgenti richiedono delle patch per poter essere compilati in maniera appropriata, e tali patch vanno inserite qui. Esistono delle macro per rendere la scrittura del file spec molto meno pesante da scrivere. Relativamente alle macro, sono degli accorgimenti per evitare di scrivere l'intero path del sistema e prevengono da eventuali errori. In base a ciò che serve, esse sono: STANDARD /usr/lib/rpm/macros,: %_prefix /usr %_exec_prefix %{_prefix} %_bindir %{_exec_prefix}/bin %_sbindir %{_exec_prefix}/sbin %_libexecdir %{_exec_prefix}/libexec %_datadir %{_prefix}/share %_sysconfdir %{_prefix}/etc %_sharedstatedir %{_prefix}/com %_localstatedir %{_prefix}/var %_libdir %{_exec_prefix}/lib %_includedir %{_prefix}/include %_oldincludedir /usr/include %_infodir %{_prefix}/info %_mandir %{_prefix}/man REDHAT /usr/lib/rpm/redhat/macros %_prefix /usr %_sysconfdir /etc %_localstatedir /var %_infodir /usr/share/info %_mandir /usr/share/man %_initrddir %{_sysconfdir}/rc.d/init.d %_defaultdocdir %{_usr}/share/doc Esistono anche macro speciali o per il debugging %dump Prints out macro values %{echo:message} Prints message to stderr %{error:message} Prints message to stderr and returns BADSPEC %{expand:expression} Like eval, expands expression %{F:file_exp} Expands file_exp to a file name %global name value Defines a global macro %{P:patch_exp} Expands patch_exp to a patch file name %{S:source_exp} Expands source_exp to a source file name %trace Toggles the printing of debugging information %{uncompress:filename} Tests if file filename is compressed. If so, uncompresses and includes in the given context. If not compressed, calls cat to include file in given context. %undefine macro Undefines the given macro %{warn:message} Prints message to stderr Ovviamente è possibile la creazione di nuove macro per usi particolari, la cui struttura del file è: %define macro_name value For example: %define major 2 %define minor 2 %define patchlevel 7 You can then use a macro with the %macro_name or %{macro_name} syntax. For example: Version: %{major}.%{minor}.%{patchlevel} You can also expand the results of running shell commands using a %(command) syntax with parenthesis instead of curly braces. For example: %define today %(date) Most macros perform simple text substitution. You can also pass parameters to macros, and access those parameters within your macros, similarly to how shell scripts get command-line parameters. Cross Reference Chapter 14, Automating RPM with Scripts covers shell scripting with RPM. With parameters, you can expand the normal definition of a macro to the following: %define macro_name(options) value Any text within the parenthesis is passed to getopt(3), and acts as parameters to the macro. This is performed when the macro is expanded. You can also pass options to the macro using the %macro_name syntax (without curly braces). For example: %foo 1 2 3 This example passes the parameters 1, 2, and 3 to the macro foo. Inside the macro, you can use a shell script-like syntax to access the parameters through special macros. Table 10-6 lists these macros. Table 10-6 Parameter macros inside a macro expansion Macro Holds %0 The name of the macro %* All the parameters to the macro, except for any processed options %# The number of parameters %1 The first parameter %2 The second parameter %3 The third parameter, and so on with %4, %5 and beyond %{-p} Holds -p if the -p parameter was passed to the macro; otherwise holds nothing %{-p*} Holds the value passed with the -p parameter, if the -p parameter was passed to the macro; otherwise holds nothing %{-p:text} Holds text if the -p parameter was passed to the macro; otherwise holds nothing Note that all parameters listed in Table 10-6 hold the remaining parameters after getopt(3) processing. You can use these macros within the definition of your own macros. You can also nest macros, such as the following: %define mypatch() patch %{-p:-p%{-p*}} This macro expands to the patch command if no -p parameter was passed. If you pass a -p parameter, such as -p 1, then the macro expands to -p with the value of the -p parameter: patch -p1 Note This type of syntax is used heavily with the patch command - la sezione Build - la sezione Install - la sezione script di Install ed Uninstall - la sezione Verify - la sezione Clean - la sezione File