Repository 32bit  Forum
Repository 64bit  Wiki

Linee guida per pacchettizzatori Slackware 14.0: differenze tra le versioni

Da Slacky.eu.
(Caricato i file esterni all'interno di wikislacky)
Riga 1: Riga 1:
[[Category:Packages]]
[[Category:Packages]]
= DOCUMENTO IN LAVORAZIONE =
+
= DOCUMENTO DA PERFEZIONARE =
Questa guida vuole definire delle linee da seguire per semplificare la creazione di pacchetti slacky
Questa guida vuole definire delle linee da seguire per semplificare la creazione di pacchetti slacky

Versione delle 19:43, 5 ott 2012


Indice

DOCUMENTO DA PERFEZIONARE

Questa guida vuole definire delle linee da seguire per semplificare la creazione di pacchetti slacky 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 che si troveranno sul repository slacky devono essere compilati su l'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 vuole installarsi particolari programmi che possano invadere le librerie standard (in particolare, per chi usa Slackware64, le multilib di compatibilità a 32bit) o vuole 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 GIA' PRESENTI nel repository, e se non lo sono vanno preventivamente pacchettizzate.

Compilazione multi-arch

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

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

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

(Può essere utile lo Slackware Chroot AutoBuilder al proposito. Qui potete trovare un hack per fare il boot dalla macchina chrootata)

Costituzione di un pacchetto

Per fare un pacchetto slacky abbiamo bisogno di:

Lo slack-required viene generato automaticamente da requiredbuilder.

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:

./categoriadelsoftware/nomedelpacchetto/versionedelpacchetto/<pacchetto.txz>

./categoriadelsoftware/nomedelpacchetto/versionedelpacchetto/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 una wget; per il resto andrebbe inserita una 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. Là dove il software non è scaricabile con una wget ma solo interattivamente (riempimento di un capcha, 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 venga generato sia comunque scritto tale e quale al nome originale, lo stesso vale per lo SlackBuild e lo slack-desc.

I 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 (soprattutto ora che Slacky mette a disposizione i repository per 32 e 64 bit).


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

SlackBuild

  • 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

#!/bin/sh
 
# Heavily based on the Slackware 14.0 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 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 ...

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

# 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, esempio quelle non rilevate da requiredbuilder e quelle che fanno parte degli extra di Slackware oppure le dipendenze necessare solamente per compilare. 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
set -e

parametri di base da modificare. (il tag dovrebbe rimanere sl)

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"
TAR=      # empty = auto
DIR=      # empty = auto
DOCS="AUTHORS COPYING INSTALL TODO TROUBLESHOOTING docs/ ..."
SLKFILES=""

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. EULA. Necessario per i pacchetti proprietari. Non modificare se non necessario.

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

path di lavoro, download e architettura. Non modificare se non necessario. Queste impostazioni dovrebbero essere sufficienti per gran parte del software presente.

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|)$//')}
 
if [ ! -e "$CWD/$TAR" ];then
  wget "$SOURCE" -O "$CWD/$TAR"
fi
 
CHOST="i486"
if [ "$ARCH" = "i486" ]; then
  SLKCFLAGS="-O2 -march=i486 -mtune=i686"
  LIBDIRSUFFIX=""
elif [ "$ARCH" = "i586" ]; then
  SLKCFLAGS="-O2 -march=i586 -mtune=i686"
  LIBDIRSUFFIX=""
elif [ "$ARCH" = "i686" ]; then
  SLKCFLAGS="-O2 -march=i686 -mtune=i686"
  LIBDIRSUFFIX=""
elif [ "$ARCH" = "x86_64" ]; then
  SLKCFLAGS="-O2 -fPIC"
  LIBDIRSUFFIX="64"
  CHOST="x86_64"
fi

anche JOBS, lasciarlo a -j2; se hai bisogno di più parallelismo puoi effettuare l'override da fuori.

preparazione dei sorgenti. Solitamente da modificare solo se hai bisogno di patch o se il tuo sorgente è .zip o ha altre indicazioni speciali.

rm -rf $TMP
mkdir -p $TMP $PKG $OUTPUT
cd $TMP
tar xvf $CWD/$TAR
cd $DIR
 
# patch -p1 < $CWD/some_patch.diff
# zcat $CWD/compressed_patch.diff.gz |patch -p1
 
chown -R root:root .
chmod -R u+w,go+r-w,a-s .

compilazione. Aggiungi i parametri di cui hai bisogno

CFLAGS="$SLKCFLAGS" \
CXXFLAGS="$SLKCFLAGS" \
./configure \
  --prefix=/usr \
  --libdir=/usr/lib$LIBDIRSUFFIX \
  --sysconfdir=/etc \
  --localstatedir=/var \
  --mandir=/usr/man \
  --build=$CHOST-slackware-linux
make $JOBS
make install DESTDIR=$PKG

personalizzazione. (rimozione file, modifiche ecc)

Rinomina quì i file di configurazione e gli rc script e inserisci eventuali altri nuovi file

# 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. copia qualche file di documentazione dai sorgenti. Se hai valorizzato la variabile DOCS e SLKFILES sopra non dovrebbero essere necessarie modifiche, a meno che i sorgenti non abbiano path speciali

mkdir -p $PKG/usr/doc/$PKGNAME-$VERSION
cp -r $DOCS $PKG/usr/doc/$PKGNAME-$VERSION
 
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
done

compressione man pages

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

strip. Strip dei file binari

( 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
)

slack-desc e doinst.sh

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

slack-required e costruzione pacchetto. Lancia requiredbuilder per la gestione delle dipendenze. E' opportuno che questo sia installato nel sistema, ma comunque viene effettuato il controllo di esistenza.

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
 
/sbin/makepkg -l y -c n $OUTPUT/$PKGNAME-$VERSION-$ARCH-$BUILD$TAG.${PKGTYPE:-txz}
 
if [ "$1" = "--cleanup" ]; then
  rm -rf $TMP
fi

ovviamente eliminate tutte le parti che non interessano il vostro pacchetto. Questa è la base. Ogni pacchetto avrà le sue particolarità, ma la struttura dovrebbe comunque rimanere su questa linee. Più in basso trovate i dettagli dei significati delle singole sezione e cosa/come aggiungere o modificare allo script.

doinst.sh

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
  # Otherwise, we leave the .new copy for the admin to consider...
}
#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
#config etc/configfile.new

ovviamente eliminate tutte le parti che non interessano il vostro pacchetto. Se non avete file di configurazione eliminate anche tutta la prima parte. Più in basso trovate i dettagli dei significati delle singole sezione e cosa/come aggiungere o modificare allo script.

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.

slack-desc

# 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:

ricorda... esattamente 11 righe, e l'handy-ruler esattamente 72 caratteri. Dettagli più in basso.

Attenzione ai ^M. Se il file è stato editato in windows, è probabile che questi caratteri 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

Dettagli dei template

Poichè la compilazione dei software opensource nella maggior parte dei casi si compila con un sempilce "./configure&&make&&make install", nella grande maggioranza dei casi, sarà sufficiente effettuare piccole modifiche ai template di cui sopra (nome, versione, url e descrizione) per creare il pacchetto slacky.

Tuttavia quì presentiamo delle linee guida su come modificare i template per adattarlo ai pacchetti in cui non è sufficiente il template base.

Non potrò esaurire quì tutta la caseistica e la problematica che si può presentare, ma quanto descritto dovrebbe essere sufficiente per un buon numero di pacchetti.

SlackBuild

intestazione

  • La shell da utilizzare è sempre /bin/sh
  • Specificare per quale versione di slackware è scritto lo SlackBuild
  • L'autore dello SlackBuild. Potete mettere il nome o il nick, ma come contatto possibilmente mettete un indirizzo email (mio <at> indir.email)
  • 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.0 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://......
 
# 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: GConf and ORBit2 from slackware*/extra/

parametri di base

La seguente sezione è quella che contiene i parametri base, cioè il nome del pacchetto, la versione, l'architettura, la build version e l'url diretto da dove scaricare i sorgenti. Per quanto riguarda il BUILD, la norma è che ad ogni modifica del pacchetto, ricompilazione ecc, il numero va incrementato, mentre all'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= . Spesso funziona anche senza ma in qualche caso può succedere un casino. 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}.

set -e
 
PKGNAME=appname
VERSION=${VERSION:-1.4.1}
BUILD=${BUILD:-1}
TAG=${TAG:-sl}
ARCH=${ARCH:-i486}

Nel nuovo template il nome del tar file 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.

SOURCE="http://downloads.sourceforge.net/project/......./${PKGNAME}-${VERSION}/${PKGNAME}-${VERSION}.tar.gz"
TAR=      # empty = auto
DIR=      # empty = auto

In caso una di queste due asserzioni non è vera, non è necessario andare a modificare tutto il resto dello SB (if [ ! -e , wget, tar, cd, eventuale altre parti), ma è sufficente modificare le variabili TAR e DIR.

SOURCE="http://downloads.sourceforge.net/project/......./${PKGNAME}/${PKGNAME}_${VERSION}.tar.bz2?download"
TAR=${PKGNAME}_${VERSION}.tar.bz2      # empty = auto
DIR=${PKGNAME}${VERSION}               # empty = auto

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

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|)$//')}

download

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

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

CHOST="i486"
if [ "$ARCH" = "i486" ]; then
  SLKCFLAGS="-O2 -march=i486 -mtune=i686"
  LIBDIRSUFFIX=""
elif [ "$ARCH" = "i586" ]; then
  SLKCFLAGS="-O2 -march=i586 -mtune=i686"
  LIBDIRSUFFIX=""
elif [ "$ARCH" = "i686" ]; then
  SLKCFLAGS="-O2 -march=i686 -mtune=i686"
  LIBDIRSUFFIX=""
elif [ "$ARCH" = "x86_64" ]; then
  SLKCFLAGS="-O2 -fPIC"
  LIBDIRSUFFIX="64"
  CHOST="x86_64"
fi

preparazione dei sorgenti

Segue la:

  • rimozione di una compilazione precedente
  • scompattazione dei sorgenti
  • applicazione di eventuali patch; queste devono essere presenti nella stessa directory dello SlackBuild e possono essere facoltativamente compresse.
  • settaggio dei permessi. E' 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
 
# patch -p1 < $CWD/some_patch.diff
# zcat $CWD/compressed_patch.diff.gz |patch -p1
 
chown -R root:root .
chmod -R u+w,go+r-w,a-s .

compilazione

Comincia la compilazione. Nella maggior parte dei casi utilizzeremo lo standard ./configure&&make&&make install.

Per quanto ri guarda 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 successivamente.
  • I dati andrebbero messi in /var/nomepacchetto o /var/lib/nomepacchetto, a seconda del pacchetto. P.E. 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 mette correttamente --libdir=/usr/lib$LIBDIRSUFFIX e sopra viene definito LIBDIRSUFFIX a seconda dell'architettura. 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" per ottimizzare la velocità, e altro), non viene più messo all'interno dello SlackBuild, ma si utilizza una variabile standard di make: MAKEFLAGS. Il MAKEFLAGS viene specificato fuori dello slackbuild per consentire al pacchettizzatore di passare parametri al comando 'make'. Per esempio MAKEFLAGS="-j2" bash pacchetto.SlackBuild
CFLAGS="$SLKCFLAGS" \
CXXFLAGS="$SLKCFLAGS" \
./configure \
  --prefix=/usr \
  --libdir=/usr/lib$LIBDIRSUFFIX \
  --sysconfdir=/etc \
  --localstatedir=/var \
  --mandir=/usr/man \
  --build=$CHOST-slackware-linux
make
make install DESTDIR=$PKG

cmake

Alcuni pacchetti per essere compilati necessitano di cmake anzichè ./configure. In tal caso valgono comunque tutte le considerazioni fatte sopra, ma la sintassi è diversa:

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

personalizzazione

Le sezioni che seguono sono quelle che probabilmente più dovrete personalizzare. Quì 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

Inoltre copiamo tutta la documentazione che riusciamo a trovare nei sorgenti del pacchetto (README, INSTALL, ChangeLog, ecc..) nella directory della documentazione. Nella stessa directory ci metteremo anche lo SlackBuild con cui è stato generato il pacchetto e slack-desc. Il template tenta di trovare automaticamente qualche file di documentazione, così non è solitamente necessario modificare questa parte di SlackBuild.

mkdir -p $PKG/usr/doc/$PKGNAME-$VERSION
cp -r \
  [A-Z]* doc/ docs/ readme* install.txt \
  $PKG/usr/doc/$PKGNAME-$VERSION
 
cat $CWD/$PKGNAME.SlackBuild > $PKG/usr/doc/$PKGNAME-$VERSION/$PKGNAME.SlackBuild
cat $CWD/slack-desc > $PKG/usr/doc/$PKGNAME-$VERSION/slack-desc

Lo standard di slackware è che tutte le manpages siano compresse con gzip; di conseguenza cerchiamo versioni non compresse che installano i pacchetti e comprimiamole.

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

strip

Puliamo anche i file binari e le librerie eliminando tutti gli strascichi che lascia gcc al fine di debuggure 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
)

slack-desc e doinst.sh

Abbiamo quasi finito... Popoliamo la directory install/ del pacchetto. Quì ci andrà lo slack-desc e, se necessario, il doinst.sh. Con l'attuale template non è più necessario aggiungere manualmente la riga del doinst, perchè viene cercato e copiato solo se esiste. Quindi non eliminiamo tale linea.

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

Possibilmente il doinst.sh non lo creiamo direttamente dentro lo SlackBuild, ma mettiamolo come file esterno per poi copiarlo nella directory install/. Se poi abbiamo bisogno di aggiungere operazioni di cui non sappiamo a priori le specifiche, ma le sappiamo solo dopo la compilazione, allora aggiungiamole da dentro lo SlackBuild con un >>. Un esempio di operazione necessaria è quella di avviare uno script di postinstallazione presente sotto la /usr/lib; ovviamente non sappiamo a priori se sarà in /usr/lib o /usr/lib64.

[ -e $CWD/doinst.sh ] && cat $CWD/doinst.sh > $PKG/install/doinst.sh
echo "( cd usr/lib$LIBDIRSUFFIX/$PKGNAME ; ./postinstall.sh )" >> $PKG/install/doinst.sh

slack-required

Ora andiamo a costruire il file delle dipendenze slack-required. Questo si genera con il tool requiredbuilder. Ricordiamoci di installare sempre l'ultima versione di questo tool prima di compilare. Dovremo anche assicurarci che i file del pacchetto siano tutti di root, poi lanciamo il requiredbuilder per costruire le dipendenze e finalmente creiamo il pacchetto.

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 
fi

Se il nostro pacchetto genera binari in /usr/share aggiungiamo anche il -c -b come parametri perchè per default non vengono cercate dipendenze su questo path.

costruzione pacchetto

Finalmente abbiamo finito. Possiamo costruire il nostro pacchetto.

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

Se poi il pacchettizzatore è sicuro che andrà tutto a buon fine, si può decidere di lanciare lo slackbuild con il parametro --cleanup per rimuovere le directory di lavoro al termine del processo.

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

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 vedi la directory /var/log/scripts che è una raccolta dei doinst.sh di tutti i pacchetti installati sul sistema.

Ecco alcuni usi:

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 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 i 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
  # Otherwise, we leave the .new copy for the admin to consider...
}
 
config etc/configfile.new
config etc/program/my.conf.new

gli 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

i 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à 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 )

quindi di questo non dovremo preoccuparci

file icona, menu, .desktop ecc

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 personalizzata

Potrebbe essere necessario avviare qualche script di postinstallazione al termine del doinst. 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 (come spiegato all'inizio dell'articolo) 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 perchè 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

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 già non esista. Ovviamente dovremo utilizzare useradd e groupadd che vanno a modificare l'/etc/passwd e l'/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

e poi settare i permessi adeguati, permessi che abbiamo tolto dallo slackbuild 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

Questo è più semplice. Si tratta di mettere una descrizione del pacchetto di un massimo di 11 righe e un massimo di 72 caratteri per riga. Personalmente prendo qualche riga dal README o dal sito ufficiale e lo copio lì dentro. Come esempi di descrizione si possono prendere tutti quelli di slackware.

La struttura di questo file è molto rigida. Le prime 6 righe sono solo commenti (le istruzioni per costruire lo slack-desc, ma vanno lasciate. 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

Non deve essere inserito il nome del pacchettizzatore né l'url del programma.

# 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 Long description Long description Long description
pkgname: Long description Long description Long description Long description
pkgname:
pkgname:
pkgname:
pkgname:
pkgname:
pkgname:
pkgname:

Conclusioni

Con tutti gli esempi presentati non pretendo di aver esaurito tutta la casistica, ma dovrebbe essere sufficiente per molti pacchetti.

Strumenti personali
Namespace

Varianti