Vous êtes ici: La documentation de Slackware-fr » Les slackbuilds » Slackware, les SlackBuilds : Questions fréquemment posées

Slackware, les SlackBuilds : Questions fréquemment posées

Comment installer un logiciel sous Slackware GNU/Linux ?

Sous Slackware, comme dans de nombreuses autres distributions, il est possible d'installer un nouveau logiciel de deux manières différentes.

On peut chercher une archive contenant toutes les données de l'application prêtes à être utilisées, appelée package, et l'installer via le package manager de la distribution. Dans le cas de Slackware, les packages sont des archives .txz (anciennement .tgz) qu'on peut installer avec les outils en ligne de commande pkgtool ou installpkg. Plus simplement, on peut aussi utiliser le gestionnaire de paquet “en ligne” slackpkg (comprendre, qui télécharge automatiquement les paquets)

On peut également installer un logiciel en compilant les fichiers sources disponibles sur le site du projet. C'est parfois le seul moyen d'installer un logiciel, comme dans le cas du codec Xvid ou de deCSS, pour lesquels une distribution sous forme de package est illégale dans certains pays, ou d'applications encore aux premières phases de leur développement.

Les sources se présentent sous la forme d'archives .tar.gz ou .tar.bz2, qu'on appelle communément 'tarball'.

D'accord, mais où interviennent les Slackbuilds dans tout ça ?

Les Slackbuilds sont de simples fichiers textes contenant une suite d'instructions en ligne de commande (script shell) permettant de construire un package à partir des sources.

Pourquoi ne pas simplement faire le fameux ./configure && make && make install ?

Vous l'apprendrez probablement tout seul à vos dépens si vous utilisez cette méthode, mais c'est une pratique extrèmement “sale”. Elle ne permet pas de désinstaller facilement le logiciel, donc en cas de mise à jour, les résultats seront hasardeux.

Certains objecteront qu'il est possible d'utiliser la commande 'make uninstall' pour désinstaller un logiciel installé de cette manière. En effet, certains systèmes de compilation incluent la cible 'uninstall' ; mais ce procédé n'est pas forcément exempt d'erreurs, c'est à dire que le Makefile peut parfaitement 'oublier' de supprimer des fichiers. Bien malin celui qui parviendra à les débusquer ensuite. Cette méthode oblige également à garder l'intégralité des sources *originales* sous la main (des sources plus récentes pouvant ne plus comporter l'option 'uninstall', ou avoir des résultats différents).

Bref, en procédant de la sorte, vous parsemez votre système de fichiers orphelins qui resteront à moisir dans les recoins reculés de votre disque dur. L'utilisation de packages résout tous les problèmes exposés ici ; cela demande un tout petit peu plus de travail, mais en retour vous conserverez un système propre.

Je suis propre moi, j'utilise Checkinstall.

Checkinstall est - grossièrement - une surcouche à 'make install' qui permet de packager automatiquement les fichiers normalement installés par cette commande, mais il ne marche décemment qu'avec des systèmes de compilation “raisonnables”.

Dans le cas malheureusement encore assez courant où le Makefile ne gère pas l'option DESTDIR, Checkinstall réalisera un package vide, mais les fichiers seront installés quand même (exemple: xmbmon). Vous perdez alors tout l'avantage d'utiliser des packages.

Checkinstall ne permet pas non plus de corriger l'emplacement des fichiers ou leurs permissions si le système de compilation est incorrect ; cela peut être à l'origine de problèmes de sécurité, ou simplement ennuyeux si 'make install' est fantaisiste et installe les fichiers à des endroits surprenants.

D'accord, mais ce ne serait pas plus simple d'utiliser un package non officiel, alors ?

Il existe effectivement des dépôts de packages, comme http://linuxpackages.net, qui proposent des packages tout faits pour une myriade de logiciels.

Cependant, s'il est très simple de télécharger et d'installer un package, rien ne garantit qu'il fonctionnera correctement sur votre machine ; tout simplement car le packageur n'a probablement pas la même que la vôtre, et qu'il a peut-être inclus des fonctionnalités qui ne marcheront pas chez vous.

Si le Slackbuild crée aussi un package, quel est l'avantage sur un package tout fait ?

Le package produit par le Slackbuild aura été compilé sur votre machine et par conséquent sera automatiquement adapté à votre configuration.

D'autre part, l'utilisation de Slackbuilds peut vous permettre de personnaliser l'installation du logiciel, ou d'installer une nouvelle version sans attendre qu'un packageur la compile pour vous. Rien non plus ne vous empêche de voir comment le logiciel est préparé, contrairement aux packages tout faits ; il n'y a en effet aucun moyen de savoir comment un package a été conçu sans disposer de son Slackbuild.

Avec les Slackbuilds, le packageur c'est vous.

OK, ça m'intéresse. Comment je fais ?

Nous proposons un certain nombre de Slackbuilds éprouvés sur notre site. Si votre logiciel en fait partie, il vous suffit de télécharger l'archive .tar.bz2 correspondante. Les fichiers .md5, .sha1 et .asc permettent de vérifier l'intégrité de l'archive, nous reviendrons là dessus plus tard.

Une fois l'archive téléchargée, décompressez-la avec ark, ou en ligne de commande: tar xf nom_du_logiciel.tar.bz2

Un dossier portant le nom et la version du logiciel pour lequel le Slackbuild a été conçu sera créé dans le répertoire de travail. Ce dossier contient le Slackbuild prêt à l'emploi.

Alternativement, vous trouverez des Slackbuilds en cours de test sur le forum. Il suffit généralement de les copier/coller dans un nouveau fichier. Rappelez vous que les Slackbuilds postés sur le forum sont en test et ne sont donc pas forcément exempts de bugs ; si vous en rencontrez un, signalez-le à l'auteur du script.

Pour créer le package, vous devez ensuite lancer le Slackbuild de la manière suivante: sh nom_de_l'application.Slackbuild

Quand tout est terminé, vous trouverez le package final dans le dossier /tmp/build. Vous pourrez alors l'installer comme un package ordinaire, et utiliser l'application.

Hmm, qu'est-ce que c'était toutes ces lignes qui ont défilé quand je l'ai lancé ? La ligne de commande, ça a l'air compliqué.

Installer un logiciel à partir d'un de nos Slackbuild reste cependant très simple, comme vous avez pu le constater.

La ligne de commande de GNU/Linux est un outil très puissant, et les Slackbuilds peuvent être un excellent moyen de s'y initier, puis de la dompter.

Les Slackbuilds étant de simples fichiers textes, rien ne vous empêche d'étudier les Slackbuilds de vos logiciels favoris, de les modifier, et même de créer les vôtres par la suite pour d'autres logiciels.

Bref, en apprenant à faire des Slackbuilds, vous aurez la liberté d'installer tout ce qu'il vous plaît, et vous vous familiariserez rapidement avec la ligne de commande.

Hmm, en parlant d'installation... où est-on censé installer les différents composants d'un logiciel sous Slackware ?

Slackware GNU/Linux suit les conventions Unix pour son arborescence. En règle générale, vous devez placer :

  • les exécutables dans /usr/bin
  • les bibliothèques dans /usr/lib
  • les données statiques spécifiques à l'application dans /usr/share/nom_de_l'application
  • la documentation de l'application dans /usr/doc/nom_de_l'application-version
  • les pages de man dans /usr/man (et non pas /usr/share/man !).

Le choix de tous ces chemins est généralement automatisé par les systèmes de build décents en utilisant les commandes :

./configure --prefix=/usr
# ou en l'absence de script configure:
make PREFIX=/usr

Si l'application que vous packagez ne dispose ni d'un script configure, ni d'un Makefile raisonnable, vous serez peut-être amené à placer vous même les fichiers au bon endroit…

C'est bien gentil tout ça, mais moi je veux packager une application système complexe.

Si vous souhaitez packager une application système, comme un serveur mail ou un daemon quelconque, vous devrez également vous soucier des conventions suivantes (il y a fort à parier que vous les connaissez déjà, vu votre objectif…):

  • les exécutables systèmes *critiques* (comme les outils de systèmes de fichier) dans /sbin
  • les exécutables systèmes (typiquement, votre daemon) dans /usr/sbin
  • les données relatives au fonctionnement du service dans /var
  • la configuration dans /etc

Vous ne devriez rien avoir à ajouter dans /bin ni dans /lib (commandes essentielles)

Vous pouvez spécifier ces contraintes à un script configure de la manière suivante :

./configure --sysconfdir=/etc/mon_daemon --localstatedir=/var

Le système de build en tiendra peut-être compte… :-)

Si vous installez un serveur, les scripts de démarrage se placent dans /etc/rc.d

Slackware suivant la convention BSD pour les scripts de démarrage, vous devez placer un unique script répondant aux commandes start, stop, et restart dans ce dossier. Ce script devra être appelé par un des trois scripts principaux (rc.S → rc.M → rc.local).

Les scripts rc.S et rc.M étant réservés pour l'initialisation de Slackware, il est conseillé d'ajouter le lancement de votre script à rc.local.

La seule façon d'activer ou non votre script au démarrage est de contrôler son bit exec :

if [ -x /etc/rc.d/rc.mon_serveur ]; then
    # démarre le service
    /etc/rc.d/rc.mon_serveur start
fi

Pour arrêter proprement votre serveur, vous pouvez ajouter de manière similaire les commandes suivantes au fichier /etc/rc.d/rc.local_shutdown (appelé automatiquement à l'arrêt par le script systèmes rc.6) :

if [ -x /etc/rc.d/rc.mon_serveur ]; then
    # arrête le service
    /etc/rc.d/rc.mon_serveur stop
fi

N'oubliez pas que vous êtes sous Slackware, une distribution simple et efficace ; il est donc malvenu d'ajouter des effets tape-à-l'oeil à vos scripts, comme colorer les voyelles en rouges et les consonnes en vert, ou plus prosaïquement d'afficher les OK ou KO chatoyants qu'affectionnent d'autres distributions.

À propos de ces scripts de démarrage, comment éviter d'écraser les modifications que l'utilisateur y a peut-être apporté ?

Vous pouvez pour cela utiliser le script doinst.sh.

Important : doinst.sh ? qu'est-ce que c'est ?

Si vous ajoutez un script nommé doinst.sh au dossier install à la racine de votre package, il sera automatiquement lancé par pkgtool à la fin de l'installation du package.

On peut lui trouver de nombreuses applications créatives, comme initialiser proprement l'environnement de travail du daemon, ou lancer un fc-cache après l'installation d'une police - mais n'oubliez pas, sobriété est le maître mot sous Slackware.

Cet ingénieux script vous permet donc d’éviter de remplacer le script de lancement déjà présent sur le système de l’utilisateur s'il y a apporté des modifications, de la façon suivante :

cat << 'EOF' > $PKG/install/doinst.sh
#! /bin/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...
}
config etc/rc.d/rc.mon_daemon.new
 
# Makepkg handles symlinks below...
EOF

En nommant votre script de lancement rc.mon_daemon.new dans votre package et en utilisant ce doinst.sh, un rc.mon_daemon existant ne sera pas remplacé. Par contre, s'il n'existe pas déjà, le vôtre sera installé en tant que rc.mon_daemon.

Dans le cas d'un script modifié, votre utilisateur sera libre de voir les modifications que vous avez effectuées dans votre nouveau script et de les ajouter à celui qu'il utilise.

Le script doinst.sh est comme on l'a vu un outil fort commode, mais il peut également constituer une menace sérieuse ; ce script étant exécuté automatiquement en tant qu'utilisateur root lors de l'installation du package qui le contient, il a le pouvoir d'endommager gravement l'intégralité du système.

En tant que packageur, vous devez donc le concevoir avec le plus grand soin, de sorte à ce qu'il ne puisse pas détériorer le système de vos utilisateurs.

En tant qu'utilisateur, si vous installez un package tiers, vous devriez contrôler le contenu de ce script afin de vérifier qu'il ne contient pas de code involontairement dangereux ou franchement malveillant.

J'ai beaucoup appris, Sensei ! Je peux faire des Slackbuilds aussi, maintenant !

Longue est la voie de l'excellence, petit scarabée :-)

Afin que les Slackbuilds que nous proposons puissent être utilisés en toute confiance, nous demandons aux contributeurs de bien vouloir respecter deux critères de qualité principaux :

  • Respect du système des utilisateurs. Ce respect se témoigne par trois mesures essentielles :
    1. votre Slackbuild doit pouvoir être exécuté en tant qu'utilisateur non privilégié, afin de ne pas risquer d'endommager leur système. L'erreur est humaine.
    2. votre Slackbuild doit être simple. Il ne doit pas dépendre d'applications spécifiques, dans la mesure du possible. Il doit s'installer dans les même dossiers qu'un package Slackware officiel, afin que l'utilisateur n'ait pas à chercher où se trouve l'application.
    3. votre package ne doit pas être inutilement encombrant/lent. Compressez les pages de man, strippez les binaires : celui qui utilisera votre script n'aura peut-être pas autant d'espace disque que vous. De même, optimisez la compilation pour ceux qui ont des machines moins puissantes.
  • Lisibilité et transparence :
    Nous vous faisons confiance, mais nous devons pouvoir vérifier ce que fait votre script, et le comprendre facilement. Si votre script est obscur, les autres membres seront génés s'ils souhaitent le modifier ou simplement étudier son fonctionnement. Efforcez-vous donc de commenter ce que fait votre Slackbuild dans la mesure du possible.
    De même, veillez à installer la documentation du logiciel si c'est possible, et donnez une description explicite à vos packages.

Si vous respectez ces critères, les membres qui utiliseront vos Slackbuilds bénéficieront de la même qualité dont vous avez vous-même profité, et pourront s'ils le désirent suivre le même chemin que vous.

Pour vous aider, nous avons élaboré un Slackbuild type, tenant compte de toutes ces recommandations. Vous pouvez le trouver ici : SlackBuild générique
Cela peut être un bon départ pour concevoir les vôtres.

Des recommandations concrètes sur l'élaboration d'un Slackbuild de bonne facture ont également été rassemblées sous la forme de Guidelines (ligne de conduite) ici : Guide du SlackBuild

Si votre script suit ces principes, il respectera les critères de qualité exposés précédemment.

Je respecte tous ces critères, et j'ai fait un Slackbuild pour un nouveau logiciel.

Si vous le souhaitez, vous pouvez soumettre votre script à l'appréciation des autres membres sur le forum. Si les retours sont positifs, votre script pourra être inclus aux contributions, et donc permettre aux visiteurs d'installer très facilement le logiciel que vous avez packagé.

Devoir d'abord exposer votre Slackbuild sur le forum peut vous paraître superflu, mais cela peut être l'occasion de prendre connaissance de bugs qui n'apparaissent pas sur votre configuration, mais sur celle d'un autre membre, ou d'apprendre de nouvelles astuces de programmation shell.

Les autres membres ont accueilli mon script avec enthousiasme !

Vous pouvez l'ajouter au contributions si vous le désirez, avec l'accord de l'administrateur. Il faut pour cela placer votre Slackbuild, ainsi que tous les fichiers nécessaires à son bon fonctionnement, dans un dossier portant le nom et la version du logiciel packagé ; compressez ensuite le tout au format tar.bz2.

Afin que les membres puissent vérifier l'intégrité du script, il est recommandé de fournir également des sommes de contrôle MD5 et SHA1, ainsi que de signer l'archive avec gpg.

Cela se résume souvent aux commandes suivantes :

md5sum logiciel-version-Slackbuild.tar.bz2 > logiciel-version-Slackbuild.tar.bz2.md5
sha1sum logiciel-version-Slackbuild.tar.bz2 > logiciel-version-Slackbuild.tar.bz2.sha1
gpg -a -b logiciel-version-Slackbuild.tar.bz2

Hé au fait, comment on vérifie l'intégrité ? La question a été rapidement éludée tout à l'heure.

Chaque chose en son temps :-)

Il suffit d'examiner l'affichage des commandes suivantes :

md5sum -c *.md5
sha1sum -c *.sha1
gpg --verify *.asc

Si l'une d'entre elles signale une erreur, vous devriez essayer de retélécharger l'archive. Si l'erreur persiste, il est possible que l'archive soit corrompue, signalez-le à l'auteur.

Tags

slackbuilds/faq.txt · Dernière modification: 2011/05/16 10:03 par aster