Creare un port per OpenBSD

Saper mettere mani ai pacchetti del sistema che si usa più frequentemente è un’abilità che torna utile spesso. Permette non solo di poter aggiornare o sistemare del software, ma anche di poter aiutare gli altri utenti allo stesso tempo: poter “tornare” qualcosa agli altri è quello che va a costruire una comunità in fondo.

Personalmente non ho molta esperienza come “packager”, ma ho creato/aggiornato abbastanza port (i BSD usano più frequentemente il termine “port” che “pacchetto”) di OpenBSD da sapermi arrangiare. Ieri ho creato e inviato un port per Telescope; dato che il software in questione è semplice da pacchettizzare e può essere quindi un buon esempio introduttivo.

Ottenere il port tree

I pacchetti (port) di OpenBSD sono organizzati in repository CVS che necessita di essere scaricato in locale. Il posto usuale è /usr/ports, ma volendo lo si può scaricare dove si preferisce (ma bisogna aggiustare PORTSDIR in /etc/mk.conf, si veda bsd.port.mk(5)).

Scaricare il port tree

mirror GitHub (in caso si preferisca l’uso di git a cvs)

Consiglio di non scaricare il port tree come tarball se si intende contribuire. NB: nulla vieta di usare la OpenBSD-STABLE, ma per contribuire bisogna testare i port sulla -CURRENT. Il port tree della -CURRENT potrebbe non funzionare sulla -STABLE.

Creare il port

Un port è, fondamentalmente, una cartella contenente un Makefile e altri file utili alla creazione del pacchetto (distfile, eventuali patch, …).

Per iniziare basta creare una cartella e copiare il template di Makefile:

la cartella ‘mystuff’ in /usr/ports è spesso usata come posto dove lavorare su dei port personali, per non “sporcare” l’albero principale.

Il Makefile.template ha molti commenti che vale la pena di leggere. In genere, cerco di seguire il file dall’inizio alla fine, tornando indietro a sistemare solo una manciata di variabili quando serve.

Come primo passo, possiamo cancellare un paio di commenti e definire COMMENT. Dato che non stiamo lavorando su un port python o Go, si possono cancellare le righe riguardanti MODGO e MODPY.

DISTNAME viene usato come base per il nome del pacchetto che, stando a packages-spec(7) è dato da “stem-version”, dato che è (o almeno era) comune distruibire dei tarball seguendo quella nomenclatura. (“Stem” è il nome del progetto, Telescope in questo caso, version il numero di versione.) Come il commento fa notare, DISTNAME non include il suffisso (“.tar.gz”, “.tgz”, …). Per quello c’è EXTRACT_SUFX poche righe più in basso. Nel caso di telescope, DISTNAME è “telescope-0.5.2”.

Telescope è disponibile su GitHub, quindi potremmo usare le variabili GH_* per definire il port, ma dato che è fornito anche un tarball stabile, useremo quello.

La variabile CATEGORIES è obbligatoria e va impostata ad almeno una categoria. In questo caso “net” è sufficiente. HOMEPAGE è anche opzionale, ma è buona prassi definirla.

La variabile MAINTAINER serve per definire il “responsabile” del port. Di default è la mailing list ports@openbsd.org, e non è visto male non voler prendere la “maintainership” del port. Però è una mossa carina. A differenza di altri repository, il MAINTAINER non è “più importante”, per piccole cose, o se non risponde entro due settimane, viene allegramente scavalcato. Vale la pena aggiornare/migliorare dei port che hanno già un maintainer.

PERMIT_PACKAGE serve per specificare se OpenBSD può effettivamente distribuire il pacchetto precompilato. La maggior parte dei port ha questa variabile settata a “Yes”, ma ci sono alcuni casi nei quali licenze particolari possono impedirne la diffusione. È richiesto di specificare la licenza come commento prima della riga di PERMIT_PACKAGE: si tratta di un “best effort”, ma è comunque un dato utile.

WANTLIB serve per specificare le dipendenze del port, questa è una di quelle variabili che specificheremo in seguito.

MASTER_SITES è l’URL da cui scaricare il DISTFILE, in questo caso useremo github:

Svariate varibili commentate di seguito non servono in casi semplici come questi. Dato che telescope è scritto in (più o meno) C99 non serve aggiustare la variabile COMPILER, e non serve nemmeno usare nessun modulo, quindi anche la variabile MODULES può essere ignorata.

{BUILD,RUN,LIB,TEST}_DEPENDSh conviene tenerle commentate per un po’, in seguito quando specificheremo meglio le dipendenze probabilmente andranno settate.

Immediatamente dopo segue un blocco di commenti piuttosto “denso”, ma è in fondo anche l’ultimo che andrà configurato. CONFIGURE_STYLE serve per definire lo stile usato (se usato) per la fase di configurazione del port. In genere gli step seguiti sono:

fetch

extract

patch

configure

build

fake (install)

package

telescope usa gli autotools e il tarball fornisce uno script configure già pronto, quindi basta impostare CONFIGURE_STYLE a “gnu” per finire. Da qui fino a “.include <bsd.port.mk>” non ci serve settare nulla.

Tutte le variabili sono descritte in breve come commenti del template, che meritano di essere letti, oppure nel dettaglio in bsd.port.mk(5).

Il Makefile a questo punto dovrebbe essere più o meno:

Il prossimo passo è generare i checksum e scaricare i sorgenti in locale:

a fianco al Makefile ora c’è anche “distfile” contenente i checksum.

Nonostante l’infrastruttura dei port è in grado di accorgersi da sola quando “make makesum” vada chiamato, preferisco farlo a mano per controllare che i checksum siano effettivamente corretti.

Compilare il port è davvero semplice, basta soltanto:

A questo punto possiamo simulare l’installazione con ‘make fake’ e generare la lista di file installati con ‘make plist’. Quest’ultimo in particolare andrà a generare il file ‘pkg/PLIST’.

Ora che abbiamo compilato il port, è un ottimo momento per controllare le effettive dipendenze. Almeno per port in C o C++, controllare le librerie richieste è semplicissimo:

ci viene anche suggerito cosa aggiungere al makefile! Dopo aver aggiunto WANTLIB come richiesto (l’avevamo lasciata commentata) conviene riprovare.

In genere bisogna anche controllare che durante la fase di compilazione non vengano usati altri programmi (git è un caso comune), e aggiustare BUILD_DEPENDS di conseguenza.

Dato che telescope usa solo librerie fornite dal sistema base, tutte le variabili {BUILD,RUN,LIB,TEST}_DEPENDS possono essere rimosse!

Il makefile a questo punto è:

L’ultimo passo è fornire un file ‘pkg/DESCR’ con una descrizione (più lunga del COMMENT) del pacchetto. Una volta fatto questo, possiamo creare il pacchetto (ed eventualmente installarlo).

Fine :)

Scherzavo, c’è ancora una piccola correzione che possiamo fare. Per evitare di ripetere il numero di versione due volte nel makefile (nel DISTFILE e nel MASTER_SITES), in genere si definisce una variabile ‘V’:

evviva la pigrizia!

Per contribuire dei port si usa la mailing list ports@openbsd.org. Nuovi port vengono inviati come tarball, aggiornamenti come diff. Conviene essere iscritti alla mailing list

OpenBSD mailing list

$BlogIt: creare-un-port-per-openbsd.gmi,v 1.1 2021/10/20 07:41:39 op Exp $