¡Ojo! Esta traducción está muy desactualizada, por favor, consulte el documento original.

[ Adaptaciones ] [ Debian GNU/Hurd ] [ Noticias ] [ Configuración ] [ CDs de Hurd ] [ Documentación ] [ Desarrollo ] [ Contactos ]

Debian GNU/Hurd

Desarrollo de la distribución

Discos de arranque

En estos momentos no trabajamos en discos de arranque nativos. Sin embargo, estamos disponiendo los fundamentos necesarios para hacerlos, y a veces adaptamos paquetes individuales que son necesarios para dicha tarea. Si desea ayudarnos, trabaje en el proyecto debian-installer y asegúrese de que sus componentes se ejecutan en Hurd.

Adaptar paquetes de Debian

Si quiere ayudar con la arquitectura GNU/Hurd, debería familiarizarse con el sistema de empaquetado de Debian. Una vez que lo haya hecho, leyendo la documentación disponible y visitando el Rincón de los Desarrolladores debería saber cómo extraer los fuentes de los paquetes de Debian y compilar un paquete Debian. He aquí un curso acelerado para los muy perezosos:

Obtener el código fuente y construir paquetes

Para extraer el contenido de un paquete de fuentes de Debian se necesita el fichero package_version.dsc y los ficheros listados en él. El directorio de compilación de Debian se construye con la orden dpkg-source -x package_version.dsc

La construcción de un paquete se lleva a cabo en el nuevo directorio de construcción Debian package-version con la orden dpkg-buildpackage -B -rsudo "-mMiNombre <MiCorreo>". En lugar de -B se puede usar -b si también quiere construir las partes del paquete que son independientes de la arquitectura. Puede utilizar -rfakeroot en lugar de -rsudo, si utiliza el paquete fakeroot. Si está construyendo como usuario root, puede hacerlo sin -r. Puede añadir -uc para evitar firmar el paquete con su clave pgp.

Escoja uno

¿En que paquetes se necesita trabajar? Bien, cualquiera que aún no haya sido adaptado, y lo necesite. Esto cambia de forma constante, de manera que escoja al azar uno que no lo esté, o compruebe la información sobre el proceso de autocompilación en la lista de correos debian-hurd.

Paquetes que No Van a Ser Adaptados

Algunos de estos paquetes, o partes de ellos, podrían ser adaptables más adelante, pero, al menos actualmente, se consideran inadaptables.

base/update, porque el Hurd no necesita un demonio update (los sistemas de archivos se sincronizan ellos mismos). Para cambiar el intervalo de sincronización, puede utilizar fsysopts para ajustar la opción --sync. ¡Se puede establecer diferentes intervalos de sincronización para cada sistema de archivos! Para sincronizar manualmente, utilice la utilidad syncfs.
base/makedev, porque el Hurd viene con su propia versión de este guión. El paquete de fuentes de Debian sólo contiene una versión específica para Linux.
base/ld.so, porque el Hurd no utiliza el enlazador que se distribuye con la biblioteca de C de GNU.
base/modconf y base/modutils, porque el concepto de módulo es específico de Linux.
base/netbase, porque el resto de cosas que hay en él es muy específico del núcleo Linux. El Hurd, en su lugar, utiliza inetutils.
base/pcmcia-cs, porque el Hurd no da soporte para PCMCIA (e incluso si lo tuviese, este paquete es probablemente específico para Linux).
base/procps, porque este código es específico para el sistema de ficheros proc de Linux.
base/ppp y base/pppconfig, porque el Hurd no da ningún soporte para PPP (e incluso si lo tuviese, este paquete es probablemente muy específico para Linux).
base/setserial, porque es específico para el núcleo de Linux. Sin embargo, con la adaptación de los gestores de dispositivos de caracteres al Mach de GNU, quizá podamos utilizarlo.

Generalidades de la Adaptación

He aquí una lista de incompatibilidades comunes que puede encontrar cuando compile en el Hurd programas no suficientemente adaptables.

Descriptor de Archivo Erróneo
Si ve el error Bad File Descriptor cuando intenta leer un archivo (o acceder a él de algún modo), compruebe la llamada a open(). El segundo argumento es el método de acceso. Si tiene un número en lugar de uno de los símbolos definidos en los ficheros estándar de cabecera, el código es malo, y se debería arreglar o usar O_RDONLY, O_WRONLY o O_RDWR. Este error se ha observado en los paquetes fortunes y mtools, por ejemplo.
PATH_MAX
Cada uso sin condiciones de PATH_MAX es una incompatibilidad con POSIX. Si no hay límite superior para la longitud de un camino, este símbolo no está definido en ningún archivo de cabecera. En su lugar, necesita usar una implementación diferente que no dependa de la longitud de una cadena, o usar sysconf() para preguntar la longitud durante la ejecución. Si sysconf() devuelve -1, ha de usar realloc() para reservar de modo dinámico la memoria necesaria.
MAXHOSTNAMELEN
véase PATH_MAX
MAXPATHLEN
véase PATH_MAX
NOFILE
véase PATH_MAX
#define específico del Hurd
Si necesita incluir código específico para el Hurd utilizando #if...#endif, entonces puede usar el símbolo __GNU__ para hacerlo. !Pero antes piénselo (al menos) tres veces! En la mayoría de las situaciones, es completamente innecesario y creará más problemas de los que puede resolver. Mejor pregunte en las listas de correo cómo hacerlo correctamente si no se le ocurre una solución mejor.
sys_errlist[] vs. strerror():
Si un programa sólo tiene soporte para sys_errlist[] tendrá que hacer algún trabajo para hacerlo compatible en el Hurd, que ha dejado de dar soporte para esto y sólo proporciona strerror(). Steinar Hamre escribió lo siguiente acerca de strerror():
Se debería usarstrerror() porque :
- Es la forma moderna y POSIX.
- Está localizada.
- Gestiona señales/número no válidos fuera de rango. (mejor gestión de error y no un candidato a desbordamiento de buffer/riesgo de seguridad)
Si está disponible, se debería usar siempre strerror(). Desafortunadamente, todavía hay algunos viejos sistemas no POSIX que no tienen strerror(), sólo sys_errlist[].

Hoy, dar soporte sólo a strerror() es mucho mejor que dar soporte sólo a sys_errlist[]. Lo mejor (desde el punto de vista de la portabilidad), sin embargo, es dar soporte a ambos. Para configure.in, necesitará:

AC_CHECK_FUNCS(strerror)

Para config.h.in, necesitará añadir:

#undef HAVE_STRERROR

Luego, algo como:
```
        #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 */
```
Por ejemplo, puede mirar en el último fileutils (lo anterior es una versión simplificada de lo que encontré ahí.) Por supuesto, los parches se deberían enviar a los mantenedores principales, esto es muy útil incluso para sistemas en los que funciona sys_errlist[].
Nombres De Fichero Que Terminan En `/'
Son malvados si no existen y quiere darle un nombre así a un directorio. Por ejemplo, mkdir foobar/ no funcionará en el Hurd. Esto es compatible con POSIX. POSIX dice que el camino de un directorio puede tener `/' concatenados. Pero el directorio no existe todavía, así que el camino no se refiere a un directorio, y de ahí que no se garantice que los `/' al final funcionen. Simplemente, descarte los `/', y le irá bien.