Les indications qui suivent montrent à quoi votre distribution devrait ressembler lorsqu'on la récupère et qu'on la décompacte.
L'erreur la plus agaçante que font les développeurs novices est de fabriquer des archives qui décompactent les fichiers et répertoires de la distribution dans le répertoire courant, avec le risque d'écraser des fichiers déjà présents. Ne faites jamais cela !
A la place, faites en sorte que les fichiers de vos archives partagent le même répertoire, avec un nom dérivant de celui du projet. Ainsi, ils se placeront dans un seul répertoire, juste en-dessous du répertoire courant.
Voici un moyen de réaliser cela dans un makefile, en supposant que le répertoire de votre distribution est `toto' et que SRC est une variable contenant la liste des fichiers de votre distribution. Vous devez avoir GNU tar 1.13.
VERS=1.0
toto-$(VERS).tar.gz:
tar --name-prefix='toto-$(VERS)/' -czf toto-$(VERS).tar.gz $(SRC)
Si votre version de tar est plus ancienne, faites quelque chose dans ce genre :
toto-$(VERS).tar.gz:
@ls $(SRC) | sed s:^:toto-$(VERS)/: >MANIFEST
@(cd ..; ln -s toto toto-$(VERS))
(cd ..; tar -czvf toto/toto-$(VERS).tar.gz `cat toto/MANIFEST`)
@(cd ..; rm toto-$(VERS))
Fournissez un fichier nommé README ou READ.ME, qui donne une vision d'ensemble de votre distribution. C'est une vieille convention, et c'est le premier fichier que l'intrépide explorateur lira après avoir extrait les sources.
Voici quelques éléments qu'il est bon d'avoir dans un README :
Avant même d'avoir regardé le README, votre intrépide explorateur aura parcouru la liste des fichiers dans le répertoire principal de votre distribution. Ces noms, par eux-mêmes, contiennent de l'information. En suivant certaines règles d'appellation, vous donnerez à l'explorateur de bons indices pour orienter son parcours.
Voici quelques noms recommandés pour les fichiers du répertoire principal, avec leur signification. Tous ne sont pas indispensables dans chaque projet.
le plan d'ensemble, à lire en premier
instructions de configuration, de compilation et d'installation
liste des contributeurs du projet
dernières nouvelles
histoire du projet
termes de la licence (convention GNU)
termes de la licence
liste des fichiers
"Foire Aux Questions" pour le projet, au format texte.
fichier de tags généré automatiquement, pour être utilisé par Emacs ou vi
Remarquez que la convention générale est que les fichiers dont le nom ne comporte que des majuscules sont des fichiers d'information sur le projet lui-même, et ne sont pas des éléments du système à compiler.
La présence d'une FAQ vous soulagera beaucoup. Quand une question relative au projet revient fréquemment, rajoutez-la dans la FAQ. Puis demandez aux utilisateurs de lire la FAQ avant de poser des questions ou d'envoyer des rapports de bogues. Une FAQ bien entretenue peut réduire d'au moins un ordre de grandeur la charge du support pour les mainteneurs du projet.
Il est bon d'avoir un fichier HISTORY ou NEWS avec un historique du projet mis à jour à chaque nouvelle version. Entre autres choses, il pourrait vous aider à prouver votre antériorité si vous étiez pris dans un procès pour contrefaçon (ce n'est jamais encore arrivé à personne, mais autant y être préparé).
Votre logiciel évoluera dans le temps au rythme des versions successives. Certains des changements ne seront pas compatibles avec l'existant. Par conséquent, réfléchissez bien à l'organisation du logiciel afin que plusieurs versions puissent être installées et coexister sur le même système. C'est particulièrement important pour les bibliothèques de fonctions : vous ne pouvez pas compter que tous les programmes clients soient mis à jour d'un seul coup pour s'adapter aux modifications de vos interfaces.
Les projets Emacs, Python et Qt ont adopté une bonne convention pour traiter ce problème, celle des répertoires numérotés par version. Voici à quoi ressemble une hiérarchie de bibliothèques Qt (${ver} est le numéro de version) :
/usr/lib/qt
/usr/lib/qt-${ver}
/usr/lib/qt-${ver}/bin # Emplacement de moc
/usr/lib/qt-${ver}/lib # Emplacement des .so
/usr/lib/qt-${ver}/include # Emplacement des fichiers d'en-tête
+
Une telle organisation vous permet de faire coexister plusieurs versions. Les programmes clients doivent spécifier quelle version de la bibliothèque ils désirent, mais c'est un faible prix à payer en comparaison des incompatibilités d'interface qu'ils évitent.
Le format standard de facto pour les distributions de binaires à installer est celui qu'utilise le Red Hat Package Manager, RPM. Il est présent dans les distributions Linux les plus populaires, et il est supporté en pratique par toutes les autres (sauf Debian et Slackware ; et Debian peut faire des installations à partir de RPM).
Par conséquent, c'est une bonne idée de fournir sur le site de votre projet des RPM installables en même temps qu'une archive des sources.
C'est aussi une bonne idée d'inclure dans votre archive de sources le fichier de spécification du RPM, avec dans le Makefile une entrée qui fabrique les RPM à partir de lui. Le fichier de spécification devrait avoir l'extension `.spec' ; c'est comme cela que l'option -t de rpm le trouve à l'intérieur de l'archive.
Encore un point de style : générez votre fichier de spécification avec un script shell qui insère automatiquement le numéro de version en analysant le Makefile ou un fichier version.h.
Note : si vous fournissez des RPM sources, utilisez BuildRoot pour fabriquer le programme dans /tmp ou /var/tmp. Si vous ne le faites pas, l'installation, réalisée au cours de la partie install de votre fabrication, se déroulera dans les répertoires finaux. Ceci se produira même en cas d'homonymie de fichiers ou si vous ne désirez pas réellement installer le produit. Une fois la fabrication terminée, les fichiers seront installés à leur emplacement définitif, et la base de données RPM du système ne sera pas mise à jour. Des SRPM ayant ce mauvais comportement sont des champs de mines et doivent être évités.