Debian GNU/Hurd
Entwicklung der Distribution
Installationssystem
Aktuell arbeiten wir nicht an einem nativen Installationssystem. Wir versuchen allerdings die Basis dafür zu schaffen und portieren manchmal dafür wichtige Pakete. Wenn Sie uns helfen wollen, arbeiten sie am debian-installer-Projekt mit und stellen Sie sicher, dass die Komponenten auf dem Hurd laufen.
Debian-Pakete portieren
Wenn Sie dem Debian GNU/Hurd Port helfen wollen, sollten Sie sich mit dem Debian-Paketsystem vertraut machen. Wenn Sie dies getan haben, durch Lesen der verfügbaren Dokumentation und Besuchen der Entwickler-Ecke, sollten Sie gelernt haben, wie man Debian-Quellcodepakete auspackt und wie man Debian-Pakete erstellt. Nachfolgend finden sie einen Crashkurs für die ganz faulen Leute:
Quellcode bekommen und Pakete erstellen
Um ein Debian-Quellcodepaket auszupacken, benötigt man die Datei
paketname_version.dsc und die in ihr aufgelisteten
Dateien. Sie erstellen das Debian-Paketverzeichnis mit dem Programm
dpkg-source -x paketname_version.dsc
Um ein Paket zu erstellen, wechseln Sie in das
Debian-Paketverzeichnis paketname_version und führen Sie
den Befehl
dpkg-buildpackage -B -rsudo "-mMeinName <Meine-E-Mail>"
aus. Anstelle von -B können
Sie auch -b benutzen, um auch die architekturunabhängigen
Teile des Pakets zu erstellen. Sie können -rfakeroot
statt -rsudo benutzen, wenn Sie das fakeroot-Paket
installiert haben. Oder Sie können das -r weglassen, wenn
Sie den Befehl als Benutzer root ausführen. Sie können auch
-uc hinzufügen, wenn Sie das Paket nicht mit ihrem
PGP-Schlüssel signieren wollen.
Ein Paket auswählen
An welchem Paket sollte gearbeitet werden? An jedem, das noch nicht portiert wurde, aber portiert werden muss. Dies ändert sich ständig, daher wird empfohlen, sich zunächst auf Pakete mit vielen Rückwärts-Abhängigkeiten zu konzentrieren, was man in dem Paket-Abhängigkeits-Graphen http://people.debian.org/~sthibault/graph-radial.pdf sehen kann, der täglich aktualisiert wird, oder auf der Liste der meist-gewünschten Pakete (most-wanted list) http://people.debian.org/~sthibault/graph-total-top.txt (dies sind die langfristig gewünschten, die kurzfristig gewünschten sind in http://people.debian.org/~sthibault/graph-top.txt aufgeführt). Es ist für gewöhnlich auch eine gute Idee, welche von der Liste veralteter Pakete http://people.debian.org/~sthibault/out_of_date.txt zu nehmen, da diese mal funktioniert haben und der Grund für die Beschädigung jetzt möglicherweise nur einer von ein paar wenigen Gründen sein könnte. Sie können sich aber auch eines der noch nicht portierten Pakete zufällig heraussuchen, auf der debian-hurd-Mailingliste nach Informationen über den autobuilding-Prozess Ausschau halten oder die Liste der fehlgeschlagenen Pakete (wanna-build list) von http://people.debian.org/~sthibault/failed_packages.txt.gz benutzen.
Überprüfen Sie ebenfalls, ob Arbeiten bereits erledigt wurden: auf http://alioth.debian.org/tracker/?atid=410472&group_id=30628&func=browse oder auf http://alioth.debian.org/tracker/?atid=411594&group_id=30628&func=browse, im BTS unter http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-hurd@lists.debian.org;tag=hurd, auf http://wiki.debian.org/Debian_GNU/Hurd sowie laut dem Live-Status der Pakete auf buildd.debian.org, z.B. https://buildd.debian.org/util-linux.
Pakete, die nicht portiert werden
Manche dieser Pakete oder Teile von ihnen könnten später doch portabel sein, aber im Moment werden sie als nicht portabel angesehen.
base/update, weil der Hurd keinen update-Daemon benötigt (die Dateisysteme synchronisieren sich selbst). Wollen Sie das Synchronisationsintervall ändern, können siefsysoptsverwenden, um die--syncOption einzustellen. Sie können für jedes Dateisystem ein anderes Synchronisationsintervall einstellen. Um dies manuell zu tun, benutzen Sie dassyncfs-Hilfsprogramm.base/makedev, weil der Hurd eine eigene Version dieses Skripts mitbringt. Das Debian-Quellcodepaket enthält nur eine linuxspezifische Version.base/ld.so, weil der Hurd den Linker benutzt, der bei der GNU C-Bibliothek mitgeliefert wird.base/modconfundbase/modutils, weil Module ein linuxspezifisches Konzept sind.base/netbase, weil der dort übrig gebliebene Kram sehr spezifisch für den Linux-Kernel ist. Der Hurd benutzt stattdesseninetutils.base/pcmcia-cs, weil der Hurd keine PCMCIA-Unterstützung hat (und wenn er sie hätte, wäre das Paket wahrscheinlich trotzdem linuxspezifisch).base/procps, weil der Code speziell für das Linux proc-Dateisystem ist.base/pppundbase/pppconfig, weil der Hurd keine PPP-Unterstützung hat (und wenn er sie hätte, wäre das Paket wahrscheinlich trotzdem linuxspezifisch).base/setserial, weil es speziell für den Linux-Kernel ist. Das Paket könnte dennoch nutzbar sein, wenn die Linuxtreiber für zeichenorientierte Geräte für den GNU Mach portiert werden.
Allgemeine Portierungsprobleme
Eine Liste häufiger Problem ist auf der Website der Originalautoren verfügbar. Die nachfolgende Liste von häufigen Problemen ist spezifisch für Debian.
Bevor Sie versuchen, ein Problem zu beheben, überprüfen Sie, ob die kfreebsd-Portierung bereits einen passenden Fix hat, der nur noch für hurd-i386 angepasst werden muss.
Defekte Abhängigkeit für libc6(Broken libc6 dependency)Einige Pakete verwenden eine fehlerhafte Abhängigkeit auf
libc6-dev. Das ist inkorrekt, dalibc6speziell für bestimmte GNU/Linux-Architekturen gilt. Das korrespondierende Paket für GNU lautetlibc0.3-dev, aber andere Betriebssysteme haben andere Pakete. Sie können das Problem in der Dateidebian/controldes Quellbaums ermitteln. Typische Lösungen sind u.A. die Erkennung des Betriebssystems mittelsdpkg-architectureund die Hardkodierung des Sonamens. Besser verwenden Sie ein logisches ODER, z.B.libc6-dev | libc6.1-dev | libc0.3-dev | libc0.1-dev | libc-dev, hierbei istlibc-devein virtuelles Paket, das für jeden Sonamen funktioniert. Sie dürfen es aber nur als letzte Option einsetzen.Undefinierte Referenz auf snd_*, SND_* nicht deklariertEinige Pakete verwenden ALSA selbst auf nicht Linux-Architekturen. Das Paket oss-libsalsa stellt einige Emulationen via OSS bereit, aber es beschränkt sich auf 1.0.5 und einige Funktionalitäten, wie alle Sequenzier-Operationen, werden nicht bereitgestellt.
Falls das Paket es ermöglicht, sollte die Unterstützung von ALSA auf
!linux-any-Architekturen deaktiviert werden (z.B. durch eineconfigure-Option) und ein[linux-any]-Kennzeichner sollte zu den ALSA-Build-Dependsund entsprechend das Gegenstück zuBuild-Conflictshinzugefügt werden, wieBuild-Conflicts: libasound2-dev [!linux-any].
