<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
  <META NAME="GENERATOR" CONTENT="GtkHTML/3.12.2">
</HEAD>
<BODY>
Bon la discution commence &#224; etre enorme, et &#224; partir dans tous les sens.<BR>
<BR>
Moi aussi je lance ma branche!!<BR>
<BR>
<BR>
Donc comme promis trashy, le cafouillage sur le patch. (La revue des experts est naturellement indispensable)<BR>
<BR>
<BR>
<BLOCKQUOTE>
    * On fait une copie de sauvegarde du fichier &#224; modifier (on lui ajoute un extension explicite et unique, par exemple .max_ext) ;<BR>
            $ cp fichier fichier.max_ext<BR>
    * On modifie l'original (celui qui s'appelle 'fichier') comme on le d&#233;sire ;<BR>
    * On g&#233;n&#232;re un patch avec gendiff :<BR>
            cd ~/rpmbuild/BUILD<BR>
            gendiff dossier .max_ext &gt; ../SOURCES/nom_du_soft-version-max_ext.patch<BR>
    * On indique dans le specfile qu'il faut ajouter le patch
<PRE>
...
<B>Patch0:                PyPar2-0.10-max_ext.patch</B>&nbsp; //On donne le nom du patch
...
<I>%prep</I>
%setup -q -n PyPar2-%{version}
<B>%patch0 -p1 -b .max_prefix</B>  //On l'applique
...
</PRE>
</BLOCKQUOTE>
L'interet de l'extension se revele lorsqu'un patch mais plusieurs fichiers en jeu, et qu'il y a plusieurs problemes &#224; patcher.<BR>
Voici un exemple pour clarifier la chose :<BR>
Soit 10 fichiers : f0, f1, .., f9<BR>
et deux problemes &#224; patcher.<BR>
<BR>
f1, et f4 sont modifi&#233;s pour resoudre le probl&#232;me A, donc f1 et f4 seront copi&#233; sous les noms f1.fixA et f4.fixA, puis modifi&#233; comme il le faut, selon la methode expliqu&#233;e plus haut.<BR>
<BR>
f2, f7, f8, et f9 doivent etre modifi&#233;s pour r&#233;soudre le probleme B. Idem on a {f2, f7, f8,f9}.fixB<BR>
<BR>
On applique deux fois gendiff, comme vu plus haut. On obtient deux patchs. 1 par probleme, qui chacun modifie plusieurs fichiers.<BR>
Ainsi, malgr&#233; la complexit&#233; du probl&#232;me on conserve un specfile propre et simple.<BR>
<BR>
<BR>
Voil&#224; de ce que j'ai compris du fonctionnement.<BR>
J'avais fait des tests pour m'entrainer (meme si ils ne servaient &#224; rien)<BR>
<BR>
<BR>
Quelques cas o&#249; le patch ne devrait, selon moi, pas etre utilis&#233; :<BR>
ex : un Makefile un peu moche dit : prefix=/usr/local<BR>
alors que nous on pr&#233;f&#232;rerait : /usr<BR>
<BR>
On pourrait faire un patch, mais on pourrait aussi indiqu&#233; dans le specfile tout simplement :<BR>
make install DESTDIR=%{buildroot} prefix=%{_prefix}<BR>
<BR>
Le patch, dans le cas d'une op&#233;ration aussi simple que celle-ci vient plus compliqu&#233; la tache du reviewer qu'autre chose.<BR>
<BR>
<BR>
Remi, chithles, christophe, &#224; vos claviers.<BR>
<BR>
Johan &gt; j'esp&#232;re que j'ai &#233;t&#233; &#224; peu pres clair.<BR>
<BR>
A+<BR>
<TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
<TR>
<TD>
<PRE>
-- 
Maxime Carron &lt;<A HREF="mailto:maxime.carron@fedoraproject.org">maxime.carron@fedoraproject.org</A>&gt;
Fedora Ambassador
Fedora-fr Community Manager
</PRE>
</TD>
</TR>
</TABLE>
</BODY>
</HTML>