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.
Hosting by: Hurra Communications GmbH
Generated: 2007-01-26 18:01:16