[ Portages ] [ Debian GNU/Hurd ] [ Actualité ] [ Installation ] [ Cédéroms Hurd ] [ Documentation ] [ Développement ] [ Contact ]

Debian GNU/Hurd

Développement de la distribution

Disques d'amorçage

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.

Porter des paquets Debian

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 Coin du développeur, vous devriez savoir comment extraire les paquets source Debian et empaqueter un paquet Debian. Voici un cours intensif pour les personnes très paresseuses :

Obtenir le source et empaqueter des paquets

Extraire un paquet source Debian requiert le fichier package_version.dsc et les fichiers qui y sont listés. Vous créez le répertoire d'empaquetage Debian avec la commande dpkg-source -x package_version.dsc

La construction du paquet se fait dans le nouveau répertoire d'empaquetage Debian package-version avec la commande dpkg-buildpackage -B -rsudo "-mMonNom <MonCourrierÉlectronique>". Vous pouvez utiliser -b au lieu de -B si vous voulez aussi compiler les parties indépendantes de l'architecture du paquet. Vous pouvez utiliser -rfakeroot au lieu de -rsudo si vous utilisez le paquet fakeroot. Vous pouvez le faire sans -r si vous empaquetez en tant que superutilisateur. Vous pouvez ajouter -uc pour éviter de signer le paquet avec votre clé pgp.

Choisissez un paquet

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.

Paquets qui ne seront pas portés

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.

base/update, 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 fsysopts pour ajuster l'option --sync. Vous pouvez choisir des intervalles de synchronisation différents pour chaque système de fichiers ! Pour le faire vous-mêmes, utilisez l'utilitaire syncfs.
base/makedev, parce que le Hurd apporte ses propres version de ce script. Le paquet source Debian ne contient qu'une version spécifique à Linux.
base/ld.so, parce que le Hurd utilise l'éditeur de liens qui est fourni par la bibliothèque GNU C.
base/modconf and base/modutils, parce que les modules sont un concept spécifique à Linux.
base/netbase, parce que le reste qui s'y trouve est hautement spécifique au noyau Linux. Le Hurd utilise inetutils à la place.
base/pcmcia-cs, parce que le Hurd ne gère pas le PCMCIA (et même s'il le faisait, ce paquet est probablement spécifique à Linux).
base/procps, parce que ce code est spécifique au système de fichiers « proc » de Linux.
base/ppp et base/pppconfig, parce que le Hurd ne gère pas le PPP (et même s'il le faisait, ce paquet est probablement spécifique à Linux).
base/setserial, 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.

Problèmes généraux de portage

Voici une liste d'incompatibilités communes que vous pouvez rencontrer en compilant certains logiciels insuffisamment portables sur le Hurd.

Mauvais descripteur de fichier
Si vous obtenez l'erreur Bad File Descriptor lorsque vous essayez de lire depuis un fichier (ou en y accédant seulement), vérifiez l'invocation de open(). 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 O_RDONLY, O_WRONLY ou O_RDWR. Ce bogue a été observé dans les paquets fortunes et mtools par exemple.
PATH_MAX
Toute utilisation sans condition de PATH_MAX 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 sysconf() pour demander la longueur au moment du lancement. Si sysconf() renvoie -1, vous devez utiliser realloc() pour allouer dynamiquement la mémoire nécessaire.
MAXHOSTNAMELEN
voir PATH_MAX
MAXPATHLEN
voir PATH_MAX
NOFILE
voir PATH_MAX
#define spécifique au Hurd
Si vous avez besoin d'inclure du code spécifique au Hurd en utilisant #if...#endif, alors vous pouvez pour ce faire utiliser le symbole __GNU__. Mais pensez-y (au moins) à trois fois (!) avant de le faire. Dans la plupart 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.
sys_errlist[] vs. strerror()
Si un programme ne gère que sys_errlist[] vous devrez travailler un peu pour le faire compiler sur le Hurd, qui a abandonné sa gestion et ne fournit que strerror(). Steinar Hamre écrit, à propos de strerror() :
strerror() devrait être utilisé parce que :
- c'est la méthode moderne, la méthode POSIX.
- C'est localisé.
- 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é).
strerror() devrait toujours être utilisé s'il est disponible. Malheureusement, certains anciens systèmes non POSIX ne gèrent pas encore strerror(), mais seulement sys_errlist[].

Aujourd'hui, gérer strerror() est bien mieux que ne gérer que sys_errlist[]. Le mieux (du point de vue de la portabilité) est toutefois de gérer les deux. Pour configure.in, vous aurez besoin de :

AC_CHECK_FUNCS(strerror)

Pour config.h.in, il faudra ajouter :

#undef HAVE_STRERROR

Et quelque chose comme :
```
        #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 */
```
Vous pouvez par exemple regarder dans le dernier fileutils (le code qui précède est une version modifiée de celui 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 sys_errlist[] fonctionnel.
Noms de fichiers se finissant par slash « / »
C'est terrible s'ils n'existent pas et que vous souhaitez appeler un répertoire ainsi. Par exemple, mkdir foobar/ ne marchera pas 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.