Table des matières

Le guide du SlackBuild


Introduction

Cette guideline ou “ligne de conduite” a été réalisée dans le but d'uniformiser un minimum les SlackBuilds créés par les différents contributeurs de ce site en posant des règles de base obligatoires. Ces principes de base servent avant tout à créer des SlackBuilds qui généreront (normalement ;-)) des packages à la fois de qualité et à la fois respectant la “philosophie Slackware”.
La syntaxe shell utilisée est laissée au choix du créateur de SlackBuild, sauf indication contraire, tant que le résultat recherché est le même. Prenez cependant l'habitude de faire des SlackBuilds clairs, commentés (mais pas trop), et pas trop complexes (un débutant ne doit pas trop avoir de mal à comprendre ce que fait votre SlackBuild en le lisant).
Les principes ci-dessous sont énumérés dans la mesure du possible dans un ordre à priori logique, en suivant l'ordre du SlackBuild d'exemple.
Enfin, il est vivement conseillé de lire la FAQ en plus de ce document qui apporte de nombreuses précisions non abordées ici.


Les principes de base (obligatoires) des SlackBuilds de Slackbuilds.net (contributions comprises)


L'indication des prérequis

Si le succès de la compilation du logiciel que vous packagez dépend d'une ou plusieurs applications (ou bibliothèques) qui ne sont pas incluses dans Slackware, vous devez le signaler au début de votre Slackbuild en utilisant la syntaxe suivante : 

# Depends: ap/logiciel1, d/logiciel2, l/bibliothèque1

Si l'application que vous packagez peut proposer des fonctionnalités supplémentaires dans le cas où certains logiciels tiers sont présents lors de la compilation, vous pouvez le signaler par cette en-tête : 

# Suggests: ap/logiciel1, d/logiciel2, l/bibliothèque1

Cette syntaxe simple - la liste des applications requises ou suggérées, séparées par des virgules - est imposée afin de permettre un traitement automatisé de ces informations par d'éventuels scripts d'installation.

NB : afin de faciliter le traitement (hypothétique, rien n'existe à ce jour) de cette liste par des logiciels tiers, veillez à ne pas ajouter aucun autre commentaire sur ces lignes.

Bien entendu, si votre SlackBuild ne nécessite rien de particulier, ces en-têtes peuvent être omises.


Les variables

Les variables sont libre de choix. Cependant, quelques variables communes obligatoires ont été définies. Leur syntaxe particulière permet à l'utilisateur de les modifier sans éditer le SlackBuild car elles sont de la forme VARIABLE=${VARIABLE:-ValeurParDefaut} Les voici : 

VERSION=${VERSION:-1.0} # version du logiciel telle que sur le tarball
BUILD=${BUILD:-1PKG} # version du slackbuild
ARCH=${BUILD:-i486} # architecture matérielle
TMP=${TMP:-/tmp} # dossier de travail
OUT=${OUT:-$TMP/build} # dossier où sera placé le package

Notez que les valeurs par défaut de ARCH, TMP et OUT sont obligatoires (en l'occurence i486 pour ARCH, /tmp pour TMP et $TMP/build pour OUT). Bien évidemment, il vous faudra adapter les valeurs par défaut des variables VERSION et BUILD selon le logiciel.

On peut grâce à cette “interface” facilement redéfinir le dossier de travail de la manière suivante : 

TMP=~/tmp source application.SlackBuild

Attention 

TMP=~/tmp sh application.Slackbuild

Ce code, à l'apparence similaire, ne marchera pas comme vous le souhaitez… Ici, sh instancie un nouveau shell ; en plaçant la redéfinition de variable avant son invocation, la variable sera redéfinie dans le shell courant, mais pas dans celui qui exécutera le Slackbuild. source, en revanche, utilise le shell courant, donc le problème ne se pose pas. Les commandes sh et source permettent toutes deux de lancer le script même s'il n'a pas le bit exec.


Le options d'optimisations

Passez au ./configure les options d'optimisation de gcc, en incluant par exemple le code suivant : 

ARCH=i486
 
if [ "$ARCH" = "i386" ]; then
   CPUOPT="-O2 -march=i386 -mtune=i686"
elif [ "$ARCH" = "i486" ]; then
   CPUOPT="-O2 -march=i486 -mtune=i686"
elif [ "$ARCH" = "i586" ]; then
   CPUOPT="-O2 -march=i586 -mtune=i686"
elif [ "$ARCH" = "i686" ]; then
   CPUOPT="-O2 -march=i686 -mtune=i686"
elif [ "$ARCH" = "s390" ]; then
   CPUOPT="-O2"
elif [ "$ARCH" = "x86_64" ]; then
   CPUOPT="-O2"
fi
 
CFLAGS=$CPUOPT CXXFLAGS=$CPUOPT

Remarque : La dernière ligne est à mettre sur la même ligne que le ./configure… si on veut mettre cette ligne à part comme ici, il faut exporter ces variables avec export avant.

Attention pkgtool, le gestionnaire de packages de Slackware, ne gère pas correctement les dénominations d'architecture comportant un tiret (e.g athlon-xp) dans les noms de package. Veillez donc à éviter d'utiliser tels quels ces architectures dans le nom de vos packages.


Le slack-desc

Vous devez fournir une description appropriée pour le logiciel que vous packagez, afin qu'une fois installé il soit facilement identifiable depuis pkgtool.

Sous Slackware, la description d'un package suit un format particulier ; elle doit être contenue dans un fichier nommé slack-desc, placé dans un dossier install/ à la racine du package.

Ce fichier slack-desc a une syntaxe particulière respectée par tous les packages Slackware : 

        |-----handy-ruler------------------------------------------------------|
logiciel: logiciel (description courte)
logiciel:
logiciel: Description longue, généralement inspirée du README, ou de la présen-
logiciel: tation du logiciel sur le site officiel du projet.
logiciel: Notez l'espace entre les ':' et le début de la ligne, que vous devrez
logiciel: vous aussi laisser. De même, vous ne devez pas dépasser le 'handy ru-
logiciel: ler', qui doit être calé sur les ':' et indique la fin de ligne.
logiciel: Même si la description est courte, vous devez laisser les 11 lignes.
logiciel: NB: vous devrez remplacer 'logiciel' par le nom _exact_ de votre
logiciel: package, sinon la description ne sera pas visible.
logiciel:

Vous pouvez alternativement inclure le slack-desc dans le corps de votre Slackbuild en utilisant la syntaxe shell here document : 

cat << 'EOF' > $PKG/install/slack-desc
        |-----handy-ruler------------------------------------------------------|
logiciel: logiciel (description courte)
logiciel:
logiciel: Description longue (rappelez-vous, les onze lignes sont obligatoires)
logiciel: 
logiciel: 
logiciel: 
logiciel: 
logiciel: 
logiciel: 
logiciel: 
logiciel:
EOF

Si vous procédez de la sorte, vous pourrez toujours extraire facilement le texte du slack-desc en utilisant la commande sed suivante: 

sed -n '/handy-ruler/,/EOF/{s/^.*handy-ruler.*//;x;p;D;}' logiciel.Slackbuild


Le doinst.sh

Vous pouvez être amené à fournir un fichier doinst.sh selon le logiciel que vous packagez. Ce point est détaillé dans la FAQ.


La documentation


if [ -d $PKG/usr/man ]; then
  ( cd $PKG/usr/man
    for manpagedir in $(find . -type d -name "man*") ; do
      ( cd $manpagedir
        for eachpage in $( find . -type l -maxdepth 1) ; do
          ln -s $( readlink $eachpage ).gz $eachpage.gz
          rm -f $eachpage
        done
        gzip -9 *.?
      )
    done
  )
fi


if [ -d $PKG/usr/info]; then
  rm -f $PKG/usr/info/dir
  gzip -9 $PKG/usr/info/*.info*
fi


Les derniers paufinement avant l'empaquetage

Les exécutables (binaires) et les bibliothèques partagées doivent être “strippés”, c'est-à-dire épurés de leurs symboles de debug (entraîne une empreinte mémoire plus faible et des packages plus petits notamment). Exemple de code : 

# Pour les binaires exécutables
find $PKG | xargs file | grep "ELF 32-bit LSB executable" | cut -f 1 -d : | xargs strip --strip-unneeded 2> /dev/null || true
# Pour les bibliothèques partagées
find $PKG | xargs file | grep "shared object" | cut -f 1 -d : | xargs strip --strip-unneeded 2> /dev/null || true


L'empaquetage
PACKAGING="
chown root:root . -R
/sbin/makepkg -l y -c n ../$NAMETGZ-$VERSION-$ARCH-$BUILD.tgz
rm -rf $PKG
rm -rf $TMP/$NAME
"
if type -p fakeroot ; then
   echo "$PACKAGING" | fakeroot
else
   su -c "$PACKAGING"
fi




Facultatif mais recommandé







1) Note de _Hitek_ : personnellement, je refais la somme sha1 pour chaque tarball de sources avec l'aide d'un simple script pour une meilleure cohérence et être certain que tous les tarballs ont leurs sommes de contrôles d'intégrité car le but n'est pas vraiment ici de tester l'intégrité des sources dans un soucis de sécurité mais d'être sûr que l'archive a été correctement téléchargée
2) Voici le script en question : 
for i in $(find . -name *.tgz) ; do j=`echo $i | awk -F/ '{ print $2 }'` ; sha1sum $i > $i.sha1 ; done
for i in $(find . -name *.tar.gz) ; do j=`echo $i | awk -F/ '{ print $2 }'` ; sha1sum $j > $j.sha1 ; done
for i in $(find . -name *.tar.bz2) ; do j=`echo $i | awk -F/ '{ print $2 }'` ; sha1sum $j > $j.sha1 ; done