[ Portierungen ] [ Debian GNU/Hurd ] [ Neues ] [ Installation ] [ Hurd-CDs ] [ Dokumentation ] [ Entwicklung ] [ Kontakt ]

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.

Eins auswählen

An welchem Paket sollte gearbeitet werden? An jedem, das noch nicht portiert wurde aber portiert werden muss. Das ändert sich ständig, also können Sie sich entweder eines der nicht portierten Pakete zufällig heraussuchen oder auf der debian-hurd Mailingliste nach Informationen über den autobuilding-Prozess Ausschau halten.

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 braucht (Die Dateisysteme synchronisieren sich selbst). Wollen Sie das Synchronisationsintervall ändern, können sie fsysopts verwenden, um die --sync Option zu einzustellen. Sie können für jedes Dateisystem ein anderes Synchronisationsintervall einstellen. Um dies manuell zu tun, benutzen Sie das syncfs-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/modconf und base/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 stattdessen inetutils.
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/ppp und base/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

Nachfolgend finden sie eine Liste mit verbreiteten Kompatibilitätsproblemen, auf die Sie stoßen könnten, wenn Sie schlecht portable Software auf dem Hurd kompilieren.

Ungültiger Dateideskriptor (Bad File Descriptor)
Wenn beim Versuch, aus einer Datei zu lesen (oder sonstwie auf sie zuzugreifen) ein Bad File Descriptor Fehler auftritt, sollten sie den open()-Aufruf überprüfen. Das zweite Argument ist die Zugriffsmethode. Wenn es eine feste Nummer anstatt eines in den Standard-Headerdateien definierten Symbols ist, dann ist der Code nicht portabel und sollte durch Benutzung eines der drei Symbole O_RDONLY, O_WRONLY oder O_RDWR gefixt werden. Dieser Fehler trat zum Beispiel in den Paketen fortunes und mtools auf.
PATH_MAX
Jede unbedingte Benutzung von PATH_MAX ist eine POSIX-Inkompatibilität. Wenn es kein oberes Limit für die Länge eines Pfades gibt wird dieses Symbol in keiner Headerdatei definiert. Stattdessen sollten Sie eine andere Implementierung benutzen, die nicht auf die Länge eines Strings angewiesen ist oder sysconf() benutzen, um die Länge zur Laufzeit zu ermitteln. Wenn sysconf() -1 zurückgibt, müssen Sie realloc() benutzen, um den benötigten Speicher dynamisch zu allozieren.
MAXHOSTNAMELEN
siehe PATH_MAX
MAXPATHLEN
siehe PATH_MAX
NOFILE
siehe PATH_MAX
hurdspezifisches #define
Wenn Sie speziellen Code für den Hurd mit Hilfe von #if...#endif einfügen müssen, können Sie das __GNU__-Symbol dafür benutzen. Aber denken Sie mindestens dreimal nach, bevor Sie das tun. In den meisten Situationen ist dies komplett unnötig und schafft mehr Probleme als es löst. Fragen Sie besser auf der Mailingliste nach einer besseren Lösung, wenn Ihnen keine einfällt.
sys_errlist[] vs. strerror()
Wenn ein Programm nur sys_errlist[] unterstützt, müssen Sie ein wenig Arbeit leisten, um es auf dem Hurd zum Kompilieren zu bringen, da dieser nur noch strerror() unterstützt. Steinar Hamre schreibt über strerror():
strerror() sollte benutzt werden weil:
- Es der moderne, POSIX-Weg ist.
- Es lokalisiert ist.
- Es ungültige Signale/Nummern außerhalb des erlaubten Bereichs verarbeitet. (Bessere Fehlerbehandlung und kein Pufferüberlauf-Kandidat/Sicherheitsrisiko)
Wenn verfügbar, sollte immer strerror() benutzt werden. Leider gibt es immer noch einige alte nicht-POSIX-Systeme, die kein strerror() haben, nur sys_errlist[].

Heute ist es wesentlich besser, nur strerror() zu unterstützen anstatt nur sys_errlist[]. Am besten (aus dem Blickwinkel der Portabilität) ist, beide zu unterstützen. Für configure.in brauchen Sie:

AC_CHECK_FUNCS(strerror)

In config.h.in müssen sie hinzufügen:

#undef HAVE_STRERROR

Und etwas wie:
```
        #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 */
	  
```
Sie können zum Beispiel in die neueste Version der fileutils schauen (das obige ist eine vereinfachte Version dessen, was ich dort gefunden habe.) Patches sollten natürlich an den ursprünglichen Betreuer weitergeleitet werden, das obige ist auch auf Systemen mit einem funktionierenden sys_errlist[] nützlich.
Dateinamen, die in einem Slash / enden.
Solche Dateinamen sind böse, wenn sie nicht existieren und Sie ein Verzeichnis so nennen wollen. mkdir foobar/ wird beim Hurd nicht funktionieren. Das ist POSIX-kompatibel. POSIX sagt, dass der Pfad eines Verzeichnisses am Ende angefügte Slashes haben darf. Aber das Verzeichnis existiert noch nicht, deshalb verweist der Pfad nicht auf ein Verzeichnis und so müssen abschließende Slashes nicht funktionieren. Entfernen Sie einfach die Slashes und alles ist ok.