Re: [RFR2] webwml://ports/hurd/hurd-devel-debian
On Sat, May 28, 2005, Mohammed Adnène Trojette wrote:
> Merci de la relecture. J'ai tout repris sauf le " !" à cause de l'espace
> insécable. J'avais effectivement oublié un paragraphe, donc je reposte
> un RFR2. J'ai un problème avec la première phrase du dernier paragraphe.
> C'est bien de ça que tu parles pour la ligne 208 (désolé, j'ai appliqué
> ton patch avant de vérifier la ligne en question) ?
Avec la pièce jointe.
--
adn
Mohammed Adnène Trojette
"Aime l'honneur plus que ta propre vie."
Pierre de Pibrac
#use wml::debian::template title="Debian GNU/Hurd – Development" NOHEADER="yes"
#include "$(ENGLISHDIR)/ports/hurd/menu.inc"
#use wml::debian::translation-check translation="1.29" maintainer="Mohammed Adnène Trojette"
<h1>
Debian GNU/Hurd</h1>
<h2>
Developpement de la distribution</h2>
<h3>
Disques d'amorçage</h3>
<p>
Actuellement, nous ne travaillons pas sur des disques d'amorçages
natifs. Nous nous reposons toutefois sur certaines des bases nécessaires
à ceci, et portons parfois individuellement des paquets nécessaires à
cet effet. Si vous voulez aider, travaillez sur le projet d'installateur
Debian et être sûr que ses composants fonctionnent sur le Hurd.</p>
<h3>
Porter des paquets Debian</h3>
<p>
Si vous souhaitez le portage Debian GNU/Hurd, vous devriez
vous familiariser avec le système d'empaquetage de Debian. Une fois
que vous l'aurez fait en lisant la documentation disponible et en
visitant le <ahref="../../devel/">Coin du développeur</a>, vous devriez
savoir comment extraire les paquets source Debian et empaqueter
un paquet Debian. Voici un cours intensif pour les personnes très
paresseuses :</p>
<h3>
Obtenir le source et empaqueter des paquets</h3>
<p>
Extraire un paquet source Debian requiert le fichier
<code>package_version.dsc</code> et les fichiers qui y sont listés.
Vous créez le répertoire d'empaquetage Debian avec la commande
<code>dpkg-source -x package_version.dsc</code></p>.
<p>
La construction du paquet se fait dans le nouveau répertoire
d'empaquetage Debian <code>package-version</code> avec
la commande <code>dpkg-buildpackage -B -rsudo "-mMonNom
<MonCourrierÉlectronique>"</code>. Vous pouvez utiliser
<code>-b</code> au lieu de <code>-B</code> si vous voulez aussi compiler
les parties indépendantes de l'architecture du paquet. Vous pouvez
utiliser <code>-rfakeroot</code> au lieu de <code>-rsudo</code> si vous
utilisez le paquet fakeroot. Vous pouvez le faire sans <code>-r</code>
si vous empaquetez en tant que superutilisateur. Vous pouvez ajouter
<code>-uc</code> pour éviter de signer le paquet avec votre clé pgp.</p>
<h3>
Choisissez un paquet</h3>
<p>
Quels sont les paquets sur lesquels il faut travailler ? Bon,
chaque paquet qui n'est pas encore porté, mais qui a besoin d'être
porté. Cela change constamment, alors soit prenez-en un au hasard
parmi les paquets manquants, soit cherchez des informations à propos
des processus d'empaquetage automatique sur la liste de diffusion
debian-hurd.</p>
<h4>
Paquets qui ne seront pas portés</h4>
<p>
Quelques paquets parmi ceux qui suivent, ou des parties de ces paquets,
seront peut-être portables plus tard, mais ils sont actuellement
considérés comme non portables au moins.</p>
<ul>
<li>
<code>base/update</code>, parce que le Hurd n'a pas besoin d'un démon
de mise à jour (les systèmes de fichiers se synchronisent eux-mêmes).
Pour changer l'intervalle de synchronisation, vous pouvez utiliser
<code>fsysopts</code> pour ajuster l'option <code>--sync</code>. Vous
pouvez choisir des intervalles de synchronisation différents pour chaque
système de fichiers !
Pour le faire vous-mêmes, utilisez l'utilitaire <a
href="hurd-doc-utils#syncfs"><code>syncfs</code></a>.</li>
<li>
<code>base/makedev</code>, parce que le Hurd apporte ses propres version
de ce script. Le paquet source Debian ne contient qu'une version
spécifique à Linux.</li>
<li>
<code>base/ld.so</code>, parce que le Hurd utilise l'éditeur de liens
qui est fourni par la bibliothèque GNU C.</li>
<li>
<code>base/modconf</code> and <code>base/modutils</code>, parce que
les modules sont un concept specifique à Linux.</li>
<li>
<code>base/netbase</code>, parce que le reste qui s'y trouve
est hautement spécifique au noyau Linux. Le Hurd utilise
<code>inetutils</code> à la place.</li>
<li>
<code>base/pcmcia-cs</code>, parce que le Hurd ne gère pas le PCMCIA
(et même s'il le faisait, ce paquet est probablement spécifique à
Linux).</li>
<li>
<code>base/procps</code>, parce que ce code est spécifique au système de
fichiers « proc » de Linux.</li>
<li>
<code>base/ppp</code> et <code>base/pppconfig</code>, parce que le Hurd
ne gère pas le PPP (et même s'il le faisait, ce paquet est probablement
spécifique à Linux).</li>
<li>
<code>base/setserial</code>, parce que c'est spécifique au noyau Linux.
Cependant, avec le portage des pilotes de caractères Linux sur GNU Mach,
nous pourrons peut-être les utiliser.</li>
</ul>
<h3>
Problèmes généraux de portage</h3>
<p>
Voici une liste d'incompatibilités communes que vous pouvez rencontrer
en compilant certains logiciels insuffisamment portables sur le
Hurd.</p>
<ul>
<li>
<code>Mauvais descripteur de fichier</code>
<p>
Si vous obtenez l'erreur <code>Bad File Descriptor</code> lorsque
vous essayez de lire depuis un fichier (ou en y accédant seulement),
vérifiez l'invocation de <code>open()</code>. Le second argument
est la méthode d'accès. Si c'est un nombre codé en dur au lieu d'un
symbole défini dans les fichiers d'en-tête standard, le code est
foutu et devrait être réparé pour utiliser <code>O_RDONLY</code>,
<code>O_WRONLY</code> ou <code>O_RDWR</code>. Ce bogue a été observé
dans les paquets <code>fortunes</code> et <code>mtools</code> par
exemple.</p></li>
<li>
<code>PATH_MAX</code>
<p>
Toute utilisation sans condition de <code>PATH_MAX</code> est une
incompatibilité de POSIX. S'il n'y a pas de limite supérieure sur la
longueur d'un chemin, ce symbole n'est pas défini dans le fichier
d'en-tête. À la place, vous devez soit utiliser une implémentation
différente qui ne se repose pas sur la longueur d'une chaîne de
caractères, soit utiliser <code>sysconf()</code> pour demander la
longueur au moment du lancement. Si <code>sysconf()</code> renvoie
<code>-1</code>, vous devez utiliser <code>realloc()</code> pour allouer
dynamiquement la mémoire nécessaire.</p></li>
<li>
<code>MAXHOSTNAMELEN</code>
<p>
voir <code>PATH_MAX</code></p></li>
<li>
<code>MAXPATHLEN</code>
<p>
voir <code>PATH_MAX</code></p></li>
<li>
<code>NOFILE</code>
<p>
voir <code>PATH_MAX</code></p></li>
<li>
<code>#define</code> spécifique au Hurd
<p>
Si vous avez besoin d'inclure du code spécifique au Hurd en utilisant
<code>#if...#endif</code>, alors vous pouvez pour ce faire utiliser le
symbole <code>__GNU__</code>. Mais pensez-y (au moins) à trois fois (!)
avant de le faire. Dans <em>la plupart</em> des cas, c'est complètement
inutile et créera plus de problèmes que ça n'en résoudra. Il vaut mieux
demander sur la liste de diffusion comment le faire correctement si vous
ne voyez pas de meilleure solution.</p></li>
<li>
<code>sys_errlist[]</code> vs. <code>strerror()</code>
<p>
Si un programme ne gère que <code>sys_errlist[]</code> vous devrez
travailler un peu pour le faire compiler sur le Hurd, qui a abandonné sa
gestion et ne fournit que <code>strerror()</code>. Steinar Hamre écrit,
à propos de <code>strerror()</code> :</p>
<blockquote>
<p>
<code>strerror()</code> devrait être utilisé parce que :
<ul>
<li>
c'est la méthode moderne, la méthode POSIX.</li>
<li>
C'est localisé.</li>
<li>
Il gère les signaux/nombres hors de portée et invalides (ce qui est
mieux que de le gérer comme une erreur et qui n'est pas un risque de
débordement de tampon/sécurité).</li></ul>
<p>
<code>strerror()</code> devrait toujours être utilisé s'il est
disponible. Malheureusement, certains <em>anciens</em> systèmes non
POSIX ne gèrent pas encore <code>strerror()</code>, mais seulement
<code>sys_errlist[]</code>.</p>
<p>
Aujourd'hui, gérer <code>strerror()</code> est bien mieux que
ne gérer que <code>sys_errlist[]</code>. Le mieux (du point de
vue de la portabilité) est toutefois de gérer les deux. Pour
<code>configure.in</code>, vous aurez besoin de :</p>
<p>
<code>AC_CHECK_FUNCS(strerror)</code></p>
<p>
Pour <code>config.h.in</code>, il faudra ajouter :</p>
<p>
<code>#undef HAVE_STRERROR</code></p>
<p>
Et quelque chose comme :
<pre>
\#ifndef HAVE_STRERROR
static char *
private_strerror (errnum)
int errnum;
{
extern char *sys_errlist[];
extern int sys_nerr;
if (errnum > 0 && errnum <= sys_nerr)
return sys_errlist[errnum];
return "Unknown system error";
}
\#define strerror private_strerror
\#endif /* HAVE_STRERROR */
</pre>
<p>
Vous pouvez par exemple regarder dans le dernier <code>fileutils</code>
(celui qui précède est une version modifiée ce que j'ai trouvé là).
Les rustines doivent bien sûr être envoyées aux responsables en
amont, ce qui est très utile, même pour les systèmes qui ont un
<code>sys_errlist[]</code> fonctionnel.</blockquote>
<li>
Noms de fichiers se finissant par slash « / »
<p>
C'est terrible s'ils n'existent pas et que vous souhaitez appeler un
répertoire ainsi. Par exemple, <code>mkdir foobar/</code> <em>ne</em>
marchera <em>pas</em> sous Hurd. C'est compatible POSIX. POSIX dit que
le chemin d'un répertoire peut avoir des slash en fin de nom. Mais
le répertoire n'existant pas encore, le chemin ne fait pas référence
à un répertoire, et il n'est pas garanti que les slash en fin de nom
fonctionneront. Laissez tomber les slash, et tout ira bien.</p>
</ul>
Reply to: