[RFR] wml://ports/hurd/hurd-devel-debian.wml

[Laura Arjona Reina <larjona99@gmail.com>]

Saludos
Laura Arjona

#use wml::debian::template title="Debian GNU/Hurd --- Desarrollo" NOHEADER="yes"
#use wml::debian::translation-check translation="1.52"
#include "$(ENGLISHDIR)/ports/hurd/menu.inc"

<h1>
Debian GNU/Hurd</h1>
<h2>
Desarrollo de la distribución</h2>

<h3>
Adaptar paquetes de Debian</h3>
<p>
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 <a
href="$(HOME)/devel/">Rincón de los Desarrolladores</a> 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:</p>

<h3>
Obtener el código fuente y construir paquetes</h3>
<p>
Se puede obtener el código fuente simplemente ejecutando <code>apt-get source
package</code>, que también extraerá los fuentes.
</p>

Para extraer el contenido de un paquete de fuentes de Debian se necesita
el fichero
<code>package_version.dsc</code> y los ficheros listados en él. El 
directorio de compilación de Debian se construye con la orden
 <code>dpkg-source -x package_version.dsc</code></p>
<p>
La construcción de un paquete se lleva a cabo en el nuevo directorio
de construcción Debian 
<code>package-version</code> con la orden 
<code>dpkg-buildpackage -B -rsudo "-mMiNombre &lt;MiCorreo&gt;"</code>.
En lugar de <code>-B</code> se puede
usar 
<code>-b</code> si también quiere construir las partes del paquete que 
son independientes de la arquitectura. Puede utilizar
 <code>-rfakeroot</code> en lugar de
<code>-rsudo</code>, si utiliza el paquete fakeroot. Si está construyendo
como usuario root, puede hacerlo sin <code>-r</code>. Puede añadir
<code>-uc</code> para evitar firmar el paquete con su clave pgp.</p>

<p>
La construcción puede necesitar que se instalen paquetes adicionales.
La manera más sencilla es ejecutar <code>apt-get build-dep package</code> 
que instalará todos los paquetes necesarios.
</p>

<h3>
Escoja uno</h3>
<p>
¿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 es preferible concentrarse primero en paquetes que tengan muchas
dependencias inversas, lo que puede verse en el gráfico de dependencias 
de paquetes <url "http://people.debian.org/~sthibault/graph-radial.pdf";>
que se actualiza cada día, o en la lista de más solicitados
<url "http://people.debian.org/~sthibault/graph-total-top.txt";> (ésta es
la de más solicitados a largo plazo, la de más solicitados a corto plazo es
<url "http://people.debian.org/~sthibault/graph-top.txt";>).
También suele ser buena idea escoger de la lista de desactualizados
<url "http://people.debian.org/~sthibault/out_of_date.txt";>, ya que ésos 
solían funcionar, y ahora están rotos probablemente sólo por un par de razones.

Puede simplemente escoger uno de los paquetes que faltan de manera aleatoria, 
o mirar los registros de autoconstrucción en la lista de correo debian-hurd-build-logs, 
o usar la lista wanna-build de 
<url "http://people.debian.org/~sthibault/failed_packages.txt.gz";> .
</p>
<p>
También, compruebe si ya se ha realizado trabajo en 
<url "http://alioth.debian.org/tracker/?atid=410472&amp;group_id=30628&amp;func=browse";>,
<url "http://alioth.debian.org/tracker/?atid=411594&amp;group_id=30628&amp;func=browse";>,
y el BTS (<url "http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-hurd@lists.debian.org;tag=hurd";>), y <url "http://wiki.debian.org/Debian_GNU/Hurd";>,
y el estado de los paquetes en vivo en buildd.debian.org, p.ej. 
<url "https://buildd.debian.org/util-linux";>.
</p>

<h4>
Paquetes que no van a ser adaptados
</h4>
<p>
Algunos de estos paquetes, o partes de ellos, podrían ser adaptables
más adelante, pero, al menos actualmente, se consideran inadaptables.
Normalmente se marcan como NotForUs en la base de datos de buildd.
</p>

<ul>
<li>
<code>base/makedev</code>, 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.</li>
<li>
<code>base/modconf</code> y <code>base/modutils</code>, porque el concepto
de módulo es específico de Linux.</li>
<li>
<code>base/netbase</code>, porque el resto de cosas que hay en él es 
muy específico del núcleo Linux. El Hurd, en su lugar, utiliza
<code>inetutils</code>.</li>
<li>
<code>base/pcmcia-cs</code>, porque este paquete es específico para
Linux.</li>
<li>
<code>base/setserial</code>, 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.</li>
</ul>

<h3><a name="porting_issues">
 Generalidades de la adaptación
</h3>
<p>
Se puede encontrar<a href=http://www.gnu.org/software/hurd/hurd/porting/guidelines.html>Una lista de asuntos comunes</a> en el sitio web del proyecto original.
Los siguientes asuntos comunes son específicos de Debian.</p>
<p>Antes de arreglar algo, compruebe si la adaptación kfreebsd* quizá ya tiene un arreglo,
y simplemente se debe extender a hurd-i386.</p>


<ul>
<li>
<code>Dependencia con libc6 rota</code>

<p>
Algunos paquetes dependen erróneamente de <code>libc6-dev</code>. Esto
es incorrecto porque <code>libc6</code> es específica a algunas arquitecturas de
GNU/Linux. El correspondiente paquete para GNU es <code>libc0.3-dev</code>
pero otros Sistemas Operativos tendrán otras diferentes. Puede localizar el problema 
en el fichero <code>debian/control</code> en el árbol de código fuente. Soluciones típicas
son detectar el SO usando <code>dpkg-architecture</code> e insertando en el código el soname,
o mejor, usar un OR lógico. P.ej.:
<code>libc6-dev | libc6.1-dev | libc0.3-dev | libc0.1-dev | libc-dev</code>.
El paquete <code>libc-dev</code> es un paquete virtual que funciona para cualquier soname
pero tiene que ponerlo sólamente como última opción.</p></li>
<li>
<code>referencia no definida a snd_*, SND_* no declarado</code>
<p>
Algunos paquetes usan ALSA incluso en arquitecturas no-Linux. El paquete oss-libsalsa 
proporciona alguna emulación sobre OSS, pero está limitado a 1.0.5, y no se proporcionan
algunas características, como las operaciones de secuenciador.
</p>
<p>
Si el paquete lo permite, el soporte de alsa debería deshabilitarse en 
las arquitecturas <code>!linux-any</code> (p.ej. a través de una opción
<code>configure</code>), y añadir un cualificador <code>[linux-any]</code> 
al <code>Build-Depends</code> de alsa, y el añadir el opuesto a 
<code>Build-Conflicts</code>, como <code>Build-Conflicts: libasound2-dev [!linux-any]</code>.
</p>
</li>
</ul>