[ Port ] [ Debian GNU/Hurd ] [ Notizie ] [ Installazione ] [ CD di Hurd ] [ Documentazione ] [ Sviluppo ] [ Contatti ]

Debian GNU/Hurd

Sviluppo della distribuzione

Dischi di avvio

In questo momento non si sta lavorando su dischi per l'avvio nativo, comunque si stanno posando le loro fondamenta il che, qualche volta, comporta il port di singoli pacchetti. Se si vuole contribuire, si aiuti il progetto debian-installer e assicurarsi che i suoi componenti funzionino con Hurd.

Port dei pacchetti Debian

Se si desidera contribuire al port Debian GNU/Hurd è necessario aver confidenza con il sistema di pacchettizzazione Debian. Una volta fatto questo leggendo la documentazione disponibile e visitando l'angolo degli sviluppatori si dovrebbe essere in grado estrarre i pacchetti sorgente Debian e creare un pacchetto binario Debian. Per le persone più pigre è disponibile un corso rapido:

Recuperare i sorgenti e creare i pacchetti

L'estrazione di un pacchetto sorgente Debian richiede il file pacchetto_versione.dsc e i file che sono elncati al suo interno. La directory di compilazione Debian viene creata con il comando dpkg-source -x pacchetto_versione.dsc.

La costruzione del pacchetto avviene nella directory di compilazione Debian pacchetto-versione appena creata con tramite il comando dpkg-buildpackage -B -rsudo "-mMyName <MyEmail>". Al posto di -B si può usare -b per compilare le parti indipendenti dall'architettura del pacchetto. È possibile usare -rfakeroot al posto di -rsudo per usare il pacchetto fakeroot. Si può tralasciare -r se si compila da utente root. Infine è possibile aggiungere -uc per evitare di firmare il pacchetto con la chiave GPG.

Scegliere un pacchetto

Quale pacchetto richiede del lavoro? Ogni pacchetto che ancora non è stato portato e che deve essere portato. Questi cambiano continuamente quindi o si prende un pacchetto a caso oppure si controllano attentamente le informazioni del processo autobuilder sulla lista di messaggi debian-hurd.

Pacchetto che non devono essere portati

Alcuni di questi pacchetti, o delle loro parti, potrebbero essere portabili in futuro ma almeno per ora sono considerati non-portabili.

base/update, perché Hurd non necessita di un demone di aggiornamento (i filesystem si sincronizzano da soli). Per modificare l'intervallo di sincronizzazione si può usare fsysopts e regolare l'opzione --sync. Si possono impostare valori diversi dell'intervallo di sincronizzazione per ogni filesystem! Per farlo manualmente si usi l'utilità syncfs.
base/makedev, perché Hurd dispone della propria versione di questo script. Il pacchetto sorgente Debian contiene solo la versione specifica per Linux.
base/ld.so, perché Hurd non usa il linker fornito insieme alla libreria C GNU.
base/modconf e base/modutils, perché i moduli sono un concetto specifico di Linux.
base/netbase, perché le parti fornite da questo pacchetto non disponibili sono altamente specifiche del kernel Linux. Al suo posto Hurd usa inetutils.
base/pcmcia-cs, perché Hurd non ha nessun tipo supporto per PCMCIA (e se lo avrà probabilmente questo pacchetto risulterà specifico di Linux).
base/procps, perché il codice è specifico per il filesystem proc di Linux.
base/ppp e base/pppconfig, perché Hurd non ha nussun supporto per PPP (e se lo avrà probabilmente questo pacchetto risulterà specifico di Linux).
base/setserial, perché è specifico per il kernel Linux. Comunque con il port dei driver a caratteri di Linux su GNU Mach saremo in grado di usarlo.

Problemi generali del port

Questo è un elenco delle incompatibilità più comuni che possono incontrare quando si compila del software non sufficientemente portabile su Hurd.

Bad File Descriptor
Se si ottiene l'errore Bad File Descriptor quando si tenta di leggere da un file (o quando si tenta di accedervi) si controlli la chiamata a open(). Il secondo argomento è il metodo di accesso, se questo è un numero fisso e non uno dei simboli definiti nei file header standard il codice non è perfetto e deve essere corretto in modo che usi O_RDONLY, O_WRONLY o O_RDWR. Per esempio questo problema è stato riscontrato nei pacchetti fortunes e mtools.
PATH_MAX
Ogni uso incondizionato di PATH_MAX è incompatibile con POSIX. Se non ci sono limiti superiori alla lunghezza di un percorso questo simbolo non è definito in nessun file header, nel caso opposto si può usare una implementazione che non si fida della lunghezza della stringa oppure usare sysconf() per interrogare la lunghezza durante l'esecuzione; se sysconf() restituisce -1 si deve usare realloc() per allocare dinamicamente la memoria.
MAXHOSTNAMELEN
vedere PATH_MAX
MAXPATHLEN
vedere PATH_MAX
NOFILE
vedere PATH_MAX
#define specifiche di Hurd
Se è necessario includere del codice specifico per Hurd tramite #if...#endif, allora si può fare usando __GNU__, però pensateci almeno tre volte prima di farlo. In molte situazioni questo non è assolutamente necessario e crea molti più problemi di quanti ne può risolvere. È meglio chiedere cosa fare sulla lista di messaggi se non si riesce a trovare una soluzione migliore.
sys_errlist[] vs. strerror()
Se un programma ha solo il supporto per sys_errlist[] allora è necessario fare un po' di lavoro per riuscire a compilarlo con Hurd che non lo supporta e fornisce solo strerror(). Steinar Hamre ha scritto riguardo a strerror():
strerror() dovrebbe essere usato perché:
- È il modo previsto in POSIX.
- È localizzato.
- Gestisce segnali non validi e valori fuori dai limiti (miglior gestione degli errori, nessuna possibilità di buffer overflow e nessun rischio di sicurezza).
strerror() dovrebbe essere usato sempre se è disponibile. Sfortunatamente esistono ancora dei vecchi sistemi non-POSIX che non hanno strerror(), ma hanno solo sys_errlist[].

Oggi, il supporto del solo strerror() è molto meglio del solo supporto di sys_errlist[]. La cosa migliore (dal punto di vista del port) è il supporto di entrambi. In configure.in si deve:

AC_CHECK_FUNCS(strerror)

In config.h.in, si deve aggiungere:

#undef HAVE_STRERROR

E successivamente qualcosa di simile a:
```
        #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 */
```
Come esempio si può guardare le ultime fileutils (il codice precedente è una versione semplificata di ciò che contengono). Ovviamente le patch dovono essere inviate ai manutentori originali, Questo è molto utile anche per i sistemi che funzionano con sys_errlist[].
Nomi di file che finiscono con uno slash "/"
Questi sono una disgrazia se si vuole nominare una directory non esistente usando questa sintassi. Per esempio, mkdir foobar/ non funziona sotto Hurd ma è conforme a POSIX. POSIX permette che il percorso di una directory termini con degli slash, poiché la directory ancora non esiste il percorso non indica una directory e quindi non è garantito il funzionamento degli slash finali. Eliminate gli slash e tutto andrà benissimo.