openSUSE:Linee guida per la creazione dei pacchetti

(Reindirizzamento da openSUSE:Packaging guidelines)
Linee guida creazione pacchetti
Le linee guida per la creazione dei pacchetti regolano tutti i dettagli specifici della creazione dei pacchetti per la distribuzione openSUSE. Ci sono regole generali, regole relative agli aspetti legali di un pacchetto, alle funzioni specifiche di un pacchetto e agli specifici tipi di pacchetto.
  • Chi controlla i pacchetti (reviewer) ha la responsabilità di segnalare gli specifici problemi di un pacchetto, mentre colui che crea il pacchetto (packager) ha la responsabilità di intervenire su questi problemi. Le persone che revisionano e creano il pacchetto lavorano insieme per determinare la gravità dei problemi (se bloccare un pacchetto o se è possibile lavorarci dopo l'inserimento nel repository).
  • Le linee guida per la creazione dei pacchetti sono una raccolta di problemi comuni e relativa gravità che andrebbe ad essi associata. Sebbene queste linee guida non dovrebbero essere ignorate, non dovrebbero nemmeno essere seguite ciecamente. Se pensi che il tuo pacchetto dovrebbe essere esentato da parte delle linee guida, segnala il problema nella mailing list openSUSE-packaging.
  • Nota anche che nel Build Service molte regole saranno imposte o segnalate, dopo una compilazione completata con successo, da uno strumento chiamato rpmlint. Colui che crea il pacchetto dovrebbe sempre controllarne il risultato per ricevere notifiche relative a errori comuni nella creazione del pacchetto e ottenere suggerimenti su come migliorare la creazione del pacchetto. Vedi Controlli nella creazione dei pacchetti per le spiegazioni della maggior parte degli avvertimenti di rpmlint. Quella pagina contiene anche le istruzioni su come possono essere soppressi i falsi positivi.
  • Se fosse necessario modificare le linee guida sei pregato di seguire il processo di modifica come lì delineato.

Linee guida generali

Ci sono alcune regole generali da seguire.

Non includere binari o librerie precompilate

Tutti i binari o le librerie incluse nei pacchetti openSUSE devono essere stati compilati a partire dai sorgenti inclusi nel pacchetto sorgente. È un requisito per le seguenti ragioni:

  • sicurezza: i binari e le librerie pre-impacchettati e non compilati a partire dai sorgenti potrebbero includere qualsiasi cosa, contenuto dannoso o pericoloso, o essere semplicemente non funzionanti. Inoltre ci sono funzionalità atrimenti impossibili da aggiustare o correggere.
  • Flag del compilatore: i binari e le librerie già impacchettati e non creati a partire dai sorgenti probabilmente non sono stati compilati con le stesse opzioni del compilatore usate come standard in openSUSE per ragioni di sicurezza e ottimizzazione.

Se hai dubbi se qualcosa è da considerarsi file binario o libreria, ecco alcuni criteri utili:

  • è eseguibile? Se sì, probabilmente è un binario.
  • Contiene un'estensione .so, .so.#, .so.#.# o .so.#.#.#? Se sì, probabilmente è una libreria.
  • Se hai dubbi chiedi sulla mailing list openSUSE-packaging.

Infine non sono permessi i pacchetti che richiedono componenti non open source per essere compilati (per esempio quelli che richiedono un compilatore proprietario).

Eccezioni

  • Alcuni programmi (di solito legati a compilatori o ad ambienti di compilazione per più sistemi) non possono essere compilati senza l'utilizzo di una toolchain precedente o di un ambiente di sviluppo (open source). Se il tuo pacchetto risponde a questo criterio, contatta l'openSUSE Packaging Committee per l'approvazione.
  • È prevista un'eccezione per i firmware binari, a condizione che rispondano ai requisiti qui documentati: Firmware binari

Accorpamento di più progetti

I pacchetti in openSUSE dovrebbero fare ogni sforzo per evitare di contenere più progetti separati e distinti accorpati in un singolo pacchetto.

Linee guida per i file Spec

Le regole che si applicano al contenuto dei file spec si trovano in un documento separato chiamato Linee guida per i file Spec.

Supporto delle architetture

Tutti i pacchetti openSUSE devono essere compilati con successo in file RPM binari per almeno una delle architetture supportate, cioè i586 e x86_64. Chi crea i pacchetti dovrebbe compiere ogni sforzo per consentire la compilazione per entrambe le architetture supportate. Il contenuto (codice che non necessità di compilazione) e il codice non dipendente dall'architettura (noarch) sono importanti eccezioni.

Pacchetti rilocabili

L'utilizzo dell'opzione di RPM per generare pacchetti rilocabili è fortemente scoraggiata. È difficile farla funzionare in modo appropriato, impossibile da usare dal programma di installazione o da zypper e yast e non è generalmente necessaria se si seguono le altre linee guida per la creazione dei pacchetti. Tuttavia, nell'improbabile possibilità che tu abbia una buona ragione per creare un pacchetto rilocabile, DEVI dichiarare questo intento e motivarlo nella richiesta di revisione del pacchetto.

Aspetti legali

Software vietato

Le applicazioni (o altro software) elencate in questa Lista nera delle applicazioni sul Build Service sono vietate.

Licenza

Le licenze dei software dovrebbero essere conformi alla definizione di Open Source (attualmente alla versione 1.9). Se hai dubbi riguardo alla conformità di una particolare licenza con la definizione di Open Source dovresti creare un bug utilizzando la categoria SUSE Tools -> SUSE Linux Legal Issues.

File Spec

I creatori dei pacchetti di solito entrano in contatto con le licenze dei software tramite i file spec. Un file spec può dichiarare la/e licenza/e per l'intero pacchetto o per i singoli sotto-pacchetti. Le licenze dovrebbero essere dichiarate utilizzando il formato abbreviato SPDX. SPDX e il suo elenco associato di licenze è, però, un progetto relativamente giovane. Di conseguenza l'elenco è limitato e non riguarda tutte le licenze con cui deve tipicamente confrontarsi un creatore di pacchetti openSUSE. Per ovviare temporaneamente a questo limite abbiamo creato un documento che contiene non solo le licenze SPDX esistenti, ma anche molte altre accettate per openSUSE Factory o openSUSE NonFree. Se non riesci ancora a trovare un nome abbreviato adatto per la licenza dovresti creare un bug utilizzando la categoria SUSE Tools -> SUSE Linux Legal Issues.

Oltre all'utilizzo di una sintassi predefinita per la dichiarazione delle licenze, openSUSE riconosce anche un tipo specifico di "grammatica" nei file spec. Puoi utilizzare gli operatori come 'and' per dichiarare un'associazione di licenze o 'or' per dichiarare la necessità di scegliere una delle licenze dichiarate. Puoi anche utilizzare le parentesi per raggruppare le licenze, per esempio 

License: (MIT or GPL-2.0) and LGPL-2.1+

potrebbe essere la dichiarazione per un pacchetto contenente un eseguibile binario e una corrispettiva libreria sotto licenza LGPL-2.1+.

Un altro punto da tenere in considerazione quando si scrivono i file spec è che i sotto-pacchetti erediteranno la licenza del pacchetto principale se si omette di inserire una licenza specifica per il sotto-pacchetto. Non è sempre la cosa ideale. Per esempio se decidi di creare un sotto-pacchetto separato per la documentazione dovresti controllare se questa è rilasciata sotto licenza, per esempio, GFDL-1.1 piuttosto che (sempre per esempio) sotto la licenza GPL-2.0+ del pacchetto principale. È raccomandabile aggiungere sempre una licenza ai sotto-pacchetti anche se questa coincide a quella del pacchetto principale, in questo modo la licenza sarà immediatamente evidente a chiunque leggerà successivamente il file spec.

Infine i testi delle licenze dovrebbero essere sempre copiati nel pacchetto. Di solito questo viene effettuato aggiungendo il nome del file alla sezione %doc del file spec. Le licenze spesso si trovano in file con nomi come COPYING, COPYING.LIB, LICENSE.txt, ecc.

Codice e contenuti a confronto

È importante fare una distinzione tra codice eseguibile e contenuti. Mentre il codice è consentito (presupponendo, naturalmente, che abbia una licenza open source compatibile, che non sia legalmente discutibile, ecc.), solo alcuni tipi di contenuti sono ammissibili. La regola è:

se il contenuto migliora l'esperienza utente, allora può essere inserito in un pacchetto per openSUSE. Questo significa, per esempio, che cose come caratteri, temi, clipart e sfondi del desktop sono ammessi.

Il contenuto deve, anche in questo caso, essere revisionato per l'inclusione. Deve avere una licenza open source compatibile e non deve essere legalmente discutibile. Inoltre ci sono varie restrizioni aggiuntive per il contenuto:

  • il contenuto non deve essere pornografico o contenere nudità, sia animata, che simulata o fotografata. Per queste cose ci sono posti più adatti su internet.
  • Il contenuto non deve essere offensivo, discriminatorio o dispregiativo. Se non sei sicuro se un dato contenuto corrisponde ad una di queste categorie, probabilmente lo è.

Alcuni esempi di contenuto lecito:

  • clipart da usare in suite d'ufficio;
  • sfondi per il desktop (non offensivi o discriminatori, con permesso per la libera redistribuzione);
  • caratteri (sotto una licenza open source, con nessuna questione di proprietà/legale);
  • i livelli di un gioco non sono considerati contenuti dato che i giochi senza livelli non funzionerebbero;
  • i suoni o la grafica inclusi in un pacchetto sorgente compresso utilizzato da un programma o da un tema (o dalla documentazione) sono accettabili;
  • la musica o l'audio di un gioco sono leciti se il contenuto è liberamente distribuile senza restrizioni;
  • i file di esempio inclusi con il pacchetto sorgente non sono considerati contenuto.

Alcuni esempi di contenuto non ammesso:

  • file di grafica di fumetti;
  • testi religiosi;
  • file mp3 (gravati da brevetto).

Se non sei sicuro che qualcosa sia considerabile come contenuto approvato, chiedi sulla mailing list openSUSE-packaging.

Funzionalità del pacchetto

Script init

Dal momento che openSUSE 12.3 è definitamente passata a systemd, non si dovrebbero più scrivere script init in stile SysV se devono essere usati soltanto su openSUSE - ma alcuni di questi potrebbero essere necessari per far sì che il proprio pacchetto funzioni anche con le distribuzioni meno recenti, in particolar modo SLE 11.

Per lo script init e il file service si raccomanda di:

  • Se sono presenti sia il file init che il file service, installare per openSUSE 12.3 e successive soltanto il file di service.
  • Se il pacchetto è necessario per SLE 11, installare necessariamente almeno il file init SysV
  • Se si intende supportare soltanto il file service, creare il collegamento (simbolico) rcXXX a /sbin/service, in modo tale che rcXXX continui a funzionare
  • Se si vuole rendere disponibile ufficialmente un nuovo pacchetto, considerare la tipologia di utenti per cui è pensato: creare un nuovo file service per openSUSE 12.3 e superiori - o un file init SysV per SLE 11.

Puoi anche (continuare a) usare il file init SysV per openSUSE, se lo desideri, ma valuta la possibilità di aggiungere un nuovo file service, dato che è molto semplice da scrivere.

File desktop

Se un pacchetto contiene un'applicazione con interfaccia grafica, è necessario includere anche un file .desktop adeguatamente installato. Per gli scopi di queste linee guida un'applicazione con interfaccia grafica è definita come una qualsiasi applicazione che disegna una finestra tramite X e che è eseguita all'interno di quella finestra. I file .desktop installati DEVONO seguire le specifiche desktop-entry-spec, particolare attenzione deve essere dedicata al controllo del corretto utilizzo delle voci Name, GenericName, Categories e StartupNotify.

Voce Icon nei file desktop

La voce Icon deve corrispondere al nome base del file dell'icona perché questo consente la gestione dei temi di icone, per esempio con:

  • Icon=comical

verrà da prima cercato il file .png corrispondente, se l'impostazione predefinota fallisce si proverà con .svg e infine con .xpm.

Creazione dei file .desktop

Se il pacchetto non include e installa già un suo file .desktop, è necessario crearlo manualmente e includerlo tra i sorgenti (per esempio Source3: %name.desktop). I contenuti di un file .desktop di esempio (comical.desktop) sono: 

[Desktop Entry]
Name=Comical
GenericName=Comic Archive Reader
Comment=Open .cbr & .cbz files
Exec=comical
Icon=comical
Terminal=false
Type=Application
Categories=Graphics;

Utilizzo di %suse_update_desktop_file

Non è sufficiente la semplice inclusione del file .desktop nel pacchetto. BISOGNA eseguire %suse_update_desktop_file nella sezione %install e inserire BuildRequires: update-desktop-files per aiutare a garantire la sicurezza e la conformità del file .desktop. %suse_update_desktop_file DEVE essere utilizzato se il pacchetto non installa il file o se ci sono modifiche da fare al file .desktop (come l'aggiunta/rimozione di categorie, ecc). Ecco alcuni esempi d'uso:

  • controllare il file desktop
%suse_update_desktop_file %{name}
  • installare il file desktop e modificare le categorie
%suse_update_desktop_file -r %{name} System Utility Core GTK FileManager

Utenti e gruppi

Per il momento ci occupiamo primariamente del caso in cui l'associazione tra i nomi utente/gruppo e uid/gid sia decisa dinamicamente dai sistemi al momento dell'installazione del pacchetto. Sotto vengono discusse anche alcune opzioni per gli amministratori del sistema per rendere statica questa associazione anche se gli scriptlet del pacchetto utilizzano uno schema dinamico. Verranno spiegate anche ulteriori opzioni comprese le possibilità per rendere statica l'associazione al momento della compilazione del pacchetto.

Per creare utenti e gruppi nei pacchetti utilizza: 

Requires(pre): pwdutils

[...]

%pre
getent group GROUPNAME >/dev/null || groupadd -r GROUPNAME
getent passwd USERNAME >/dev/null || useradd -r -g GROUPNAME -d HOMEDIR -s /sbin/nologin -c "user for PACKAGENAME" USERNAME
exit 0

[...]

HOMEDIR di solito dovrebbe essere una cartella creata e di proprietà del pacchetto con permessi restrittivi adeguati. Una buona scelta come posizione della cartella è la cartella dei dati del pacchetto o quella sotto /var come /var/cache/NAME o /var/lib/NAME in caso ne abbia una.

I profili utente creati dai pacchetti sono raramente utilizzati per gli accessi interattivi e dovrebbero quindi utilizzare generalmente /bin/false o /sbin/nologin come shell dell'utente.


exit 0 alla fine avrà come conseguenza che lo scriptlet %pre ritornerà un risultato positivo anche se la creazione dell'utente/gruppo fallisse per un qualche motivo. La cosa non è ottimale, ma è preferibile rispetto al consentire un fallimento. Se l'utente/gruppo non fosse disponibile al momento della decompressione del pacchetto, rpm si limiterà a prendere quei file di proprietà di root.

getent è eseguito prima di groupadd/useradd per controllare se l'utente/gruppo che si sta per creare esiste già e in qual caso saltare la creazione. Questo per dare la possibilità agli amministratori locali di creare prima l'utente/gruppo a mano in caso essi desiderino ottenere un'associazione UID/GID statica predefinita per quegli utenti.

groupadd/useradd in %pre viene sempre eseguito: sia al momento delle installazioni iniziali che per gli aggiornamenti. Questo è possibile tramite i controlli getent sopra e dovrebbe correggere problemi in caso di eliminazione dell'utente/gruppo dopo l'installazione iniziale del pacchetto che si sta per aggiornare (così come i permessi dei file vengono reimpostati al momento degli aggiornamenti, ecc.).

Gli utenti o i gruppi creati dai pacchetti non vengono mai rimossi. Non c'è alcun modo fattibile per controllare se i file di proprietà di certi utenti/gruppi rimangono nel sistema e anche se ci fosse: cosa dovremmo fare con questi file? Lasciarli con i permessi che puntano a utenti/gruppi non più esistenti potrebbe causare problemi di sicurezza quando successivamente venisse creato un utente/gruppo semanticamente non correlato riutilizzando lo stesso UID/GID. Inoltre, in alcune configurazioni, la cancellazione dell'utente/gruppo potrebbe non essere possibile o desiderabile, per esempio, quando si utilizza un database remoto e condiviso per gli utenti/gruppi. La pulizia degli utenti/gruppi non usati è lasciata agli amministratori di sistema se lo desiderano.

In alcuni casi è auspicabile creare solo un gruppo senza un account utente. Di solito la ragione è che ci sono alcune risorse di sistema di cui vogliamo controllare l'accesso utilizzando questo gruppo e un account utente separato non aggiungerebbe alcunché. Esempi di casi comuni di questo tipo includono (ma non solo) giochi i cui eseguibili sono setgid per poter condividere i file del punteggio o le preferenze e/o programmi che hanno bisogno di permessi eccezionali per alcuni dispositivi hardware e che non sarebbe giusto concederli a tutti gli utenti del sistema o anche solo a quelli collegati alla console. In questi casi applica solo le parti relative a groupadd della soluzione di cui sopra.

Nota che la pratica di non creare utenti/gruppi se esistono già ha uno svantaggio relativo alla possibile esistenza di utenti e/o gruppi con lo stesso nome, ma non correlati con il risultato di ottenere accessi non necessari e non desiderabili a cose in un pacchetto che utilizza gli stessi utenti e/o gruppi. Questa versione delle linee guida per utenti/gruppi non si occupa del problema in alcun modo, ma è possibile che future revisioni lo faranno se si troverà un metodo efficace.

Patch

Vedi linee guida per le patch nella creazione dei pacchetti.

Supportare più versioni di un pacchetto

Vedi Supportare l'installazione di più versioni di un pacchetto.

Log delle modifiche

Vedi Creare file changes delle modifiche ai pacchetti RPM. Si noti infatti che openSUSE usa un file separato (file .changes) per i log delle modifiche dei file RPM (ovvero per la sezione changelog).

Scriptlet GConf

Definizioni del servizio SuSEfirewall2

Tipi di pacchetto

Alcune applicazioni hanno linee guida specifiche a loro dedicate in pagine nella gerarchia Creazione pacchetti.


Pacchetti 32bit (baselib)

openSUSE:Build_Service_baselibs.conf

Branding

Debuginfo

I pacchetti dovrebbero produrre pacchetti -debuginfo utili o bisognerebbe disattivare questi ultimi in modo esplicito se non è possibile generarne di utili. Nel caso in cui venga disattivato esplicitamente un pacchetto -debuginfo è necessario aggiungere una spiegazione della ragione nel file spec. I pacchetti debuginfo sono discussi in maggior dettaglio in un documento separato: [1].

Plugin di Eclipse

Emacs

Caratteri

I caratteri in formati per scopi generali come Type1, OpenType TT (TTF) o OpenType CFF (OTF) sono soggetti a specifiche linee guida per la creazione dei pacchetti e non dovrebbero mai essere inseriti in una cartella privata di un'applicazione invece che nelle posizioni dedicate ai caratteri a livello di sistema.

Giochi

La creazione dei pacchetti per i giochi è spiegata in Creazione dei pacchetti per i giochi.

GNOME

Go

La creazione dei pacchetti per i programmi in Go è spiegata in Creazione dei pacchetti per Go.

Haskell

Come creare i pacchetti per il software scritto in Haskell è spiegato in Creazione dei pacchetti per Haskell.

Java

La creazione dei pacchetti per i programmi in Java è spiegata in Creazione dei pacchetti per Java.

Lisp

Come creare i pacchetti per il software in Common Lisp è spiegato in openSUSE:Packaging_Lisp.

Lua

Come creare pacchetti per il software in Lua è spiegato in Creazione pacchetti per Lua.

Mono

Mozilla

OCaml

Estensioni di OpenOffice.org

PAM (Pluggable Authentication Modules)

Perl

La creazione dei pacchetti per i programmi in Perl è spiegata in Creazione dei pacchetti per Perl.

PHP

La creazione dei pacchetti per i programmi in PHP è spiegata in Creazione dei pacchetti per PHP.

Python

La creazione dei pacchetti per i programmi in Python è spiegata in Creazione dei pacchetti per Python.

R

Ruby

La creazione dei pacchetti per i programmi in Ruby è spiegata in Creazione dei pacchetti per Ruby.

wxWidgets

La creazione dei pacchetti per i programmi in wxWidgets è spiegata in Creazione dei pacchetti per wxWidgets

Librerie

Librerie condivise

Regole per la creazione di pacchetti di librerie condivise.

Binding di GObject Introspection (.typelibs)

Un buon numero di librerie, per lo più relative a GNOME, include un file .typelib. Questo .typelib è un'interfaccia tra vari linguaggi di programmazione (seed, python, vala) e la libreria. Proprio come le librerie condivise questi file hanno numeri di versione e possono potenzialmente richiedere l'installazione in più versioni.

Il nome del pacchetto segue la convenzione 

typelib-<GIVersion>-<TypeLibName>-<TypeLibVersion>

dove i punti (.) sono sostituiti con i trattini bassi (_).

Spiegazione dei <CAMPI>:

  • typelib: letterale, un identificatore del tipo di pacchetto.
  • <GIVersion>: l'attuale versione di gobject introspection è 1.0, quindi 1_0
  • <TypeLibName>: il nome del vero e proprio binding, con distinzione tra maiuscole e minuscole.
  • <TypeLibVersion>: la versione del binding.

Tutti questi elementi possono essere ricavati dal nome del file. Per esempio da /usr/lib/girepository-1.0/Memphis-0.2.typelib si ottiene il nome del pacchetto typelib-1_0-Memphis-0_2 Durante la creazione di questo tipo di pacchetti assicurati che il file spec contenga BuildRequires: gobject-introspection dato che questo attiva l'installazione ulteriore di uno strumento di scansione automatica delle dipendenze. Come risultato il pacchetto typelib-* richiederà automaticamente le sue librerie e se necessario altri pacchetti typelib.

Librerie statiche

I pacchetti che includono librerie dovrebbero escludere il più possibile le librerie statiche (per esempio tramite configurazione con opzioni come --disable-static). Le librerie statiche dovrebbero essere incluse solo in circostanze eccezionali. Le applicazioni che utilizzano librerie dovrebbero, per quanto possibile, utilizzare librerie condivise e non le versioni statiche.

Gli archivi libtool, file foo.la, non dovrebbero essere inclusi. I pacchetti che utilizzano libtool li installeranno in modo predefinito anche se li configuri con --disable-static, potrebbe quindi essere necessario rimuovere questi file prima della creazione del pacchetto. A causa di bug nelle versioni più vecchie di libtool o di bug nei programmi che la utilizzano, a volte non è sempre possibile rimuovere i file *.la senza modificare il programma. Nella maggior parte dei casi è abbastanza facile collaborare con il responsabile del programma per correggere questi problemi. Nota che se stai aggiornando una libreria in un rilascio stabile di openSUSE e il pacchetto contiene già i file *.la, la rimozione dei file *.la deve essere trattata come una modifica delle API/ABI, in altre parole la rimozione modifica l'interfaccia che la libreria offre al resto del sistema e non dovrebbe essere effettuata con leggerezza.

Eccezione

Vogliamo poter tenere traccia dei pacchetti che stanno utilizzando librerie statiche in modo da poter trovare i pacchetti che necessitano di essere ricompilati se viene risolta, per esempio, una problematica di sicurezza in una libreria statica. Se hai proprio bisogno di creare pacchetti contenenti librerie statiche, devi seguire queste linee guida.

Le librerie statiche devono essere poste in un sotto-pacchetto *-devel-static contenente un riferimento Requires al sotto-pacchetto *-devel. La separazione delle librerie statiche dagli altri file di sviluppo in *-devel ci permette di tenere traccia di questo comportamento controllando quali pacchetti contengono un BuildRequire per il pacchetto *-devel-static. Lo scopo è, se possibile, far utilizzare ai pacchetti le librerie condivise al posto delle statiche. Quando un pacchetto fornisce solo librerie statiche viene saltato Requires sul sotto-pacchetto *-devel. I pacchetti che hanno bisogno esplicitamente di fare riferimento alla versione statica devono quindi contenere BuildRequire: foo-devel-static in modo che l'utilizzo possa essere rilevabile.

Se (e solo se) un pacchetto ha librerie condivise che richiedono librerie statiche per funzionare, le librerie statiche possono essere incluse nel sotto-pacchetto *-devel. Il sotto-pacchetto devel deve contenere un Provide virtuale per il pacchetto *-devel-static e i pacchetti che dipendono da questo devono contenere BuildRequire per il pacchetto *-devel-static.

Duplicazione delle librerie di sistema

Per molte ragioni un pacchetto non dovrebbe includere o essere compilato su una copia locale di una libreria che esiste su un sistema. Il pacchetto dovrebbe essere integrato con una patch per utilizzare le librerie del sistema. Questo approccio previene il perdurare di vecchi bug e problematiche di sicurezza anche dopo l'aggiornamento e correzione delle librerie di sistema.

Tcl

Applicazioni web

Le applicazioni web in pacchetti per openSUSE dovrebbero posizionare il proprio contenuto in /srv/www/%name e NON in /var/www. Questo perché:

  • /var si suppone contenga file di dati variabili e registri. /srv/www è molto più appropriato in questi casi.
  • Gli utenti possono già avere qualcosa in /var/www e non vogliamo che un qualsiasi pacchetto openSUSE possa andare a sovrascrivere questo materiale.
  • /var/www non è più specificato nel Filesystem Hierarchy Standard.

Vala

Come rilevare la versione di Vala nel file spec

Partiamo dalla considerazione che tu non stia compilando lo stesso Vala. Se fosse così tu stesso hai definito la versione di Vala e puoi richiamarla semplicemente utilizzando il comando %{version}, il problema quindi non esisterebbe. Qui ci occupiamo di una situazione problematica come la seguente:

il pacchetto è compilato con Vala e funziona bene con tutte le versioni di Vala (quindi non devi aggiungere informazioni ulteriori tipo BuildRequires: vala >= 0.14), ma devi comunque rilevare e utilizzare il numero di versione di Vala.

E qui sorge un problema. Per ora Vala non può essere semplicemente incluso con BuildRequires: vala ed esportare la sua versione in modo semplice con qualcosa come %{py_ver} o %{perl_version} come fanno Perl o Python. Alcuni pacchetti hanno bisogno di sapere il numero di versione di Vala per poter funzionare (es. Babl o Gegl installeranno in modo predefinito un file .vapi in /usr/share/vala, ma quella cartella non ha senso in un sistema openSUSE standard. openSUSE utilizza cartelle con suffissi indicanti il numero di versione di Vala, per esempio /usr/share/vala-0.14. È quindi tua responsabilità spostare questi file dalla cartella predefinita dal pacchetto a quella necessaria per openSUSE.

Naturalmente potresti, utilizzando il comando %if 0?{%suse_verion} >= 1140, spostarli nella cartella con suffisso indicante il numero di versione standard di Vala installato in modo predefinito sulla quella specifica versione di openSUSE. Ma questo renderebbe il tuo file spec molto lungo e non gestibile (dovresti aggiungere questo tipo di sezione per praticamente tutte le versioni di openSUSE).

Utilizziamo invece la funzione autodefinita %define nel file spec in questo modo： 

 #importa la dipendenza Vala
 BuildRequires: vala
 #definisce una funzione per esportare il numero di versione di Vala
 %define vala_version %(rpm -q --queryformat='%{VERSION}' vala | sed 's/\.[0-9]*$//g')

Utilizziamo rpm -q --queryformat='%{VERSION}' vala per recuperare il numero di versione completo di Vala 0.14.0 che viene installato in modo standard prima che il processo di compilazione parta effettivamente (ragione per cui questo codice può funzionare). Poi usiamo il comando sed della shell con la versatilità delle espressioni regolari per tagliare il suffisso.0 e esportiamo il risultato nella variabile vala_version che può essere facilmente richiamata con %{vala_version}. Esempio: 

 #crea una nuova cartella. -pv serve per esportare le cartelle generate nel file di registro per successivo debug
 #e creare automaticamente le cartelle di livello superiore se non esistono.
 %{__mkdir} -pv %{buildroot}%{_datadir}/vala-%{vala_version}/
 #sposta i file
 %{__mv} %{buildroot}%{_datadir}/vala/* %{buildroot}%{_datadir}/vala-%{vala_version}/
 #cancella la cartella di origine
 %{__rm} -rf %{buildroot}%{_datadir}/vala/

Anche nella sezione %files puoi usare: 

 %dir %{_datadir}/vala-%{vala_version}/
 %{_datadir}/vala-%{vala_version}/*

per semplificare il tuo file spec.

Dato che ogni file nella %{buildroot} verrà inserito nel pacchetto RPM finale in una maniera strutturata gerarchicamente, il file spec risulterà piu maneggevole e di più facile comprensione.

Estratto da "https://it.opensuse.org/index.php?title=openSUSE:Linee_guida_per_la_creazione_dei_pacchetti&oldid=10060"