
                     HOWTO sur la publication de logiciels

Eric S. Raymond <esr@thyrsus.com> Traduction par Thierry Bzecourt
<thbzcrt@worldnet.fr>

   2.4, 12 juillet 2000
     _________________________________________________________________

   _Ce HOWTO dcrit des mthodes de publication de logiciel convenant 
   des projets de logiciel libre pour Linux. En adoptant ces rgles, vous
   permettrez  vos utilisateurs de compiler votre code et de l'utiliser
   plus facilement, et  d'autres dveloppeurs de mieux le comprendre et
   de vous aider  l'amliorer. Ce document est  lire absolument par les
   dveloppeurs dbutants. Ceux qui ont plus d'exprience devraient le
   parcourir  nouveau au moment de publier un nouveau projet. Il sera
   mis  jour priodiquement afin de reflter l'volution des rgles de
   bonne pratique._
     _________________________________________________________________

1. Introduction

1.1 Raison d'tre de ce document

   Un vaste ensemble de traditions relatives au dveloppement de
   logiciels libres permet  d'autres personnes de porter le code plus
   facilement, de l'utiliser et de participer  son dveloppement.
   Certaines de ces conventions sont des traditions du monde Unix
   antrieures  Linux ; d'autres ont t suscites rcemment par
   l'apparition de nouveaux outils et de nouvelles technologies comme le
   World Wide Web.

   Ce document vous aidera  acqurir ces rgles d'usage. Il se compose
   de plusieurs sections thmatiques, chacune contenant une liste de
   points  vrifier. Considrez que ces sections sont pour votre
   distribution comme la liste de contrle qu'un pilote d'avion vrifie
   avant le dcollage.

1.2 Nouvelles versions de ce document

   Ce document sera envoy chaque mois dans le forum de discussion
   comp.os.linux.answers . Ce document est archiv sur plusieurs sites
   FTP Linux, dont metalab.unc.edu dans le rpertoire
   pub/Linux/docs/HOWTO.

   Vous pouvez aussi voir la dernire version, en anglais, de ce HOWTO
   sur le World Wide Web  l'URL
   http://www.linuxdoc.org/HOWTO/Software-Release-Practice.html. La
   version franaise est disponible  l'adresse
   http://metalab.unc.edu/pub/Linux/docs/HOWTO/translations/fr.

   Vous pouvez envoyer vos questions et vos commentaires sur ce HOWTO 
   Eric S. Raymond, esr@snark.thyrsus.com.

1.3 Note du traducteur sur l'usage de l'anglais dans le document

   On a choisi de ne pas traduire les noms de fichiers que l'auteur
   recommande d'inclure dans un logiciel. En effet, le monde des
   logiciels libres est fortement internationalis, et il utilise
   l'anglais comme langue commune. On supposera donc que le lecteur qui
   souhaiterait mettre en application les conseils de ce HOWTO connat
   suffisamment d'anglais pour crire des documents tels que le fichier
   README ou le fichier INSTALL. Cela n'interdit pas, bien entendu,
   d'inclure dans les projets une version franaise de ces documents, qui
   sera trs apprcie des utilisateurs francophones, qu'ils parlent ou
   non l'anglais.

2. Rgles d'usage pour l'appellation de votre projet et de votre archive

   Au fur et  mesure que s'accrot la charge de travail des
   gestionnaires d'archives comme Metalab, le site PSA ou le CPAN, les
   soumissions sont de plus en plus souvent traites, en tout ou en
   partie, par des programmes (et non en totalit par des humains).

   Il est donc trs important que le nom de votre projet et celui de
   votre fichier d'archive suivent des rgles prcises, afin que des
   programmes informatiques puissent les analyser et les comprendre.

2.1 Utilisez le style d'appellation GNU, avec un prfixe suivi d'un numro du
type majeur.mineur.patch.

   Vous faciliterez la vie  tout le monde en donnant  vos archives des
   noms dans le style GNU : un prfixe-racine alphanumrique tout en
   minuscules, suivi par un tiret, puis un numro de version, une
   extension et d'autres suffixes.

   Supposons que vous ayez un projet nomm "toto", qui en est  la
   version 1, mise  jour 2, niveau 3. S'il est compos d'une seule
   archive (sans doute le code source), voici  quoi devrait ressembler
   son nom :

   _toto-1.2.3.tar.gz_
          L'archive des sources

   _toto.lsm_
          Le fichier LSM (si vous l'envoyez  Metalab).

   N'utilisez _pas_ les noms suivants :

   _toto123.tar.gz_
          Beaucoup de programmes croiront qu'il s'agit du fichier
          d'archive d'un projet nomm `toto123', sans numro de version.

   _toto1.2.3.tar.gz_
          Beaucoup de programmes croiront qu'il s'agit de l'archive d'un
          projet nomm `toto1'  la version 2.3.

   _toto-v1.2.3.tar.gz_
          Beaucoup de programmes prendront cela pour un projet nomm
          `toto-v1'.

   _to_to-1.2.3.tar.gz_
          Le caractre soulign est difficile  prononcer,  taper, et 
          retenir.

   _ToTo-1.2.3.tar.gz_
          A moins que vous vouliez _vraiment_ ressembler  un accroc du
          marketing. L encore, c'est difficile  prononcer,  taper et 
          retenir.

   Si vous voulez faire sparment une archive de sources et une archive
   de binaires, ou diffrentes archives de binaires, ou encore indiquer
   un certain type d'option de fabrication dans le nom de l'archive,
   rajoutez pour cela une extension _aprs_ le numro de version. Voici
   quelques exemples :

   _toto-1.2.3.src.tar.gz _
          sources

   _toto-1.2.3.bin.tar.gz _
          binaires, type non spcifi

   _toto-1.2.3.bin.ELF.tar.gz _
          binaires ELF

   _toto-1.2.3.bin.ELF.static.tar.gz _
          binaires ELF lis statiquement

   _toto-1.2.3.bin.SPARC.tar.gz _
          binaires pour SPARC

   N'utilisez _pas_ des noms comme `toto-ELF.1.2.3.tar.gz', car les
   programmes ont beaucoup de mal  sparer un infixe (tel que `ELF') de
   la racine du mot.

   Un bon schma d'appellation gnrique contient, dans l'ordre, les
   parties suivantes :

    1. prfixe du projet
    2. tiret
    3. numro de version
    4. point
    5. "src" ou "bin" (optionnel)
    6. point ou tiret (un point de prfrence)
    7. type de binaire et options (optionnel)
    8. extensions relatives au mode d'archivage et de compression

2.2 Mais respectez le cas chant les conventions locales

   Certains projets ou communauts ont des conventions bien tablies pour
   les noms et les numros de version, et ces conventions ne sont pas
   toujours compatibles avec les conseils qui prcdent. Par exemple, les
   modules Apache ont en gnral des noms du genre mod_foo, et ils ont 
   la fois un numro de version propre et le numro de la version
   d'Apache avec laquelle ils fonctionnent. De mme, les numros de
   version des modules Perl peuvent tre traits comme des nombres
   dcimaux (par exemple, vous pouvez voir 1.303  la place de 1.3.3), et
   les distributions s'appellent en gnral Foo-Bar-1.303.tar.gz pour la
   version 1.303 du module Foo::Bar.

   Apprenez et respectez les conventions des communauts et dveloppeurs
   spcialiss ; suivez les rgles dcrites ci-dessus dans le cas
   gnral.

2.3 Choisissez avec le plus grand soin un prfixe unique et facile  taper

   Le prfixe-racine devrait tre le mme pour tous les fichiers d'un
   projet, et il devrait tre facile  lire,  taper et  retenir.
   N'utilisez pas le caractre "soulign". Et ne mettez pas de majuscules
   ou de MajusculesIntrieures sans une trs bonne raison -- cela drange
   le trajet naturel de l'oeil humain, et vous aurez l'air de faire du
   marketing.

   C'est difficile de s'y retrouver lorsque deux projets ont le mme nom.
   Assurez-vous donc, dans la mesure du possible, qu'il n'y a pas de
   conflit de noms avant de publier votre premire version. Deux bons
   endroits pour vrifier ceci sont l'index de Metalab et l'index des
   applications (appindex)  Freshmeat. Un autre endroit recommand est
   SourceForge, en effectuant une recherche par nom.

3. Rgles d'usage pour la licence et le copyright : la thorie

   La licence que vous choisissez dfinit le contrat social que vous
   souhaitez mettre en place avec vos co-dveloppeurs et vos
   utilisateurs. Le copyright que vous mettez sur le logiciel sert
   principalement de dclaration lgale de votre droit  fixer les termes
   de la licence sur le logiciel et sur les oeuvres qui en sont drives.

3.1 Les logiciels  code ouvert et le copyright

   (Note du traducteur : dans cette section comme dans celles qui
   suivent, l'expression "(logiciel ) code ouvert" est utilise pour
   traduire l'anglais "open source", tandis que l'expression habituelle
   "logiciel libre" sert  transcrire "free software")

   Tout ce qui n'appartient pas au domaine public possde un copyright,
   voire plusieurs. Selon la Convention de Berne (qui a force de loi aux
   Etats-Unis depuis 1978), le copyright n'a pas besoin d'tre explicite.
   C'est--dire que les auteurs d'une oeuvre sont dtenteurs du copyright
   mme s'il n'y a pas de note de copyright.

   Il peut tre trs difficile de dterminer qui peut tre compt comme
   un auteur, surtout lorsque de nombreuses auteurs ont travaill sur le
   logiciel. C'est ce qui fait l'importance des licences. En prcisant
   les conditions dans lesquelles l'oeuvre peut tre utilise, elles
   donnent aux utilisateurs des droits qui les protgent des actions
   arbitraires que pourraient entreprendre les dtenteurs du copyright.

   Dans le logiciel propritaire, les termes de la licence sont formuls
   de manire  protger le copyright. Ils permettent de donner quelques
   droits aux utilisateurs tout en assurant au propritaire (le dtenteur
   du copyright) la plus grande possibilit d'action possible sur le plan
   lgal. Le dtenteur du copyright a une grande importance, et la
   licence est tellement restrictive dans l'esprit que les dtails
   techniques de ses termes sont gnralement sans importance.

   Dans le logiciel  code ouvert, la situation est souvent exactement
   inverse ; le copyright existe pour protger la licence. Les seuls
   droits qui sont toujours conservs au dtenteur du copyright sont ceux
   qui permettent de renforcer la licence. Parmi les autres droits, un
   petit nombre seulement sont rservs, et c'est l'utilisateur qui a la
   plus grande libert. En particulier, le dtenteur du copyright ne peut
   pas modifier la licence sur une copie que vous possdez dj. Par
   consquent, le dtenteur du copyright dans les logiciels  code ouvert
   n'a presque aucune importance -- contrairement aux termes de la
   licence.

   Normalement, le dtenteur du copyright sur un projet est le
   responsable actuel du projet ou une organisation mcne. Le changement
   de responsable  la tte d'un projet se manifeste souvent par la
   modification du copyright. Toutefois ce n'est pas une rgle absolue ;
   dans de nombreux projets  code source ouvert, le copyright revient 
   de multiples personnes, et il n'y a pas de cas connu o cela ait
   entran des complications sur le plan lgal.

   Certains projets choisissent de donner le copyright  la Free Software
   Foundation, avec l'ide que cette fondation a un intrt dans la
   dfense du logiciel  code ouvert, et possde les avocats pour s'en
   occuper.

3.2 Dterminer ce qui peut tre qualifi comme logiciel  code ouvert

   En ce qui concerne la licence, on peut distinguer plusieurs sortes de
   droits transfrables via une licence. Les droits de _copie et de
   redistribution_, les droits d'_utilisation_, les droits de
   _modification  usage personnel_ et les droits de _redistribution de
   copies modifies_. Une licence peut restreindre chacun de ces droits
   ou les accompagner de conditions.

   L' Open Source Initiative est le rsultat d'un important effort de
   rflexion sur ce qui fait un ``logiciel  code ouvert'' ou (dans une
   terminologie plus ancienne) un ``logiciel libre''. L'association place
   les contraintes suivantes sur les licences :

    1. Un droit de copie illimit doit tre accord.
    2. Un droit d'utilisation illimit doit tre accord.
    3. Un droit de modication illimit pour utilisation personnelle doit
       tre accord.

   Ces rgles proscrivent les restrictions sur la redistribution de
   binaires modifis ; cela correspond aux besoins des distributeurs de
   logiciels,  qui il faut pouvoir livrer sans entraves du code en tat
   de marche. Cela permet aux auteurs de demander que le code source
   modifi soit redistribu sous la forme du code source original plus
   des patchs, ce qui fait apparatre les intentions de l'auteur et, dans
   un``suivi d'audit'', toutes les modifications faites par d'autres
   personnes.

   L'OSD est la dfinition lgale de la marque de certification `OSI
   Certified Open Source', et vaut toutes les dfinitions qu'on a pu
   faire du ``logiciel libre'' (note du traducteur : OSI est ici l'Open
   Source Initiative et n'a rien  voir avec l'Organisme de
   Standardisation Internationale ou ISO). Toutes les licences courantes
   (MIT, BSD, Artistic et GPL/LGPL) la vrifient (encore que certaines,
   comme la GPL, ajoutent d'autres restrictions que vous devriez
   comprendre avant de les adopter).

   Notez que les licences n'autorisant qu'un usage non commercial ne
   peuvent _pas_ tre qualifies de licences  code ouvert, mme si elles
   affichent la licence ``GPL'' ou quelque autre licence courante. Elles
   font de la discrimination envers des emplois, des personnes et des
   groupes particuliers. Elles rendent la vie trop complique aux
   distributeurs de CD-ROM et aux autres personnes qui essaient de
   diffuser commercialement les logiciels  code ouvert.

4. Rgles d'usage pour la licence et le copyright : la pratique

   Voici comment appliquer dans la pratique la thorie qui prcde :

4.1 Donnez le copyright  vous-mme ou  la FSF

   Dans certains cas, si vous avez derrire vous une organisation mcne
   qui possde des avocats, vous pouvez choisir de donner le copyright 
   cette organisation.

4.2 Choisissez une licence conforme  l'Open Source Definition

   L'Open Source Definition (Dfinition du Code Ouvert) est la rgle d'or
   pour les licences. L'OSD n'est pas une licence en soi ; elle dfinit
   plutt un ensemble minimal de droits qu'une licence doit garantir afin
   d'tre considre comme une licence  code ouvert. On peut trouver
   L'OSD, avec des documents complmentaires, sur le site Web de l' Open
   Source Initiative.

4.3 N'crivez pas votre propre licence si vous pouvez l'viter.

   Les licences compatibles  l'OSD et connues de tous ont des traditions
   d'interprtation bien tablies. Les dveloppeurs (et, dans la mesure
   o ils s'y intressent, les utilisateurs) savent ce qui en dcoule, et
   mesurent les risques et les inconvnients qu'elles comportent. Par
   consquent, utilisez si possible l'une des licences standards sur le
   site de l'Open Source Initiative.

   Si vous devez crire votre propre licence, prenez soin de la faire
   certifier par l'Open Source Initiative. Cela vous pargnera de
   nombreuses discussions et des cots importants. Si vous n'tes jamais
   pass par l, vous ne pouvez pas imaginer pas  quel point un dbat
   sur les licences peut tourner au vinaigre ; les gens s'enflamment,
   parce que les licences sont considres comme des pactes presque
   sacrs qui touchent aux valeurs essentielles de la communaut des
   logiciels ouverts.

   De plus, l'existence d'une tradition d'interprtation bien tablie
   pourrait se rvler importante si un jour votre licence faisait
   l'objet d'un procs. A la date o ces lignes sont crites (septembre
   1999), il n'y a pas d'exemple de dcision judiciaire qui ait confirm
   ou invalid une licence de logiciel  code ouvert. Toutefois, c'est un
   principe de droit (au moins aux Etats-Unis, et sans doute dans
   d'autres pays de droit coutumier comme l'Angleterre et le reste du
   Commonwealth) que les cours de justice doivent interprter les
   licences et les contrats en fonction des attentes et des pratiques de
   la communaut qui les a produits.

5. Rgles d'usage du dveloppement

   La plupart de ces rgles visent  assurer la portabilit, non
   seulement entre les diffrentes distributions de Linux, mais aussi
   avec d'autres varits d'Unix. La portabilit vers Unix n'est pas
   seulement une question de professionnalisme ou de savoir-vivre entre
   programmeurs, c'est aussi une assurance non ngligeable contre les
   volutions futures de Linux lui-mme.

   D'autres personnes _finiront_ par essayer de compiler votre code dans
   d'autres environnements que Linux ; avec la portabilit, vous recevrez
   moins de messages ennuyeux de la part d'utilisateurs perplexes.

5.1 Ecrivez soit en C ANSI pur, soit dans un langage de script portable

   Pour des raisons de portabilit et de stabilit, il est fortement
   recommand d'crire soit en C ANSI pur, soit dans un langage de script
   dont la portabilit soit garantie par une implmentation
   multi-plateforme unique.

   Parmi les langages de script, Python, Perl, Tcl, Emacs Lisp et PHP
   respectent ce critre. Le bon vieux shell _ne convient pas_ ; il
   existe trop d'implmentations diffrentes, chacune ayant des
   particularits subtiles, et l'environnement du shell est souvent
   transform de manire imprvisible par des configurations propres 
   chaque utilisateur, comme les alias.

   Java promet beaucoup sur le plan de la portabilit, mais les
   implmentations disponibles sur Linux sont encore sommaires et mal
   intgres dans le systme d'exploitation. Java est encore un choix
   exotique, bien qu'il ait de fortes chances de gagner en popularit
   lorsqu'il aura plus de maturit.

5.2 Respectez les rgles de portabilit du C

   Si vous crivez en C, n'hsitez pas  utiliser  fond les
   fonctionnalits dcrites dans la norme ANSI -- y compris les
   prototypes de fonction, qui vous aideront  reprer les incohrences
   entre modules. Les compilateurs du type K&R relvent du pass.

   En revanche, ne supposez _pas_ que certaines caractristiques
   spcifiques  GCC comme l'option `-pipe' ou les fonctions imbriques
   sont disponibles. Cela vous poursuivra et vous vous en repentirez le
   jour o quelqu'un portera votre logiciel vers un systme autre que
   Linux, ou dpourvu de GCC.

5.3 Utilisez autoconf/automaker/autoheader

   Si vous crivez en C, utilisez autoconf/automaker/autoheader pour
   assurer la portabilit, vrifier la configuration du systme et
   affiner vos makefiles. De nos jours, les gens qui compilent  partir
   des sources s'attendent  devoir juste taper "configure; make" et que
   tout se compile proprement - sans la moindre erreur.

5.4 Soignez la rigueur de votre code avant chaque nouvelle version

   Si vous crivez en C, faites une compilation de test avec l'option
   -Wall et corrigez les erreurs rsultantes, au moins une fois avant
   chaque nouvelle version. On trouve comme cela un nombre surprenant
   d'erreurs. Pour tre vraiment complet, compilez aussi avec l'option
   -pedantic.

   Si vous crivez en Perl, vrifiez votre code avec perl -c (voire -T
   dans les cas adquats). Utilisez perl -w et 'use strict'
   religieusement (consultez la documentation de Perl pour plus
   d'informations).

5.5 Soignez votre documentation et vos README avant la livraison

   Passez-les au correcteur d'orthographe. Si vous donnez l'impression de
   ne pas connatre l'orthographe et de vous en moquer, les gents
   penseront que vous avez aussi bcl votre code.

6. Rgles d'usage pour la mise au point de la distribution

   Les indications qui suivent montrent  quoi votre distribution devrait
   ressembler lorsqu'on la rcupre et qu'on la dcompacte.

6.1 Assurez-vous que vos archives se dcompactent toujours dans un rpertoire
nouveau et unique.

   L'erreur la plus agaante que font les dveloppeurs novices est de
   fabriquer des archives qui dcompactent les fichiers et rpertoires de
   la distribution dans le rpertoire courant, avec le risque d'craser
   des fichiers dj prsents. _Ne faites jamais cela !_

   A la place, faites en sorte que les fichiers de vos archives partagent
   le mme rpertoire, avec un nom drivant de celui du projet. Ainsi,
   ils se placeront dans un seul rpertoire, juste _en-dessous_ du
   rpertoire courant.

   Voici un moyen de raliser cela dans un makefile, en supposant que le
   rpertoire 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))

6.2 Ecrivez un README

   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'intrpide explorateur lira aprs avoir
   extrait les sources.

   Voici quelques lments qu'il est bon d'avoir dans un README :

     * Une brve description du projet.
     * Un lien vers le site Web du projet, le cas chant.
     * Des indications sur l'environnement de compilation du dveloppeur
       et sur les possibles problmes de portabilit.
     * Un plan d'ensemble des fichiers et sous-rpertoires importants.
     * Les instructions de compilation et d'installation, ou bien un lien
       vers le fichier les contenant (habituellement INSTALL).
     * Le nom des responsables et des contributeurs, ou un lien vers le
       fichier contenant ces noms (habituellement CREDITS).
     * Les dernires nouvelles relatives au projet, ou un lien vers un
       fichier les contenant (habituellement NEWS).

6.3 Adoptez les conventions courantes d'appellation des fichiers

   Avant mme d'avoir regard le README, votre intrpide explorateur aura
   parcouru la liste des fichiers dans le rpertoire principal de votre
   distribution. Ces noms, par eux-mmes, contiennent de l'information.
   En suivant certaines rgles d'appellation, vous donnerez 
   l'explorateur de bons indices pour orienter son parcours.

   Voici quelques noms recommands pour les fichiers du rpertoire
   principal, avec leur signification. Tous ne sont pas indispensables
   dans chaque projet.

   _README ou READ.ME_
          le plan d'ensemble,  lire en premier

   _INSTALL_
          instructions de configuration, de compilation et d'installation

   _CREDITS_
          liste des contributeurs du projet

   _NEWS_
          dernires nouvelles

   _HISTORY_
          histoire du projet

   _COPYING_
          termes de la licence (convention GNU)

   _LICENSE_
          termes de la licence

   _MANIFEST_
          liste des fichiers

   _FAQ_
          "Foire Aux Questions" pour le projet, au format texte.

   _TAGS_
          fichier de tags gnr automatiquement, pour tre utilis par
          Emacs ou vi

   Remarquez que la convention gnrale est que les fichiers dont le nom
   ne comporte que des majuscules sont des fichiers d'information sur le
   projet lui-mme, et ne sont pas des lments du systme  compiler.

   La prsence d'une FAQ vous soulagera beaucoup. Quand une question
   relative au projet revient frquemment, 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
   rduire 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 antriorit si vous tiez pris
   dans un procs pour contrefaon (ce n'est jamais encore arriv 
   personne, mais autant y tre prpar).

6.4 Prvoyez les mises  jour

   Votre logiciel voluera dans le temps au rythme des versions
   successives. Certains des changements ne seront pas compatibles avec
   l'existant. Par consquent, rflchissez bien  l'organisation du
   logiciel afin que plusieurs versions puissent tre installes et
   coexister sur le mme systme. C'est particulirement important pour
   les bibliothques 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 problme, celle des rpertoires numrots par version.
   Voici  quoi ressemble une hirarchie de bibliothques Qt (${ver} est
   le numro 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-tte
+

   Une telle organisation vous permet de faire coexister plusieurs
   versions. Les programmes clients doivent spcifier quelle version de
   la bibliothque ils dsirent, mais c'est un faible prix  payer en
   comparaison des incompatibilits d'interface qu'ils vitent.

6.5 Fournissez des RPM

   Le format standard de facto pour les distributions de binaires 
   installer est celui qu'utilise le Red Hat Package Manager, RPM. Il est
   prsent 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 consquent, c'est une bonne ide de fournir sur le site de votre
   projet des RPM installables en mme temps qu'une archive des sources.

   C'est aussi une bonne ide d'inclure dans votre archive de sources le
   fichier de spcification du RPM, avec dans le Makefile une entre qui
   fabrique les RPM  partir de lui. Le fichier de spcification devrait
   avoir l'extension `.spec' ; c'est comme cela que l'option -t de rpm le
   trouve  l'intrieur de l'archive.

   Encore un point de style : gnrez votre fichier de spcification avec
   un script shell qui insre automatiquement le numro 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, ralise au cours de la partie install de votre
   fabrication, se droulera dans les rpertoires finaux. Ceci se
   produira mme en cas d'homonymie de fichiers ou si vous ne dsirez pas
   rellement installer le produit. Une fois la fabrication termine, les
   fichiers seront installs  leur emplacement dfinitif, et la base de
   donnes RPM du systme ne sera pas mise  jour. Des SRPM ayant ce
   mauvais comportement sont des champs de mines et doivent tre vits.

7. Comment bien communiquer

   Votre logiciel n'apportera pas grand-chose  l'univers si vous tes le
   seul  connatre son existence. De plus, en tablissant une prsence
   visible sur Internet pour votre projet, vous pourrez recruter plus
   facilement des utilisateurs et des co-dveloppeurs. On le fait
   habituellement comme ceci :

7.1 Faites une annonce dans c.o.l.a et sur Freshmeat

   Annoncez vos nouvelles versions dans comp.os.linux.announce. Non
   seulement ce forum est lu par un grand nombre de personnes, mais c'est
   aussi un fournisseur important pour des sites Web d'information comme
   Freshmeat.

7.2 Faites une annonce dans un forum de discussion adquat

   Trouvez un forum USENET dont le thme de discussion est directement
   concern par votre application, et faites-y aussi votre annonce.
   N'envoyez votre message qu'aux endroits o la _fonction_ remplie par
   votre logiciel est pertinente, et restez mesur.

   Si (par exemple) vous publiez un programme en Perl qui interroge des
   serveurs IMAP, vous devriez probablement envoyer un message dans
   comp.mail.imap. Mais srement pas dans comp.lang.perl,  moins que le
   programme utilise de manire instructive des techniques Perl avances.

   Votre annonce devrait aussi contenir l'URL du site Web de votre
   projet.

7.3 Ayez un site Web

   Si vous comptez tablir une communaut substantielle d'utilisateurs ou
   de dveloppeurs autour de votre projet, celui-ci devrait avoir son
   site Web. Voici des lments que l'on trouve habituellement sur un
   site Web :
     * La charte du projet (pourquoi il existe, quelle est son audience,
       etc).
     * Des liens pour le tlchargement des sources.
     * Des instructions relatives  l'inscription  la ou les liste(s) de
       diffusion.
     * Une FAQ (Foire Aux Questions).
     * Une version en HTML de la documentation.
     * Des liens vers des projets proches et/ou concurrents.

   Certains projets ont mme une URL pour un accs anonyme 
   l'arborescence principale du code source.

7.4 Hbergez des listes de diffusion pour votre projet

   Il est d'usage d'avoir une liste de dveloppement prive qui permet
   aux collaborateurs du projet de communiquer et d'changer des patchs.
   Vous voudrez peut-tre crer en plus une liste d'annonces pour les
   gens qui veulent tre informs de la progression du projet.

7.5 Publiez dans les archives les plus importantes

   Depuis plusieurs annes, le site Metalab est le plus important des
   endroits d'change de logiciels pour Linux.

   Voici quelques autres sites notables :

     * le site Python Software Activity (pour les logiciels crits en
       Python).
     * le CPAN ou Rseau d'Archives Perl Global (pour les logiciels
       crits en Perl).

8. La bonne gestion d'un projet

   Bien grer un projet lorsque tous les participants sont bnvoles
   prsente des dfis particuliers. Le sujet est trop large pour tre
   trait dans le cadre d'un HOWTO. Heureusement, il existe des documents
   de rflexion qui vous aideront  comprendre les principaux points.

   Pour un essai sur l'organisation de base du dveloppement et du
   principe `distribuez tt, mettez  jour souvent' propre au `mode
   bazar', lisez The Cathedral and the Bazaar.

   Pour une rflexion sur les motivations psychologiques, des coutumes de
   la communaut et de la rsolution des conflits, lisez Homesteading the
   Noosphere.

   Pour un expos des principes conomiques et des modles commerciaux 
   adopter, lisez The Magic Cauldron.

   Si vous tes allergique  la langue de Shakespeare, vous pourrez
   trouver des traductions de ces documents sur le site Linux France.

   Ces papiers ne prtendent pas se poser comme les rfrences ultimes 
   propos des dveloppements  code source ouvert. Mais ils constituent
   les premires analyses srieuses crites sur le sujet, et n'ont pas
   encore t dpasss (l'auteur espre toutefois qu'ils le seront un
   jour).
