| 1 |
chiguire 09/04/16 13:53:34 |
| 2 |
|
| 3 |
Added: faq.xml |
| 4 |
Log: |
| 5 |
new spanish translation (jose maria alonso) |
| 6 |
|
| 7 |
Revision Changes Path |
| 8 |
1.1 xml/htdocs/proj/es/releng/catalyst/faq.xml |
| 9 |
|
| 10 |
file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/es/releng/catalyst/faq.xml?rev=1.1&view=markup |
| 11 |
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/es/releng/catalyst/faq.xml?rev=1.1&content-type=text/plain |
| 12 |
|
| 13 |
Index: faq.xml |
| 14 |
=================================================================== |
| 15 |
<?xml version="1.0" encoding="UTF-8"?> |
| 16 |
<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?> |
| 17 |
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> |
| 18 |
<guide link="/proj/es/releng/catalyst/faq.xml" lang="es"> |
| 19 |
|
| 20 |
<title>FAQ de Catalyst</title> |
| 21 |
<author title="Author">John P. Davis</author> |
| 22 |
<author title="Author">Daniel Robbins</author> |
| 23 |
<author title="Contributor">William Kilian</author> |
| 24 |
<author title="Editor">Chris Gianelloni</author> |
| 25 |
<author title="Traductor"> |
| 26 |
<mail link="gentoo@××××××.org">José María Alonso</mail> |
| 27 |
</author> |
| 28 |
|
| 29 |
<abstract> |
| 30 |
Preguntas frecuentes relacionadas con la herramienta Catalyst. |
| 31 |
</abstract> |
| 32 |
|
| 33 |
<version>1.1</version> |
| 34 |
<date>2008-02-05</date> |
| 35 |
|
| 36 |
<chapter> |
| 37 |
<title>Preguntas Frecuentes</title> |
| 38 |
|
| 39 |
<section> |
| 40 |
<title>¿Cómo construyo un tarball stage2 y stage3 para un tipo de CPU |
| 41 |
no genérico como pentium4?</title> |
| 42 |
<body> |
| 43 |
|
| 44 |
<p> |
| 45 |
En primer lugar, asegúrese de que su hardware es capaz de construir |
| 46 |
ese stage. Si desea construir un stage <c>pentium4</c> necesitará |
| 47 |
construirlo en un sistema Pentium 4 o AMD64/Opteron (o superior). No |
| 48 |
puede construir un stage <c>pentium4</c> en un sistema Athlon XP, ya |
| 49 |
que las CPUs Athlon XP no soportan las instrucciones SSE2, y estas |
| 50 |
instrucciones se activan para los stages <c>pentium4</c>. Del mismo |
| 51 |
modo, si desea construir un stage <c>g4</c>, necesitará hacerlo en un |
| 52 |
sistema PowerPC G4 o G5. |
| 53 |
</p> |
| 54 |
|
| 55 |
<p> |
| 56 |
Una vez se haya asegurado de que está construyendo en el hardware |
| 57 |
correcto, simplemente siga los pasos de arriba. Para construir el |
| 58 |
stage2, simplemente cambie el ajuste <c>subarch</c> a una |
| 59 |
subarquitectura no genérica válida (p.e. <c>pentium4</c>). Entonces su |
| 60 |
stage2 será construido para la subarquitectura que especificó. A |
| 61 |
continuación, use este stage2 como el stage "semilla" para construir |
| 62 |
su stage3. Por supuesto, puede que quiera también modificar el ajuste |
| 63 |
<c>subarch</c> en su fichero spec del stage3 para que concuerde con el |
| 64 |
que usó en su fichero spec para el stage2. |
| 65 |
</p> |
| 66 |
</body> |
| 67 |
</section> |
| 68 |
|
| 69 |
<section> |
| 70 |
<title>Quiero construir unos cuantos stages para varias |
| 71 |
subarquitecturas. ¿Cómo debo hacer esto?</title> |
| 72 |
<body> |
| 73 |
|
| 74 |
<p> |
| 75 |
En primer lugar, construya un stage1 genérico. Entonces use este |
| 76 |
stage1 para construir los stage2 y stage3 específicos. Use el stage1 |
| 77 |
de nuevo para construir otro stage2 y stage2 específicos. No necesita |
| 78 |
reconstruir el stage1 -- todos sus stage2 y stage3 específicos pueden |
| 79 |
usar el mismo stage1 "semilla". |
| 80 |
</p> |
| 81 |
</body> |
| 82 |
</section> |
| 83 |
|
| 84 |
<section> |
| 85 |
<title>¿Puedo construir un stage1 para un tipo de CPU no |
| 86 |
genérico?</title> |
| 87 |
<body> |
| 88 |
|
| 89 |
<p> |
| 90 |
Esto es muy mala idea, ya que los usuarios esperan que el stage1 va a |
| 91 |
funcionar en cualquier tipo de subarquitectura. De esta forma, pueden |
| 92 |
usar el stage1 en cualquier sistema sin preocuparse. Debe estar seguro |
| 93 |
de no "contaminar" su stage1 con código específico de una CPU no |
| 94 |
genérica. Siempre use un stage3 "genérico" como semilla para construir |
| 95 |
un nuevo stage1. |
| 96 |
</p> |
| 97 |
</body> |
| 98 |
</section> |
| 99 |
|
| 100 |
<section> |
| 101 |
<title>Creía que catalyst podía construir stages "desde cero". Si |
| 102 |
catalyst construye los stages desde cero, entonces ¿Porqué se necesita |
| 103 |
un "stage semilla"? |
| 104 |
</title> |
| 105 |
<body> |
| 106 |
|
| 107 |
<p> |
| 108 |
Buena pregunta. Como sabe, los stage2 y stage3 dependen de los stages |
| 109 |
previos para la construcción, la cual se especifica y define por su |
| 110 |
nombre (p.e. un "stage2" implica que hubo un "stage1"). Sin embargo |
| 111 |
catalyst necesita un stage semilla para construir un stage1, por lo |
| 112 |
que en lo que a la construcción de un stage1 se refiere, merece la |
| 113 |
pena comprobar porque esto es necesario. Cuando se construye un |
| 114 |
stage1, catalyst usa como semilla un stage3 para preparar un entorno |
| 115 |
chroot. Dentro de este entorno chroot, el nuevo stage1 es construido |
| 116 |
ajustando la variable de entorno <c>ROOT</c> a |
| 117 |
<path>/tmp/stage1root</path>. Esto ordena al gestor de paquetes que |
| 118 |
haga emerge de todos los nuevos paquetes, no en el sistema de ficheros |
| 119 |
actual, sino en el sistema de ficheros localizado en |
| 120 |
<path>/tmp/stage1root</path>. Catalyst, entonces empaqueta |
| 121 |
<path>/tmp/stage1root</path> y éste se convierte en el stage1 |
| 122 |
objetivo. Esto significa que cuando catalyst construye un stage1, el |
| 123 |
stage2 en sí mismo no hereda ningún binario ni librería del stage1 |
| 124 |
semilla que ha usado. La semilla que se usa <e>afecta</e> al stage1 |
| 125 |
destino de alguna forma -- Los ficheros cabecera de Linux en la |
| 126 |
semilla son usados para construir la librería glibc del stage1, y los |
| 127 |
compiladores presentes en la semilla son usados para compilar todos |
| 128 |
los programas en el stage1. El stage semilla es usado para aislar el |
| 129 |
proceso de construcción del stage1 de su sistema local, y también |
| 130 |
permite, por ejemplo, construir stage1 para x86 en sistemas amd64. |
| 131 |
</p> |
| 132 |
</body> |
| 133 |
</section> |
| 134 |
|
| 135 |
<section> |
| 136 |
<title>¿Existe un HOWTO oficial para Catalyst?</title> |
| 137 |
<body> |
| 138 |
|
| 139 |
<p> |
| 140 |
Actualmente, no hay un HOWTO oficial. Si está interesado en escribir |
| 141 |
uno, por favor, abra una incidencia con el HOWTO adjunto. Sin embargo, |
| 142 |
la falta de un HOWTO oficial no significa que catalyst este |
| 143 |
completamente indocumentado. Cuando se hace emerge de catalyst, un |
| 144 |
conjunto bien comentado de ficheros spec ejemplo se instalan en |
| 145 |
<path>/usr/share/doc/catalyst-$version/examples</path>. |
| 146 |
</p> |
| 147 |
|
| 148 |
<p> |
| 149 |
Si aún tiene preguntas después de leer los ejemplos, suscríbase a la |
| 150 |
lista de correo gentoo-catalyst. |
| 151 |
</p> |
| 152 |
</body> |
| 153 |
</section> |
| 154 |
|
| 155 |
<section> |
| 156 |
<title>¿Dónde pongo los ajustes use, mask, etc. para cada |
| 157 |
paquete?</title> |
| 158 |
<body> |
| 159 |
|
| 160 |
<p> |
| 161 |
Catalyst soporta los ficheros de configuración presentes en |
| 162 |
/etc/portage. Simplemente añada lo siguiente a su fichero spec, y |
| 163 |
asegúrese igualmente de que usa el mismo ajuste <c>portage_confdir</c> |
| 164 |
para sus stages semilla: |
| 165 |
</p> |
| 166 |
|
| 167 |
<p> |
| 168 |
portage_confdir: /camino/a/personal/etc/portage |
| 169 |
</p> |
| 170 |
</body> |
| 171 |
</section> |
| 172 |
|
| 173 |
<section> |
| 174 |
<title>¿Debo realmente construir mi propio stage1 o simplemente usar |
| 175 |
uno de un servidor réplica de Gentoo?</title> |
| 176 |
<body> |
| 177 |
|
| 178 |
<p> |
| 179 |
La mejor práctica es construir <b>siempre</b> sus propios stages si no |
| 180 |
está usando la misma instantánea (snapshot) que fue utilizada para |
| 181 |
construir la última release. El estado del árbol de Portage depende |
| 182 |
mucho de sí mismo. Si dispone de un stage1 de hace 3 meses, es muy |
| 183 |
probable que tenga problemas con paquetes que bloquean a otros y |
| 184 |
cambios en el árbol que causarán que la construcción dé problemas de |
| 185 |
compatibilidad. |
| 186 |
</p> |
| 187 |
</body> |
| 188 |
</section> |
| 189 |
|
| 190 |
<section> |
| 191 |
<title>¿Cómo mantengo mis paquetes GRP/stages/LiveCD |
| 192 |
actualizados?</title> |
| 193 |
<body> |
| 194 |
|
| 195 |
<p> |
| 196 |
Catalyst usa Portage para todo el trabajo de construcción, de este |
| 197 |
modo lo único que debe hacer es regenerar su instantánea de Portage y |
| 198 |
reconstruir su GRP/stages/LiveCD. Portage seguirá todas sus reglas |
| 199 |
normalmente para decidir qué paquetes deben ser actualizados. |
| 200 |
</p> |
| 201 |
</body> |
| 202 |
</section> |
| 203 |
|
| 204 |
<section> |
| 205 |
<title>¿Usa Catalyst alguna sintaxis de ajustes USE especial?</title> |
| 206 |
<body> |
| 207 |
|
| 208 |
<p> |
| 209 |
No, la sintaxis de los ajustes USE en catalysts es exactamente la |
| 210 |
misma que en portage. |
| 211 |
</p> |
| 212 |
</body> |
| 213 |
</section> |
| 214 |
</chapter> |
| 215 |
</guide> |
Archives