Repository 32bit  Forum
Repository 64bit  Wiki

Linee guida per pacchettizzatori Slackware 14.1

Da Slacky.eu.
Versione delle 08:55, 31 dic 2013, autore: Slacky (Discussione | contributi)

(diff) ← Versione meno recente | Versione attuale (diff) | Versione più recente → (diff)


Indice

DISCLAIMER

Le seguenti linee guida sono passibili di variazioni in corso d'opera.

Per discutere delle eventuali modifiche, fare riferimento al forum di Slacky.eu.

Questa guida vuole definire delle linee da seguire per semplificare la creazione di pacchetti per il repository di Slacky.eu. Una copia di questa guida in formato testuale si può trovare quì (potrebbe non essere aggiornata all'ultima release. fate sempre riferimento a questo documento per gli ultimi update)

Si invita calorosamente a seguirla per uniformare il repository in modo che una seconda persona che voglia toccare uno SlackBuild sappia già dove mettere le mani senza doversi studiare il lavoro del suo predecessore.

Prerequisiti

I pacchetti da caricare sul repository Slacky devono essere compilati sull'ultima Slackware-stable, installata full (escludibile KDEI). Potete installare i vostri programmi preferiti, l'importante è che le librerie aggiuntive non influenzino il corretto sviluppo del precompilato.

Inoltre sul sistema deve essere installato requiredbuilder per la gestione delle dipendenze.

Chi volesse installarsi particolari programmi che possano invadere le librerie standard (in particolare, per chi usa Slackware64, le multilib di compatibilità a 32 bit di AlienBob) o volesse installarsi la current, può optare per l'utilizzo di una macchina virtuale o di una installazione in chroot (consigliata).

La cosa importante è che tutte le dipendenze dei pacchetti vengano risolte all'interno di pacchetti Slackware o di pacchetti slacky già presenti nel repository. Nel caso non lo fossero, vanno preventivamente pacchettizzate.

Compilazione multi-arch

A partire da Slackware 13.1, su Slacky.eu è disponibile il repository a 64 bit (separato da quello a 32 bit).

Chi ha un pc a 32 bit non ha problemi... compila solo pacchetti a 32 bit.

Con un sistema a 64 bit si compila a 64 bit e basta. I pacchettizzatori che volessero mettere a disposizione il pacchetto a 32 bit e a 64 bit devono installarsi anche una Slackware 32 bit, possibilmente allineata - come patch level e software aggiuntivo - con quella a 64 bit.E' possibile installare questa Slackware in una macchina virtuale o in chroot. Nonostante la distribuzione 'madre' sia a 64 bit, una Slackware 32 bit in chroot funziona ed è in grado di compilare perfettamente, eccezion fatta per la compilazione di moduli kernel e pacchetti particolari.

Può essere utile lo Slackware Chroot AutoBuilder a tal proposito.

Costituzione di un pacchetto

Per fare un pacchetto slacky abbiamo bisogno di:

Nota: i template scaricabili potrebbero non essere aggiornati all'ultimissima versione. Fare sempre riferimento a questo documento per gli ultimi update.

La directory dei sorgenti

I path standard dei repository slacky sono così composti:

./Categoria del software/nome del pacchetto/versione del pacchetto/<pacchetto.txz>

./categoria del software/nome del pacchetto/versione del pacchetto/src/<sorgenti>

quest'ultima directory conterrà lo SlackBuild, lo slack-desc, lo slack-required ed eventuali altri file da inserire nel pacchetto, se necessario, come il doinst.sh, gli initscript, qualche file di configurazione, eventuali patch e se necessario i sorgenti del software. Questi ultimi andrebbero messi solamente se non è possibile scaricarli semplicemente con un wget; per il resto andrebbe inserito un wget nello SlackBuild che scarichi i sorgenti dal sito ufficiale del produttore.

Questo consente di risparmiare molto spazio sul server slacky e soprattutto molta banda. Laddove il software non fosse scaricabile con un wget ma solo interattivamente (riempimento di un CAPTCHA, accettazione di una licenza, login al sito, link con controlli di sessione, ecc...), allora si scaricano i sorgenti manualmente e si caricano sul server. Se il pacchetto è non-GNU andrebbe caricata anche la licenza (solitamente presente all'interno del pacchetto) rinominandola in EULA.TXT e costringere l'utente ad accettarla PRIMA del download del pacchetto. Questo dovrebbe risolvere preventivamente problemi legali per i software commerciali.

Notazioni

Riguardo al nome del pacchetto, capita a volte che il nome di un software sia tipicamente scritto con l'iniziale maiuscola o altre parti del nome maiuscole. Alcuni esempi: MySQL, TiMidity++, MPlayer, Judy. E' opportuno che il pacchetto che viene generato sia comunque scritto rispettando il nome originale; lo stesso vale per lo SlackBuild e lo slack-desc.

SlackBuild Template

Per slack-desc, SlackBuild e doinst.sh sono stati elaborati dei template. Vi preghiamo di utilizzare questi per i vostri pacchetti, perché così facendo sarà più semplice condividerlo con gli altri pacchettizzatori.

In questa sezione vengono riportati i template per intero. Nella sezione successiva si provvederà a spiegarli punto per punto per semplificare l'adattamento del template al proprio software.

Changelog

  • 04/12/13 -> Adattato per Slackware 14.1, aggiunto il caso GIT/SVN in download, aggiunti i casi "cmake", "SCons", "python" in fase di compilazione, riscrittura parziale dell'intera guida.
  • 27/08/12 -> Aggiunta licenza 3rd parti, supporto a DOCS e SLKFILES. aggiunto JOBS. sistemazioni varie.
  • 04/07/12 -> Comincia l'adattamento per la 14.0, aggiunto il supporto a xz e inserito alla fine dell'intestazione la riga "Require" dove possiamo inserire dipendenze che non vengono intercettate da requiredbuilder, esempio i pacchetti Slackware che troviamo in /extra.
  • 24/04/11 -> Adattato per 13.37, rimosso cmake, modificati i commenti, aggiunto autodetect tar, directory, documentazione e doinst.sh.
  • 14/06/10 -> Rimosso depfinder.
  • 26/05/10 -> Rimosso MAKEFLAGS (v. compilazione più in basso).
  • 26/05/10 -> Aggiunto CHOST e MAKEFLAGS.
  • 26/05/10 -> Separato TAG e BUILD.
  • 24/05/10 -> Aggiunto cmake.

Intestazione

  • La shell da utilizzare è sempre /bin/sh.
  • Specificare per quale versione di Slackware è scritto lo SlackBuild.
  • Specificare l'autore dello SlackBuild. Inserire il nome proprio oppure il nick, ma come contatto possibilmente inserire un indirizzo email (mio <at> indir.email). Se state ricompilando un pacchetto di terzi lasciate l'autore "così com'è" (in pratica, non "impossessatevi" dello SlackBuild). Se lo SlackBuild originale non è di Slacky.eu, molto probabilmente il formato della intestazione sarà diverso: lasciatela così com'è ed inserite una nota di adattamento.
  • L'ultimo che l'ha modificato e compilato (ovvero tu).
  • Il nome del pacchetto e il sito ufficiale.
  • Una licenza per la distribuzione dello SlackBuild.
  • Eventuale inserimento delle dipendenze extra, esempio quelle non rilevate da requiredbuilder e quelle che fanno parte degli extra di Slackware. Queste non verranno inserite nel file required ma servono solo per agevolare i fruitori dello SlackBuild.
#!/bin/sh
 
# Heavily based on the Slackware 14.1 SlackBuild
# Written by <your name> ( your [at] email.address )
# Last build from <your name> ( your [at] email.address )
 
# Slackware build script for <appname>
# Official Site: http://......

Se si copia uno SlackBuild totalmente o in parte (parti speciali come post-make particolari ecc) inserire la licenza originale (comprensivo di autore) o quantomeno linkare lo SlackBuild originale. Per esempio:

# Heavily based on the Slackware 14.0 SlackBuild
# Copyright 2009, 2010, 2011, 2012  Eric Hameleers, Eindhoven, NL
# Copyright 2009, 2010, 2011, 2012  Patrick J. Volkerding, Sebeka, MN, USA
# All rights reserved.
 
# Written by Eric Hameleers < alien at slackware.com >
# Adapted to slacky's standard by <your name> ( your [at] email.address )
 
# Slackware build script for <appname>
# Official Site: http://......
# Patches from ...

Se è già presente una licenza lasciarla, altrimenti mettere la seguente di default.

# Redistribution and use of this script, with or without modification, is
# permitted provided that the following conditions are met:
#
# 1. Redistributions of this script must retain the above copyright
#    notice, this list of conditions and the following disclaimer.
#
# THIS SOFTWARE IS PROVIDED BY THE AUTHOR ''AS IS'' AND ANY EXPRESS OR IMPLIED
# WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
# MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
# EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
# PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
# OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
# WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
# OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
# ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
#
# Require:

Modificare Require se necessario. Vanno inserite solo le dipendenze extra, ad esempio quelle non rilevate da requiredbuilder, quelle che fanno parte degli extra di Slackware oppure le dipendenze necessarie solamente in fase di compilazione. Queste non verranno inserite nel file required ma servono solo per agevolare i fruitori dello SlackBuild.

Per esempio:

# Require: apache-ant, jdk >= 6 | openjdk >= 6

Settiamo il nostro script in modo che termini ad ogni errore con:

set -e

Parametri

La seguente sezione è quella che contiene i parametri base, cioè:

  • nome del pacchetto
  • versione
  • architettura
  • build version
  • url diretto al download dei sorgenti
  • documentazione da copiare in /usr/doc e i file presenti nella directory dello SlackBuild.

Per quanto riguarda il BUILD, la norma è che ad ogni modifica del pacchetto, ricompilazione ecc, il numero vada incrementato, mentre ad ogni upgrade (cambio di versione) questo numero ritorna ad 1.

Per quanto riguarda il TAG (la sigla dopo il numero), a partire dal repository per Slackware 13.1 questo deve essere obbligatoriamente 'sl', inclusi per i pacchetti già presenti nel 13.0 che verranno semplicemente ricompilati senza modifiche per essere portati nel nuovo repository. Questo perchè ora la sigla non indica più l'autore ma il repository su cui si trova.

Per l'URL utilizzate esclusivamente il sito ufficiale del prodotto. Occhio ai doppi apici in SOURCE="" . Senza di essi, non in tutti i casi funziona. Fate anche attenzione a quegli url che come separatore non hanno un trattino bensì un underscore (_) pechè in tal caso la sintassi $PKGNAME_$VERSION non funziona, visto che bash considera quell'underscore come parte del nome della variabile. In tal caso sostituite $PKGNAME con ${PKGNAME}: ${PKGNAME}_${VERSION}.

In DOC andrà messa la documentazione che verrà copiata nella /usr/doc, quella presente nella radice del sorgente, per capirci (README, INSTALL, ecc..). Sono ammessi nomi di directory (per chiarezza mettiamoci una / finale, per esempio doc/, anche se in teoria non serve. Sono accettati i caratteri jolly supportati da cp (README* et similia).

PKGNAME=appname
VERSION=${VERSION:-1.4.1}
BUILD=${BUILD:-1}
TAG=${TAG:-sl}
ARCH=${ARCH:-i486}
SOURCE="http://downloads.sourceforge.net/project/......./${PKGNAME}-${VERSION}/${PKGNAME}-${VERSION}.tar.gz"

In caso di sorgenti ricavati da git e simili (svn, cvs, mercurial...) cambiare il parametro VERSION in

VERSION=$(date +%Y%m%d)

Nel template il nome del tarball scaricato viene riconosciuto in automatico con un basename del sorgente, quindi non è necessario modificare wget e tar se si cambia formato di compressione o se il nome usa _ invece di - o altro. Il primo livello di directory del tar viene calcolato automaticamente essere 'nome tarfile' senza tar.gz . In questi casi lasciare DIR e TAR vuote.

TAR=
DIR=
DOCS="AUTHORS COPYING INSTALL TODO TROUBLESHOOTING docs/ ..."
SLKFILES=""

In caso di sorgenti ricavati da git e simili (svn, cvs, mercurial...) cambiare i parametri TAR e DIR in:

TAR=$PKGNAME-$VERSION.tar.bz2
DIR=$PKGNAME

Nel caso una delle due condizioni non fosse vera, non è necessario andare a modificare tutto il resto dello SB (if [ ! -e , wget, tar, cd, eventuale altre parti), ma è sufficiente modificare le suddette variabili TAR e DIR.

TAR=${PKGNAME}-${VERSION}.tar.bz2
DIR=${PKGNAME}${VERSION}

DOCS indica tutti quei file presenti nei sorgenti da copiare in /usr/doc; in passato questa lista veniva modificata ogni volta nella sezione documentazione più in fondo. SLKFILES indica tutti quei file che sono necessari allo SlackBuild in quanto ora vengono copiati per intero nella /usr/doc; dalla lista vanno esclusi slack-desc doinst.sh slack-required e EULA.TXT che vengono copiati in automatico se presenti.

In SLKFILES vanno invece messi tutti i file che si trovano nella directory dello SlackBuild così che questi vengano copiati automaticamente in /usr/doc/pacchetto-versione/Slackbuild. Tale variabile non deve contenere:

  • lo SlackBuild stesso
  • slack-desc
  • slack-required
  • doinst.sh
  • doinst.sh.gz
  • EULA.TXT

in quanto lo slackbuild del template è in grado di rilevarli e copiarli automaticamente. Escludete anche i sorgenti scaricati dalla wget. Inserite invece eventuali patch, file di configurazione custom, ecc. Per intenderci tutto quello che viene caricato poi su Slacky deve essere presente in quella variabile. In caso non hai file aggiuntivi potete lasciarla vuota.

DOCS="AUTHORS COPYING INSTALL TODO TROUBLESHOOTING docs/"
SLKFILES="makefile.diff myfile.conf"

Architettura

In base all'architettura definita in $ARCH, vengono definiti i parametri della compilazione. Da notare il LIBDIRSUFFIX che determina se le librerie andranno a finire in /usr/lib o /usr/lib64.

case "$ARCH" in
	  i?86) export ARCH=i486; SLKCFLAGS="-O2 -march=i486 -mtune=i686"; CHOST="i486-slackware-linux" ;;
	x86_64) SLKCFLAGS="-O2 -fPIC"; LIBDIRSUFFIX="64"; CHOST="x86_64-slackware-linux" ;;
	  arm*) export ARCH=arm; SLKCFLAGS="-O2 -march=armv5te"; CHOST="arm-slackware-linux-gnueabi" ;;
# Unless $ARCH is already set, use uname -m for all other archs:
	     *) export ARCH=$( uname -m ) ;;
esac

EULA

Nel caso si tratta di un software non OpenSource, o che per la sua distribuzione è necessario l'accettazione di una licenza, prendere il file di licenza dai sorgenti (solitamente LICENSE.TXT o simili) e metterla nella directory dello SlackBuild con nome EULA.TXT. La seguente sezione provvederà, se presente, a mostrare la EULA a schermo e a chiedere all'utente di accettarla.

if [ -e EULA.TXT ];then
  more EULA.TXT
  echo "Do you accept terms? (yes/[no])"
  read ACCEPT
  if [ "$ACCEPT" != "yes" ];then
    echo; echo "SlackBuild Aborted!!"
    exit 1
  fi
fi

Questa sezione può essere lasciata anche in caso di software OpenSource. Se non è presente EULA.TXT verrà ignorata.

Path di lavoro

Questa parte è fissa, cioè la determinazione dei path di lavoro. Molto difficilmente dovrete variare qualcosa. Se la directory dei sorgenti non è $PKGNAME-$VERSION utilizzate le variabili TAR e DIR precedenti.

JOBS=${JOBS:--j2}
CWD=$(pwd)
TMP=${TMP:-/tmp/buildpkgs/$PKGNAME}
PKG=$TMP/package-$PKGNAME
OUTPUT=${OUTPUT:-$CWD}
TAR=${TAR:-$(basename $SOURCE)}
DIR=${DIR:-$(echo "$TAR"|sed -r 's/(\.tar|)(.gz|.bz2|.xz|)$//')}

JOBS è la variabile che determina il numero di processi paralleli per compilare (make -j2 per capirci). Non variamo questo valore. Se avete un processore potente e volete compilare veloce potete fare l'override locale quando lanciate lo slackbuild:

export JOBS=-jX
./package.SlackBuild

o, più semplicemente

JOBS=-jX ./package.SlackBuild

Download automatico dei sorgenti

Quindi si fa il download del pacchetto. Modificare solamente se si necessitano cose particolari, per esempio altri tipi di download, download di più file o patch...

if [ ! -e "$CWD/$TAR" ];then
  wget "$SOURCE" -O "$CWD/$TAR"
fi

In caso di sorgenti ricavati da git e simili (svn, cvs, mercurial...) la sezione verrà scritta nel seguente modo:

if [ ! -e $CWD/$TAR ];then
# Download sources from git/mercurial/svn/etcetera into a directory named $DIR
	git clone $SOURCE $DIR #oppure svn checkout $SOURCE $DIR, cambia a seconda dei casi
	tar czf $TAR $DIR
	rm -rf $DIR
fi

Preparazione dei sorgenti

Ora verranno preparati i sorgenti per la compilazione vera e propria. Si effettuano:

  • rimozione di una compilazione precedente
  • estrazione dei sorgenti
  • applicazione di eventuali patch, le quali devono essere presenti nella stessa directory dello SlackBuild e possono essere facoltativamente compresse.
  • settaggio dei permessi: è opportuno che i permessi dei sorgenti siano solamente 755 o 644 e che i file siano tutti di root.
rm -rf $TMP
mkdir -p $TMP $PKG $OUTPUT
cd $TMP
tar xvf $CWD/$TAR
cd $DIR
 
# eventuali patch
 
chown -R root:root .
chmod -R u+w,go+r-w,a-s .

Compilazione

Comincia la compilazione. Nella maggior parte dei casi sarà sufficiente utilizzare lo standard ./configure&&make&&make install. Segue anche trattazione per altri casi (ben rari, a onor di cronaca).

Configure && make && make install

Per quanto riguarda i parametri del configure, questi variano ovviamente da pacchetto a pacchetto, ma alcuni standard vanno seguiti:

  • Il pacchetto va installato in /usr
  • La configurazione deve andare in /etc
  • Le man pages vanno in /usr/man. Se l'installer le mette in /usr/share/man allora bisogna spostarle "a mano" successivamente.
  • I dati andrebbero messi in /var/nomepacchetto o /var/lib/nomepacchetto, a seconda del pacchetto. Ad esempio, apache li mette in /var/www, Mysql li mette in /var/lib/mysql.
  • Le librerie (questo è importante) vanno messe in /usr/lib per i pacchetti a 32bit e in /usr/lib64 per i pacchetti a 64bit. Questo viene fatto automaticamente se si setta correttamente --libdir=/usr/lib$LIBDIRSUFFIX. Se avete una macchina a 32bit e scrivete solamente pacchetti a 32bit, lasciate comunque questa accortezza per aiutare chi vorrà compilare il pacchetto a 64bit
  • In aggiunta metterete tutte le altre opzioni specifiche del software.
  • Per passare parametri a make (tipo "-j2") utilizzate la variabile JOBS dall'infuori lo SlackBuild come spiegato poco sopra.
  • Per passare dei CFLAGS/CXXFLAGS customizzati, passare esternamente i parametri come con la variabile JOBS usando le variabili stesse CFLAGS/CXXFLAGS. (vedi sopra)
CFLAGS="$CFLAGS $SLKCFLAGS" \
CXXFLAGS="$CXXFLAGS $SLKCFLAGS" \
./configure \
	--prefix=/usr \
	--libdir=/usr/lib$LIBDIRSUFFIX \
	--docdir=/usr/doc/$PKGNAME-$VERSION \
	--sysconfdir=/etc \
	--localstatedir=/var \
	--mandir=/usr/man \  
	--build=$CHOST

"make" lancia la compilazione e "make install" esegue l'installazione. La variabile DESTDIR indica in quale directory installare il tutto, nel nostro caso la directory temporanea indicata in PKG.

make $JOBS
make install DESTDIR=$PKG

In alcuni casi, la variabile potrebbe non essere DESTDIR. In tal caso cambiarla con la variabile dedicata.

Cmake

Alcuni pacchetti usano il sistema Cmake. Consultare il README nei sorgenti per informazioni. In tal caso valgono comunque tutte le considerazioni fatte sopra, ma la sintassi è diversa:

(
	mkdir -p build
	cd build
	cmake .. \
		-DCMAKE_C_FLAGS:STRING="$CFLAGS $SLKCFLAGS" \
		-DCMAKE_CXX_FLAGS:STRING="$CXXFLAGS $SLKCFLAGS" \
		-DCMAKE_INSTALL_PREFIX=/usr \
		-DMAN_INSTALL_DIR=/usr/man \
		-DSYSCONF_INSTALL_DIR=/etc \
		-DLIB_SUFFIX=${LIBDIRSUFFIX}
	make 
	make install DESTDIR=$PKG
)

Python

Alcuni pacchetti usano il sistema Python, in quanto scritti nel suddetto linguaggio. Consultare il README nei sorgenti per informazioni.

python setup.py install --root=$PKG

SCons

Alcuni pacchetti usano il sistema SCons. Consultare il README nei sorgenti per informazioni.

scons LIBDIR=/usr/lib$LIBDIRSUFFIX INSTALL_ROOT="$PKG" install

Personalizzazione

Per la maggior parte dei pacchetti questa sezione è facoltativa.

Le sezioni che seguono sono quelle che probabilmente più dovrete personalizzare. Qui si devono cancellare file inutili o che rischiano di sovrascrivere quelli di sistema, spostare alcuni file in altri path ecc.

## Do special operations

Se avete compilato un modulo perl, probabilmete vi sarà stato creato un file che, se messo nel pacchetto, va a sostiturire quello già presente sul sistema. Ovviamente se non state compilando un modulo perl non inserirete questa sezione.

( cd $PKG
  # Remove 'special' files
  find . -name perllocal.pod \
    -o -name ".packlist" \
    -o -name "*.bs" \
    | xargs rm -f
)

Potrete anche copiare file di configurazione ed eventuali altri file dalla directory dello SlackBuild.

Ricordate poi che gli script di start e stop si dovrebbero mettere possibilmente sotto /etc/rc.d; ricordo anche che tutti i file di configurazione (script inclusi) vanno messi con l'estensione .new per essere poi rinominati a posteriori nel doinst.sh..

cat $CWD/rc.application.sh > $PKG/etc/rc.d/rc.application.new
cat $PKG/etc/init.d/initscript >> $PKG/etc/rc.d/rc.program.new
rm $PKG/etc/init.d/initscript
mv $PKG/etc/appl.conf $PKG/etc/appl.conf.new

Documentazione

Adesso copiamo tutta la documentazione che riusciamo a trovare nei sorgenti del pacchetto (README, INSTALL, ChangeLog, ecc..) nella directory della documentazione. Tutti questi file li mettiamo nella variabile DOCS come spiegato sopra. Nella sottodirectory SlackBuild/ andrà inserito anche lo SlackBuild con cui è stato generato il pacchetto e gli altri file (vedi parametro SLKFILES). Se valorizzate correttamente queste due variabili non dovrebbe essere necessario fare altre modifiche a questa sezione (a meno di situazioni particolari, come di documentazioni prese da sottodirectory o rianalizzate o altro)

mkdir -p $PKG/usr/doc/$PKGNAME-$VERSION
 
for DC in $DOCS;do
	[ -e $DC ] && cp -r $DC $PKG/usr/doc/$PKGNAME-$VERSION/ || true
done
 
mkdir -p $PKG/usr/doc/$PKGNAME-$VERSION/SlackBuild
 
cd $CWD
for SB in $PKGNAME.SlackBuild slack-desc doinst.sh doinst.sh.gz EULA.TXT $SLKFILES;do
	[ -e "$SB" ] && cp -r $SB $PKG/usr/doc/$PKGNAME-$VERSION/SlackBuild/$SB || true
done

Per lo standard di Slackware tutte le man pages devono essere compresse in formato gzip, di conseguenza cerchiamo le versioni non compresse che installano i pacchetti e le comprimiamo.

for i in man info
do
    if [ -d $PKG/usr/$i ]; then
   		cd $PKG/usr/$i
		find . -type f -exec gzip -9 {} \;
		for file in $( find . -type l ) ; do ln -s $( readlink $file ).gz $file.gz ; rm $file ; done
		[ "$i" == "info" ] && rm -f dir.gz
    fi
done

Stripping dei binari

Puliamo i binari e le librerie ottenuti eliminando tutti gli extra che gcc crea al fine di facilitare il debug e linkare tra di loro gli object generati.

cd $PKG
find . | xargs file | grep "executable" | grep ELF | cut -f 1 -d : | xargs -r strip --strip-unneeded 2> /dev/null || true
find . | xargs file | grep "shared object" | grep ELF | cut -f 1 -d : | xargs -r strip --strip-unneeded 2> /dev/null || true
find . | xargs file | grep "current ar archive" | cut -f 1 -d : | xargs -r strip --strip-unneeded 2> /dev/null || true

Aggiunta doinst.sh e slack-desc

Vanno creati e aggiunti i file slack-desc (la descrizione del pacchetto) e il doinst.sh (script da eseguire in post-installazione).

mkdir -p $PKG/install
cat $CWD/slack-desc > $PKG/install/slack-desc
[ -e $CWD/doinst.sh ] && cat $CWD/doinst.sh > $PKG/install/doinst.sh
[ -e $CWD/doinst.sh.gz ] && zcat $CWD/doinst.sh.gz > $PKG/install/doinst.sh

Per informazioni sulla creazione dei doinst.sh e slack-desc cliccare sui nomi per visualizzare le sezioni apposite (più in basso).

Creazione slack-required

Viene aggiunta l'esecuzione di requiredbuilder per creare un file slack-required, usato per la gestione delle dipendenze.

cd $PKG
chown -R root:root $PKG
 
if [ -x "$(which requiredbuilder 2>/dev/null)" ];then
	requiredbuilder -y -v -s $CWD $PKG # add "-c -b" if you have binary files in /usr/share
	[ -e install/slack-required ] && cat install/slack-required > $PKG/usr/doc/$PKGNAME-$VERSION/SlackBuild/slack-required
fi

Se il nostro pacchetto genera binari in /usr/share vanno aggiunti anche i parametri -c -b. Se il nostro pacchetto necessita di qualche dipendenza che non può essere intercettata da requiredbuilder perchè non supportata, utilizzare la variabile ADD:

if [ -x "$(which requiredbuilder 2>/dev/null)" ];then
        ADD="$(cd /var/log/packages;ls apache-ant-1*|sed -r 's/apache-ant-/apache-ant >= /')" \
        requiredbuilder -y -v -s $CWD $PKG # add "-c -b" if you have binary files in /usr/share
	[ -e install/slack-required ] && cat install/slack-required > $PKG/usr/doc/$PKGNAME-$VERSION/SlackBuild/slack-required
fi

Creazione pacchetto

Lanciamo makepkg per creare finalmente il nostro pacchetto, che avrà formato: nome-versione-architettura-buildTag.txz evitando gli spazi. Il pacchetto verrà salvato nella stessa directory dello SlackBuild.

/sbin/makepkg -l y -c n $OUTPUT/$PKGNAME-$VERSION-$ARCH-$BUILD$TAG.${PKGTYPE:-txz}

Aggiungiamo la sezione di "cleanup" per permettere, a chi ne avesse voglia, un'installazione senza residui in cartella temporanea.

if [ "$1" = "--cleanup" ]; then
	rm -rf $TMP
fi

basta lanciare lo SlackBuild come:

# ./nomepacchetto.SlackBuild --cleanup

doinst.sh

Il doinst.sh viene utilizzato per effettuare tutte quelle operazioni che provvederanno ad integrare il pacchetto nel resto della distribuzione. Per esempi tipici di doinst.sh vedere la directory /var/log/scripts, che è una raccolta dei doinst.sh di tutti i pacchetti installati sul sistema.

Possibilmente il doinst.sh non dovrebbe venir creato direttamente dentro lo SlackBuild, ma andrebbe messo come file esterno per poi copiarlo nella directory install/. Se poi si necessitasse di aggiungere operazioni di cui non sappiamo a priori le specifiche, ma solo dopo la compilazione, allora possono essere aggiunte dall'interno dello SlackBuild con un ">>".

Nella scrittura di qualunque di questi comandi nel doinst.sh, si raccomanda di fare attenzione agli end-of-line all'ultima riga del file. Alcuni editor non lo inseriscono manualmente. Per verificare editate con vi e controllate se in fondo compare noeol. In tal caso è sufficiente risalvare il file con vi e il problema si risolve. Per essere comunque sicuri, lasciate sempre una riga vuota alla fine del file.

Rinomina file di configurazione .new

Questo forse è l'uso maggiore per cui si crea un doinst.sh. Quando nello SlackBuild abbiamo creato un file tipo etc/configfile.new, il doinst.sh deve provvedere a rinominarlo in etc/configfile a patto che quest'ultimo non esista già sul sistema. Nello script viene definita una funzione, config (da non toccare), che fa questo lavoro.

Al pacchettizzatore è sufficente richiamala con config etc/configfile.new. Utilizzate solo path relativi!

config() {
	NEW="$1"
	OLD="$(dirname $NEW)/$(basename $NEW .new)"
	# If there's no config file by that name, mv it over:
	if [ ! -r $OLD ]; then
		mv $NEW $OLD
	elif [ "$(cat $OLD | md5sum)" = "$(cat $NEW | md5sum)" ]; then
		# toss the redundant copy
		rm $NEW
	fi
}
 
config etc/configfile.new
config etc/program/my.conf.new

Script di start

Per gli script in rc invece va fatta una aggiunta; infatti se un file rc con lo stesso nome già esiste, allora è necessario che abbiano gli stessi permessi. Questo si fa così:

if [ -e etc/rc.d/rc.script ]; then
  cp -a etc/rc.d/rc.script etc/rc.d/rc.script.new.incoming
  cat etc/rc.d/rc.script.new > etc/rc.d/rc.script.new.incoming
  mv etc/rc.d/rc.script.new.incoming etc/rc.d/rc.script.new
fi
 
config etc/rc.d/rc.script.new

Link

Se lo SlackBuild ha creato dei link, con ln o con make install, questi non verranno inseriti nel txz finale. Al posto loro verrà messa nel doinst.sh una riga per ogni link che provvederà a crearlo in fase di postinstallazione. A fare questa operazione ci penserà già makepkg che per ogni link che trova metterà una cosa del genere nel doinst.sh:

( cd usr/bin ; rm -rf view )
( cd usr/bin ; ln -sf vim view )

File icona, menu, .desktop

Quando si installano pacchetti per KDE e/o si aggiungono nuove icone e/o file .desktop ecc. è necessario aggiornare il database di KDE.

if [ -x /usr/bin/update-desktop-database ]; then
  usr/bin/update-desktop-database -q usr/share/applications >/dev/null 2>&1
fi
if [ -x /usr/bin/update-mime-database ]; then
  usr/bin/update-mime-database usr/share/mime >/dev/null 2>&1
fi
if [ -e usr/share/icons/hicolor/icon-theme.cache ]; then
  if [ -x /usr/bin/gtk-update-icon-cache ]; then
    usr/bin/gtk-update-icon-cache usr/share/icons/hicolor >/dev/null 2>&1
  fi
fi

Post-installazione personalizzato

Potrebbe essere necessario avviare qualche script di post-installazione al termine del doinst.sh. Se lo script non si trova nel path, allora solitamente si fa un 'cd directory' e './script'.

Cerchiamo di utilizzare sempre percorsi relativi e mai assoluti perchè se stiamo installando in un chroot allora si rischia di incasinare il sistema principale.

( cd usr/share/programma ; ./postinstall.sh )

Se il postinstall si trova sotto usr/lib, allora dobbiamo inserire questa riga dallo SlackBuild per determinare, dato che non sappiamo a priori se utilizziamo una Slackware a 32 o 64bit e quindi se lo script è in usr/lib o usr/lib64.

echo "( cd usr/lib$LIBDIRSUFFIX ; ./postinstall.sh )" >> $PKG/install/doinst.sh

In caso lo script al suo interno faccia riferimento a percorsi assoluti del sistema, allora dovremo lanciare tale comando in chroot:

chroot . usr/share/programma/postinstall.sh

Aggiunta utenti

Prima del makepkg abbiamo settato tutti i proprietari dei file a root. Se abbiamo qualche pacchetto che richiede di essere avviato come altro utente (p.e. squid) dovremo provvedere a creare l'utente e, se serve, anche il gruppo. Prima dovremo controllare però che tale gruppo già non esista, ergo dovremo utilizzare useradd e groupadd che vanno a modificare i file /etc/passwd ed /etc/group. Si rende quindi necessario il lancio in chroot per evitare che si creino le utenze sul sistema sbagliato:

if ! grep -q "^nomegruppo:" etc/group; then
  chroot . groupadd mygroup &>/dev/null
fi
if ! grep -q "^nomeutente:" etc/passwd; then
  chroot . useradd -d /var/lib/nomeprogramma -s /bin/false -c "Utente programma" -g nomegruppo nomeutente &>/dev/null
fi

Per settare in seguito dei permessi adeguati che abbiamo tolto dallo SlackBuild in precedenza (con chown root.root):

chown -R nomeutente.nomegruppo var/lib/nomeprogramma

Utenti e id

Talvolta si potrebbe volere un determinato uid e gid per utenti e gruppi: uno useradd secco genera un id solitamente alto, che potrebbe confondersi con le utenze classiche mentre i servizi hanno spesso e volentieri id bassi. (Vedi il corrente /etc/passwd) Nel modo seguente è possibile 'tentare' di scegliere un determinato id e, se fallisce, allora ripiegare su un id normale.

if ! grep -q "^apache:" etc/group; then
  if ! grep -q ":80:" etc/group; then
    chroot . groupadd -g 80 apache &>/dev/null
  else
    chroot . groupadd apache &>/dev/null
  fi
fi
 
if ! grep -q "^apache:" etc/passwd; then
  if ! grep -q ":80:" etc/passwd; then
    chroot . useradd -u 80 -d /var/www -s /bin/false -c "Apache User" -g apache apache &>/dev/null
  else
    chroot . useradd -d /var/www -s /bin/false -c "Apache User" -g apache apache &>/dev/null
  fi
fi
chown apache.apache var/www/htdocs

slack-desc

Ecco il template con cui va compilato uno slack-desc. Solitamente sono già disponibili (qui su Slacky.ey, nei pacchetti pre-esistenti oppure su SlackBuilds.org).

La struttura di questo file è molto rigida.

  • Le prime 6 righe sono solo commenti (le istruzioni per costruire lo slack-desc)
  • La riga successiva, la handy-ruler, è un remember sul numero limite di caratteri per riga, questo confine è di 71 caratteri dopo i due punti.
  • La descrizione è fatta di esattamente 11 righe (se ne vuoi di meno basta lasciarle vuote) composte di nomepacchetto, due punti, spazio, descrizione.
  • La riga vuota non prevede lo spazio dopo i due punti.
  • Il nome del pacchetto deve essere esattamente lo stesso indicato in $PKGNAME
 # HOW TO EDIT THIS FILE:
 # The "handy ruler" below makes it easier to edit a package description.  Line
 # up the first '|' above the ':' following the base package name, and the '|' on
 # the right side marks the last column you can put a character in.  You must make
 # exactly 11 lines for the formatting to be correct.  It's also customary to
 # leave one space after the ':'.
 
        |-----handy-ruler------------------------------------------------------|
 pkgname: pkgname - A title for package
 pkgname:
 pkgname: Long description
 pkgname:
 pkgname:
 pkgname:
 pkgname:
 pkgname:
 pkgname:
 pkgname:
 pkgname:

Se il file è stato editato in windows, è probabile che i caratteri "^M" vengano inseriti a fine linea. Se usate vim notereste una dicitura dos in fondo. Altrimenti potete verificarlo con cat -A slack-desc. Per risistemare la situazione lanciare il comando "sed -i -e 's/^M//' slack-desc" in cui ^M non è il carattere ^ e M ma si ottiene premendo prima ctrl+V e poi ctrl+M.

...però noi siamo Slackware-user, quindi vogliamo le cose "ppiùppigre", no? Esiste un comodo script bash che automatizza la scrittura di questi documenti.

Conclusioni

Con tutti gli esempi presentati non si ha pretesa di aver esaurito tutta la casistica, ma dovrebbe essere sufficiente per la stragrande maggioranza dei pacchetti. Per ogni informazione, fare riferimento sempre al forum di Slacky.eu.

--Blallo (discussioni) 08:13, 4 dic 2013 (CET)

Strumenti personali
Namespace

Varianti