Ce fichier explique quelques unes des conventions  suivre pour ceux qui
souhaitent contribuer au projet.


	Les fichiers spec RPM.

Nos conventions pour les fichiers spec RPM sont assez similaires  celles de
RedHat, mais quelques diffrences et besoins supplmentaires pour les
paquets natifs Owl existent.

1. Commencez le fichier spec avec un commentaire contenant le mot cl CVS
Id, suivi par une ligne vide.

2. Les noms de tag prfrs (chaque fois qu'un synonyme existe) et leur
ordre est : Summary, Name, Version, Release, Epoch, License, Group, URL,
Source*, Patch*, PreReq, Requires, Conflicts, Provides, Obsoletes, Auto*,
Prefix, BuildRequires, BuildArchitectures, ExcludeArch, ExclusiveArch,
BuildRoot (ndt : respectivement Rsum, Nom, Version, Numro de sortie,
poque, Licence, Groupe, URL, Source*, Patch*, Pr-Requis, Require, Entre en
conflit, Fournit, Rend obsolte, Auto*, Prfixe, Require  la compilation,
Architectures de compilation, Architectures exclues, Architectures
exclusives, Racine de compilation). Nous n'utilisons pas (actuellement) les
autres tags.

3. Les numros de version pour les paquets Owl natifs sont de la forme :

	owlREVISION

ou, lors de l'empaquetage d'une version alpha/bta/prversion d'une certaine
pice de logiciel et le tag Version est le numro de version imminent :

	owl0.REVISION

ou, lors de la mise  jour d'une branche plus ancienne de Owl :

	BRANCH_POINT_RELEASE.BRANCH.REVISION

o REVISION est un numro de version de paquet spcifique  Owl incrment
aprs chaque mise  jour, BRANCH_POINT_RELEASE est la chane Release telle
que lorsque la branche a t cre, et BRANCH est la version de la branche
(qui est, "0.1" pour Owl 0.1-stable).

Lors de la mise  jour vers une nouvelle Version, REVISION doit tre
rinitialis  1 et, pour les branches plus anciennes, BRANCH_POINT_RELEASE
initialis  "owl0".

4. Le tag BuildRoot correct pour un paquet Owl est :

	BuildRoot: /override/%name-%version

Notre environnement de compilation surchargera le tag BuildRoot sans tenir
compte de ce tag, mais le fixer de cette faon rappellera aux gens de
surcharger le tag BuildRoot pour les compilations manuelles du paquet,
surtout en dehors de Owl.

5. Sparez les noms de tag et les valeurs que vous leur fixez avec un unique
caractre espace. Utilisez les virgules (galement suivies par un espace)
pour sparer les articles dans les listes de dpendances. Terminez les
lignes Summary avec un point. Dans Summary et %description (comme dans tout
autre documentation), vitez de mettre une majuscule aux noms des commandes,
mme si elles sont le premier mot d'une phrase,  moins que la forme avec
une majuscule soit le nom officiel pour le logiciel en question. Utilisez
deux espaces pour sparer les phrases.

6. Notre environnement de compilation fixe les drapeaux d'optimisation du
compilateur C/C++ dans %optflags d'une faon qui est optimale pour la
compilation de programmes standalone et qui ne produit pas trop
d'avertissements avec des fichiers sources typiques. En compilant des
bibliothques, un autre ensemble de drapeaux d'optimisation peut tre
utilis en plaant les deux lignes suivantes juste avant la section %build :

	# Use optflags_lib for this package if defined.
	%{expand:%%define optflags %{?optflags_lib:%optflags_lib}%{!?optflags_lib:%optflags}}

Ceci dsactivera les optimisations qui empcheraient le dbogage des
programmes lis avec les bibliothques (mme quand les programmes eux-mmes
sont correctement compils pour le dbogage) et, sur x86, garantira
l'alignement appropri dans la pile pour des oprations en nombres 
virgules flottantes et MMX efficaces qu'un programme li  la bibliothque
peut faire. (Ce dernier est juste pour tre amical avec les programmes
tiers. Nous n'avons pas une quantit notable de mathmatiques en virgules
flottantes dans les programmes qui font partie de Owl et ainsi nous ne
faisons pas d'alignement supplmentaire de la pile en compilant nos
programmes. Mais les bibliothques ont besoin de diffrer  cause de
callback possibles.)

Il est recommand galement que vous fassiez que les fichiers sources soient
assez propres pour que le compilateur ne produire pas un seul avertissement
en compilant avec "gcc -Wall". Si vous le faites, alors la faon correcte de
passer -Wall est dans la plupart des cas en passant la ligne suivante juste
avant la section %build :

	%{expand:%%define optflags %optflags -Wall}

7. Les sous-shells dans la compilation, pr/post-
installation/dsinstallation, et les trigger-scripts sont  viter par tous
les moyens puisqu'ils masquent les erreurs possibles. Si vous avez
l'intention d'utiliser un sous-shell pour changer temporairement le
rpertoire courant, utilisez plutt les commandes pushd et popd. Si vous
devez rellement utiliser un sous-shell, il est suggr que vous propagiez
manuellement le statut des commandes qu'il excute au shell pre.

8. Utilisez les tabulations pour indenter les blocs conditionnels et les
suites de lignes dans les scripts.

9. Utilisez -eq ou -ne et non pas = ou != pour comparer les valeurs
numriques. En particulier, ceci s'applique  l'argument $1 que RPM lui-mme
passe aux scripts. Et ne placez pas le $1 entre guillemets, le paquet doit
faire confiance  son gestionnaire de paquets pour lui passer de toute faon
l'entre correcte.

10. Dans les dates de l'entre %changelog, utilisez deux chiffres pour le
jour du mois avec un zro devant si ncessaire.

11. Dans %changelog, en ajoutant de nouvelles entres spcifiez les Version
et Release actuelles aprs votre adresse e-mail, comme ceci :

* Mon Mar 10 2003 Your Name <you@example.com> 0.6.2-owl1


	Nommage des fichiers patch.

Utilisez la syntaxe suivante pour les noms des fichiers patch.

	NOM-VERSION-ORIGINE-QUOI.diff

o NOM et VERSION sont les nom et version du paquet, ORIGINE est une
abrviation du nom de la distribution (ou des noms des distributions) d'o
est originaire le patch, et QUOI est la description de ce pour quoi le patch
est fait ou ce qu'il fait.

Si un seul fichier patch est bas sur des pices de plus d'une distribution,
toutes doivent tre incluses dans ORIGINE par ordre de pertinence. Pour les
patches dvelopps en tant que partie de Owl, ORIGINE doit tre fixe 
"owl". Si un patch est driv d'une autre distribution mais avec des
changements significatifs appliqus, ORIGINE devrait inclure "-owl-"
galement (ce qui devrait indiquer que tous les bogues sont les ntres). Si
un patch a t extrait du dpt CVS principal du paquet en question (par
exemple, ceci peut tre le cas pour divers rtro-portages), ORIGINE devrait
tre fixe  "cvs" et QUOI  la date correspondante (comme AAAAMMJJ) plus la
description habituelle du patch. Les patches des mainteneurs en amont qui ne
sont pas (encore?) dans le dpt CVS primaire (si un existe encore) peut
avoir ORIGINE initialis  "up".

Il y a galement quelques QUOIs communs  utiliser chaque fois que c'est en
vigueur :

Makefile	- seulement des patches de fichiers Makefile* (notez la
		  majuscule)
bound		- vrification de limites (rparations de dbordements de
		  tampon et/ou d'entier)
config		- seulement des patches de fichiers de configuration
		  (compilation ou excution)
doc		- seulement des patches de fichiers de documentation
fixes		- accumulation de patches de bogue, de fiabilit, et/ou de
		  scurit
format		- rparations de chanes de formats de type printf (pas
		  seulement de scurit)
info		- seulement des patches de fichiers de documentation texinfo
install-no-root	- changements pour excuter "make install" ou quivalent en
		  non-root
linux		- changements ncessaires pour compiler sur Linux (pour les
		  logiciels ports)
man		- patches seulement des manuels
tmp		- patches s'occupant de problmes de manipulations de
		  fichiers temporaires
vitmp		- patches qui ajoutent un support vitmp(1)
warnings	- seulement des corrections de warnings de compilation

Ceci NE suggre PAS que vous devriez essayer d'arranger vos modifications
telles que les fichiers patch correspondent  une de ces catgories. En
fait, il est souvent prfrable de faire les chose diffremment. C'est juste
pour dire que s'il arrive d'avoir un fichier patch qui correspond  l'une
des catgories, nommez le en consquence (tel que, "tmp" et non pas, disons,
"mkstemp").


	(Re-)gnrer les fichiers patch.

Les fichiers patch devraient tre gnrs avec :

	TZ=UTC diff -urpN NOM-VERSION.orig NOM-VERSION >
		NOM-VERSION-ORIGINE-QUOI.diff

o NOM-VERSION.orig and NOM-VERSION sont des rpertoires avec les versions
originales et modifies du paquet amont, respectivement. Les options "-p" et
"-N" de diff(1) peuvent tre omises si non applicables.

Lors de la r-gnration des patches pour appliquer des changements
additionels, les patches existants doivent tre appliqus avec "patch -Z",
par exemple comme ceci :

	cd NOM-VERSION
	patch -p1 -Z < ../NOM-VERSION-ORIGINE-QUOI.diff

L'utilisation des horodatages en UTC nous permet de mieux les prserver
pendant les mises  jours de fichiers par patch et de rduire la quantit de
changements entre les rvisions.


	Formatage du code source C

En dveloppant ou en important des bouts de code C pour maintenance
supplmentaire comme partie de Owl, indent(1) devrait tre initialement
utilis avec les options suivantes :

	indent -kr -i8 -nlp -nbbo -l79 -lc79

Ceci ne correspond pas exactement  notre style de codage prfr et ainsi
ne doit pas tre utilis sur les sources dj dans Owl.


	Traitement des fichiers temporaires.

Il est mieux de ne pas utiliser de fichier temporaire, cependant si vous
devez, la faon prfre de le faire depuis des scripts shell est avec du
code comme celui-ci :

TMPFILE=
trap 'rm -f -- "$TMPFILE"' EXIT
trap 'trap - EXIT; rm -f -- "$TMPFILE"; exit 1' HUP INT QUIT TERM
TMPFILE="`mktemp -t program.XXXXXXXXXX`" || exit

Ceci devrait tre utilis dans vos propres scripts ou patche. Le paquet
devrait alors exiger la version correcte de mktemp(1) :

Requires: mktemp >= 1:1.3.1

Comme d'habitude, utilisez Requires, PreReq, et/ou BuildRequires selon o
dans le paquet les utilisations de mktemp se produisent.

$Owl: Owl/doc/fr/CONVENTIONS,v 1.6 2005/11/16 11:59:01 solar Exp $
