aboutsummaryrefslogtreecommitdiffstats
path: root/spanish/ports/hurd/hurd-devel-debian.wml
blob: e57b5cfa062fc178e1d93e50c13db2286388ecbd (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
#use wml::debian::template title="Debian GNU/Hurd --- Desarrollo" NOHEADER="yes"
#use wml::debian::translation-check translation="1.54"
#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>

<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"> .
</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 "https://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
</a></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> 

© 2014-2024 Faster IT GmbH | imprint | privacy policy