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
  • Les fichiers de documentations ou de licences tels que les AUTHORS COPYING README FAQ ChangeLog TODO etc doivent être placés dans le répertoire /usr/doc/NomLogiciel-VersionLogiciel (pour voir des d'exemples, faites un tour dans /usr/doc ;-))


  • Les pages man et info doivent être compressées avec gzip (et uniquement gzip). Exemple de code pour la compression des pages man :
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


  • Vous devez supprimer tout fichier /usr/info/dir afin de ne pas écraser celui fournit par le package textinfo. Exemple de code :
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
  • Le SlackBuild doit être exécutable en utilisateur non root avec l'aide de fakeroot, mais doit proposer une alternative pour les utilisateurs ne disposant pas de fakeroot ou ne voulant pas l'installer. Exemple de code pour la partie normalement exécutée en root dans un SlackBuild (partie de création du package et définition des bons droits) :
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


  • Le package final doit se retrouver dans /tmp/build


  • La convention veut que le nom d'un package Slackware soit en minuscules ; l'auteur du build peut cependant être en majuscules. Exemple de nom correct : monsoft-version-i486-1PKG.tgz - Notez les majucules qui représentent l'auteur du package (qui peut cependant être en minuscules bien évidemment).


Facultatif mais recommandé


  • Il est conseillé de mettre une licence (impérativement libre si vous distribuez votre SlackBuild sur ce site) sur son travail, au choix. Elle doit être indiquée en début de script en commentaire. Par exemple :
    # Ce script est sous licence CeCILL dans sa version 2 et supérieure visible à http://www.cecill.info/licences/Licence_CeCILL_V2-fr.txt


  • Il est recommendé d'insérer en entête de votre SlackBuild la page du projet du logiciel compilé. Exemple :
    # Latest Logiciel sourcecode is available at:
# http://logiciel.sourceforge.net


  • Il est recommendé de placer un wget pour récupérer les sources du logiciel à compiler afin de faciliter la vie de l'utilisateur. Exemple de code :
    if [ ! -r $NAMESRC-$VERSION.$EXT ]; then
   wget ftp://ftp.gnome.org/pub/gnome/sources/$NAMESRC-$VERSION.$EXT
fi


  • Comme vu précédemment, un SlackBuild ne doit pas être lancé en root, dans la mesure du possible. Exemple de vérification à faire :
    if [ $UID -eq 0 ]; then
   echo "Ne pas exécuter en tant qu'utilisateur ROOT !"
   exit 1
fi


  • Vérifiez si le repertoire de travail existe avec une condition :
    if [ ! -d $TMP ]; then
   echo "$TMP n'existe pas ou n'est pas un répertoire !"
   exit 1
fi


  • Distribution du SlackBuild : si c'est sur un forum, un copier/coller du fichier.SlackBuild, de son slack-desc et de tout fichier jugé nécessaire fera l'affaire. Il vous faudra utiliser les balises [code] [/code].
    Si c'est en tarball, préférez empaqueter un répertoire contenant le fichier.SlackBuild, le slack-desc, éventuellement le doinst.sh et tout autres fichiers nécessaires (patches etc). Joignez avec le tarball les fichiers de signature sha1 (et/ou md5) du tarball ainsi que sa signature GPG ; ça fera donc 3 fichiers à uploader.
    tar cjvf nom-version_Slackbuild.tar.bz2 repertoire-contenant-les-2-fichiers_précités
sha1sum nom-version_Slackbuild.tar.bz2 > nom-version_Slackbuild.tar.bz2.sha1
gpg --armor --detach-sign ${NAMEARCH}_SlackBuild.tar.bz2


    Remarque : Il faut avoir préalablement créé une clé GPG. Tutorial GPG
    Remarque : Joignez les signatures et sommes seulement si le tarball ou le SlackBuild contient déjà les sommes des sources par exemple.1)2)

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

Outils personnels