Si vous souhaitez aider 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 :
Le code source peut être obtenu en exécutant simplement
apt source paquet, ce qui extrait aussi les sources.
Extraire un paquet source Debian nécessite le fichier
paquet_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 paquet_version.dsc.
La construction du paquet se fait dans le nouveau répertoire
d'empaquetage Debian paquet-version avec
la commande dpkg-buildpackage -B "-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 ajouter
-uc pour éviter de signer le paquet avec votre clef GPG.
La construction pourrait nécessiter d’installer des paquets supplémentaires.
Le plus simple est d’exécuter apt build-dep paquet
qui installera tous les paquets nécessaires.
Utiliser pbuilder peut être pratique. Il peut être construit avec
sudo pbuilder create --mirror http://deb.debian.org/debian-ports/ --debootstrapopts --keyring=/usr/share/keyrings/debian-ports-archive-keyring.gpg --debootstrapopts --extra-suites=unreleased --extrapackages debian-ports-archive-keyring,
et pdebuild -- --binary-arch peut être utilisé et gérera le
téléchargement des dépendances de construction, etc, et mettra le résultat dans
/var/cache/pbuilder/result.
Sur quels paquets faut-il travailler ? À vrai dire,
tous les paquets qui ne sont pas encore portés, mais qui nécessitent de l’être.
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
Vérifiez également si le travail a déjà été fait sur
Quelques paquets parmi ceux qui suivent, ou des parties de ces paquets,
seront peut-être portables plus tard, mais ils sont actuellement
au moins considérés comme non portables.
Ils sont normalement marqués NotForUs
dans la base de données de buildd.
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/modconf et base/modutils, parce que
les modules sont un concept spécifique à Linux.base/netbase, parce que ce qui s'y trouve
est hautement spécifique au noyau Linux. Le Hurd utilise
inetutils à la place.base/pcmcia-cs, parce que ce paquet est 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.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 utilisent une dépendance erronée à libc6-dev.
C'est incorrect 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 peut être localisé avec 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].
dh_install: Cannot find (any matches for) "foo" (tried in ., debian/tmp)
Cela se produit habituellement lorsque l’amont n’installe pas quelque chose parce qu’il ne reconnaît pas le système d’exploitation. Quelquefois c’est tout bête (par exemple, il ne sait pas que construire une bibliothèque sur GNU/Hurd se fait exactement comme sur GNU/Linux) et cela nécessite d’être corrigé. Quelquefois cela est réellement sensé (par exemple, installation des fichiers de service de systemd). Dans ce cas, il est possible d’utiliser dh-exec : la construction dépend de dh-exec, chmod +x du fichier .install, et de préfixer les lignes problématiques avec, par exemple, [linux-any] ou [!hurd-any].
Pour construire une image ISO, le plus simple est de partir d'une image existante issue de la page des images CD de Hurd. Vous pouvez alors la monter et la copier :
mount debian-sid-hurd-i386-NETINST-1.iso /mnt cp -a /mnt /tmp/mon_image umount /mnt chmod -R +w /tmp/mon_image |
Vous pouvez monter le disque virtuel de démarrage et par exemple remplacer un traducteur par votre propre version :
gunzip /tmp/mon_image/initrd.gz mount /tmp/mon_image/initrd /mnt cp ~/hurd/rumpdisk/rumpdisk /mnt/hurd/ umount /mnt gzip /tmp/mon_image/initrd |
Vous pouvez reconstruire l'ISO avec grub-mkrescue :
rm -fr /tmp/mon_image/boot/grub/i386-pc grub-mkrescue -o /tmp/mon_image.iso /tmp/mon_image |