[ Portages ] [ Debian GNU/Hurd ] [ Actualité ] [ Configuration ] [ CD 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 à cela, et portons parfois individuellement des paquets nécessaires à cet effet. Si vous voulez aider, travaillez sur le projet d'installateur Debian et assurez-vous 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 <MonAdresseÉ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

Sur quels paquets faut-il travailler ? À vrai dire, tous les paquets qui ne sont pas encore portés, mais qui en ont besoin. Cela change constamment, alors il est conseillé de se focaliser d'abord sur les paquets ayant beaucoup de dépendances inverses, qui sont visibles sur le graphique de dépendance des paquets http://people.debian.org/~sthibault/graph-radial.pdf mis à jour quotidiennement ou sur la liste des paquets les plus demandés http://people.debian.org/~sthibault/graph-total-top.txt (c'est la liste des demandes à long terme, la liste des demandes à court terme est http://people.debian.org/~sthibault/graph-top.txt). C'est généralement une bonne idée aussi d'en prendre parmi la liste des paquets dépassés http://people.debian.org/~sthibault/out_of_date.txt, car ils ont fonctionné et qu'ils ne sont probablement cassés qu'à cause d'une paire de raisons. Vous pouvez aussi en prendre un au hasard parmi les paquets manquants, surveiller les journaux des processus d'empaquetage automatique sur la liste de diffusion debian-hurd ou utiliser la liste de wanna-build en http://people.debian.org/~sthibault/failed_packages.txt.gz.

Vérifiez également si le travail a déjà été fait sur http://alioth.debian.org/tracker/?atid=410472&group_id=30628&func=browse, http://alioth.debian.org/tracker/?atid=411594&group_id=30628&func=browse, sur le BTS (http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-hurd@lists.debian.org;tag=hurd), http://wiki.debian.org/Debian_GNU/Hurd et l'état en temps réel des paquets sur buildd.debian.org, par exemple https://buildd.debian.org/util-linux.

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ême, utilisez l'utilitaire syncfs.
base/makedev, parce que le Hurd apporte ses propres versions 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 et 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

Une liste des problèmes courants est disponible sur le site amont. Les problèmes courants suivants sont spécifiques à Debian.

Avant d'essayer de corriger quoi que ce soit, vérifiez si le portage kfreebsd* n'a pas déjà préparé des correctifs, qui demandent juste à être adaptés pour convenir aussi à hurd-i386.

Broken libc6 dependency
Certains paquets dépendent par erreur de libc6-dev. C'est inexact parce que libc6 est spécifique à certaines architectures GNU/Linux. Le paquet GNU correspondant est libc0.3-dev, mais les autres systèmes d'exploitation en utilisent de différents. Le problème est situé dans le fichier debian/control de l'arborescence source. Parmi les solutions typiques, il est possible de détecter le système d'exploitation avec dpkg-architecture et de mettre « en dur » (« hardcode ») le soname, ou mieux, utiliser un OU logique. Par exemple : libc6-dev | libc6.1-dev | libc0.3-dev | libc0.1-dev | libc-dev. libc-dev est un paquet virtuel qui fonctionne pour n'importe quel soname, mais il ne faut le placer qu'en dernière option.
undefined reference to snd_*, SND_* undeclared
Certains paquets utilisent ALSA même sur les architectures non Linux. Le paquet oss-libsalsa fournit quelques émulations à l'aide d'OSS, mais il est limité à la version 1.0.5 d'ALSA, et certaines fonctionnalités ne sont pas fournies, comme par exemple toutes les opérations de séquenceur.

Si le paquet le permet, la prise en charge d'ALSA devrait être désactivée pour les architectures !linux-any (par exemple à l'aide d'une option de configure), un qualificatif [linux-any] ajouté au Build-Depends d'alsa, et l'inverse ajouté à Build-Conflicts, comme par exemple Build-Conflicts: libasound2-dev [!linux-any].