Pt. arbejder vi ikke på "native" startdisketter. Vi er dog i gang med de foretage de indledende forberedelser, og tilpasser nogle gange nødvendige individuelle pakker. Hvis du vil hjælpe til, så arbejd på projektet debian-installer og forvis dig om at dets komponenter kører under Hurd.
Hvis du vil hjælpe til med tilpasningen af Debian GNU/Hurd, skal du gøre dig bekendt med Debians pakningssystem. Når det er gjort, ved at læse tilgængelig dokumentation og besøge udviklerhjørnet skulle du vide hvordan man udpakker Debians-kildekodepakker og opbygger en Debian-pakke. Her er et lynkursus til glæde for de meget dovne:
Udpakning af Debian-kildekodepakker kræver filen
package_version.dsc og filerne anført i den. Man oprette Debians
opbygningsmappe med kommandoen dpkg-source -x
package_version.dsc
Opbygning af en pakke foretages i det nu oprettede Debian-opbygningsmappe
package-version med kommandoen dpkg-buildpackage -B -rsudo
"-mMitNavn <MinEmail>". I stedet for -B kan man bruge
-b, hvis man også ønsker at opbygge de arkitekturuafhængige dele
af pakken. Man kan bruge -rfakeroot i stedet for
-rsudo hvis man bruger pakken fakeroot. -r er ikke
nødvendig hvis man bygger pakker som brugeren root. Man kan tilføje
-uc for at undgå signering af pakken med ens pgp-nøgle.
Hvilken pakke skal der arbejdes på? Enhver pakke som endnu ikke er tilpasset, men skal tilpasses. Dette ændrer sig hele tiden, så vælg enten en tilfældig pakke eller vær på udkig efter oplysninger om den automatiske opbygningsproces på postlisten debian-hurd.
Nogle af disse paker, eller dele af dem, kan måske tilpasses senere, men pt. vurderes de om ikke andet til at være umulige at tilpasse.
base/update, fordi Hurd ikke har brug for en update-dæmon
(filsystemerne synkroniserer sig selv). For at ældre
synkroniseringsintervallet kan man bruge fsysopts for at
justere på parameteret --sync. Man kan opsætte forskellige
synkroniseringsintervaller for hvert enkelt filsystem! For at gøre det
manuelt anvendes et syncfs-værktøj.base/makedev, fordi Hurd har sin egen version af dette
scipt. Debians kildekodepakke indeholder kun en Linux-specifik
version.base/ld.so, fordi Hurd bruger den linker som leveres med
GNU C-biblioteket.base/modconf og base/modutils, fordi moduler er
et Linux-specifikt koncept.base/netbase, fordi de resterende ting er meget specifikt
rettet med Linux-kernen. Hurd bruger i stedet
inetutils.base/pcmcia-cs, fordi Hurd ikke understøtter PCMCIA (og hvis
den gjorde, ville denne pakke formentlig være Linux-specifik).base/procps, fordi denne kode er specifikt rettet mod Linux'
proc-filsystem.base/ppp og base/pppconfig, fordi Hurd ikke
understøtter PPP (og hvis den gjorde, ville denne pakke formentlig være
Linux-specifik).base/setserial, fordi den er specifikt rettet mod
Linux-kernen. Dog vil vi måske kunne bruge den da Linux' char-drivere er
tilpasset til GNU Mach.Her er en liste over fælles inkompatibiliteter som man kan støde ind i når man oversætter programmel som ikke er tilstrækkeligt tilpasningsvenligt, under Hurd.
Bad File Descriptor
Hvis du får fejlen Bad File Descriptor når programmet
prøver at læse fra en fil (eller bare tilgå den), så undersøg kaldet af
open(). Det andet parameter er tilgangsmetoden. Hvis tallet er
hårdtkodet i stedet for et symbol defineret i standard-headerfilerne, er
koden forkert og bør rettes til enten at bruge
O_RDONLY, O_WRONLY eller
O_RDWR. Denne fejl blev blandt andre fundet i pakkerne
fortunes og mtools
PATH_MAX
Enhver ubetinget anvendelse af PATH_MAX er inkompatibel med
POSIX. Hvis der ikke er en øvre grænse på længen af en sti, er dette symbol
ikke defineret i nogen headerfil. I stedet skal du enten anvende en anden
implementering som ikke er afhængig af længden på en streng, eller bruge
sysconf() for at finde frem til længden under kørslen. Hvis
sysconf() returnerer -1 skal du bruge
realloc() for dynamisk at allokere den nødvendige
hukommelse.
MAXHOSTNAMELEN
se PATH_MAX
MAXPATHLEN
se PATH_MAX
NOFILE
se PATH_MAX
#define
Hvis du er nødt til at inkludere Hurd-specifik kode ved hjælp af
#if...#endif, så kan du bruge symbolet __GNU__
for at gøre dette. Men tænk dig om (mindst) tre! gange før du gør det. I
de fleste tilfælde er det fuldstændig unødvendigt og vil give
flere problemer end det måske kan løse. Spørg hellere på postlisten hvordan
dette gøres på den rigtige måde, hvis du ikke kan finde på en bedre
løsning.
sys_errlist[] mod strerror()
Hvis et program kun understøtter sys_errlist[] er du nødt
til at arbejde for at få det til at oversætte under Hurd, som har smidt
understøttelse for det væk og kun tilbyder strerror(). Steinar
Hamre skriver følgende om strerror():
strerror()bør anvendes fordi:
- Det der den moderne og POSIX-måde.
- Den er lokaliseret.
- Den håndterer ukorrekte signaler/number som er udenfor rækkefølge. (Bedre fejlhåndtering og ikke en kandidat til et bufferoverløb eller en sikkerhedsrisiko.)
strerror()bør altid anvendes hvis den er tilgængelig. Desværre er der stadig nogle gamle ikke-POSIX-systemer der ikke harstrerror(), men kunsys_errlist[].I dag er det meget bedre kun at understøtte
strerror(), end kun at understøttesys_errlist[]. Det bedste (fra et tilpasningssyspunkt), er dog at understøtte dem begge. Tilconfigure.inskal man bruge:
AC_CHECK_FUNCS(strerror)Til
config.h.inskal man tilføje:
#undef HAVE_STRERROROg dernæst noget i retning af:
#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 */Man kan for eksempel kigge i den seneste fileutils (ovenstående er en forenklet version af hvad jeg fandt dér). Rettelser (patches) bør selvfølgelig sendes til opstrømsvedligeholdere, dette er meget nyttigt, selv på systemer med en fungerende
sys_errlist[].
Disse er ondskabsfulde hvis de ikke eksisterer og du ønsker at
navngive en mappe på denne måde. For eksempel fungerer mkdir
foobar/ ikke under Hurd. Dette er POSIX-kompatiblet.
POSIX siger at en mappes sti kan slutte med en skråstreg. Men
mappen findes ikke endnu, hvorfor stien ikke refererer til en mappe,
og derfor er der ikke garanti for at afsluttede skråstreger vil
fungere. Smid skråstregerne væk og der vil ikke være problemer.