Re: Actualización de la maint-guide -- revisión
Ana Guerrero wrote:
Hola fer y *:
Perdona por ser tan plasta, pero ¿que versión es? No es como la versión
1.2.3 en inglés..
Si es la 1.2.3 lo pone al inicio:
<version>versión 1.2.3, 18 de Enero 2005.</version>
Falta algun parrafo y otros tienen distinta forma, como esto:
<p>Como nuevo desarrollador, está desaconsejado crear
paquetes multibinarios, o bibliotecas, como se explicó antes. No es
extremadamente difícil, pero sí necesita algunos conocimientos más,
así que aquí no describiremos el proceso.
Once again, as a new maintainer you are discouraged from creating
complicated packages, e.g.,
* multiple binary packages,
* library packages,
* the source file format being neither in `tar.gz.' nor `tar.bz2',
or
* the source tarball containing undistributable contents.
It's not too hard, but it does require a bit more knowledge, so we
won't describe all of it here.
No, ese párrafo no es así en lo que he enviado, está adaptado a la nueva
versión inglesa:
<p>Como nuevo desarrollador, se desaconseja crear paquetes complicados, por
ejemplo,
<list compact>
<item>paquetes multibinarios,
<item>paquetes de bibliotecas,
<item>el formato del archivo fuente no debería estar en <tt>tar.gz.</tt> ni
en <tt>tar.bz2</tt>, o
<item>que las fuentes contenga contenidos no distribuibles.
</list> <!-- se podria traducir mejor esto... Ana -->
No es extremadamente difícil, pero sí necesita algunos conocimientos más,
así que aquí no describiremos el proceso.
Incluso tiene un comentario mio, cque no me suena nada bien la palabra
distribuible.
Así que no se que hacer.. ¿ideas?
¿Seguro que estás con la 1.2.3 y no con la 1.2?
Ana
______________________________________________
Renovamos el Correo Yahoo!
Nuevos servicios, más seguridad
http://correo.yahoo.es
Ahi va lo que he encontrado.
Lo unico que alguna vez utilizas el termino fichero y alguna archivo,
creo que quedaría mejor utilizar siempre el mismo (por ejemplo: «Si tu
programa viene en otro tipo de archivo (por ejemplo, el fichero termina
en «.Z» o «.zip»»)
Un saludo.
--- maint-guide.es.sgml 2005-09-03 17:28:49.000000000 +0200
+++ maint-guide.es.sgml.mod 2005-09-04 00:17:45.000000000 +0200
@@ -68,9 +68,9 @@
importantes del mercado es su sistema de paquetes. Aunque hay una
gran cantidad de programas disponibles en forma de paquetes de
Debian, algunas veces necesitarás instalar programas que no están
- disponible en este formato. Puedes que te preguntes cómo hacer
+ disponible en este formato. Puede que te preguntes cómo hacer
tus propios paquetes y que pienses que
- quizás ésta es una tarea demasiada difícil. Bueno, si eres un
+ quizás ésta es una tarea demasiado difícil. Bueno, si eres un
principiante en Linux, sí es duro, pero si eres un novato, no
deberías estar leyendo esto ahora mismo. :-) Necesitas saber algo
sobre programación en Unix, pero desde luego, no tienes que ser un
@@ -210,7 +210,7 @@
</list>
- <p>Por último, a documentación que se indica a continuación es de <em>gran importancia</em> y debería leerse junto con este documento:
+ <p>Por último, la documentación que se indica a continuación es de <em>gran importancia</em> y debería leerse junto con este documento:
<list>
<item><package/debian-policy/ - incluye la estructura y contenidos
@@ -256,7 +256,6 @@
<p>Debian usa el término desarrollador («maintainer», N. del T.) para la persona
que hace paquetes, autor original («upstream author», N. del T.) para la persona que hizo el programa, y desarrollador original («upstream
maintainer», N. del T.) para la persona que actualmente mantiene el
- maintainer', N. del T.) para la persona que actualmente mantiene el
programa fuera de Debian. Generalmente el autor y el desarrollador
fuente son la misma persona - y algunas veces incluso el
desarrollador es el mismo. Si haces un programa, y quieres
@@ -298,7 +297,7 @@
<tt/apt-get source nombrepaquete/) y examínalas.
Este documento, desafortunadamente, no incluye información exhaustiva
sobre la adopción de paquetes.
- No debería ser difícil averigua como funciona el paquete,
+ No debería ser difícil averiguar como funciona el paquete,
ya que alguien ha hecho el trabajo inicial por ti.
Aun así sigue leyendo, muchos de los consejos que siguen serán aplicables
para tu caso.
@@ -396,8 +395,8 @@
/usr/local/bin; no harás esto, pero eso lo veremos más adelante en
<ref id="destdir">).
- <p>El proceso varía de programa a programa, pero gran parte de los
- programas modernos vienen con un programa «configure» que configura
+ <p>El proceso varía de un programa a otro, pero gran parte de los
+ programas modernos vienen con un guión «configure» que configura
las fuentes para tu sistema y se asegura de que está en
condiciones de compilarlo. Después de configurarlo (con
«./configure»), los programas generalmente se compilan con «make».
@@ -406,13 +405,13 @@
directorios de destino ejecutando «make install».
<p>Ahora intenta compilar, y ejecutar el programa, para asegurarte
- de que funciona bien y de que no rompe nada más mientras está
+ de que funciona bien y de que no rompe nada mientras está
instalándose o ejecutándose.
- <P>También, generalmente, puedes escribir «make uninstall» para
- eliminar todos los programas instalados, y «make clean» (o mejor
+ <P>También, generalmente, puedes ejecutar «make clean» (o mejor
«make distclean») para limpiar el directorio donde se genera el
- programa.
+ programa. A veces hay incluso un «make uninstall» que se puede utilizar
+ para borrar todos los archivos instalados.
<sect id="namever">Nombre del paquete y versión
@@ -467,7 +466,7 @@
información que aparece en la pantalla y confirma pulsando la tecla
<intro>.
- <p>Tras ejecutar <prgn>dh_make</prgn>, se crea una copia del código original con el nombre <file>gentoo_0.9.12.orig.tar.gz</file> en el directorio raíz para facilitar la creación del paquete de fuentes no nativo de Debian con el <file>diff.gz</file>.
+ <p>Tras ejecutar <prgn>dh_make</prgn>, se crea una copia del código original con el nombre <file>gentoo_0.9.12.orig.tar.gz</file> en el directorio raíz para facilitar la creación del paquete de fuentes no nativo de Debian con el <file>diff.gz</file>.
Observa que hay dos cambios clave en este nombre de fichero:
<list compact>
<item>El nombre del paquete y la versión están separados por «<tt>_</tt>» .
@@ -480,7 +479,7 @@
<item>paquetes de bibliotecas,
<item>el formato del archivo fuente no debería estar en <tt>tar.gz.</tt> ni en
<tt>tar.bz2</tt>, o
- <item>que las fuentes contenga contenidos no distribuibles.
+ <item>que las fuentes contengan partes que no se puedan distribuir.
</list> <!-- se podria traducir mejor esto... Ana -->
No es extremadamente difícil, pero sí necesita algunos conocimientos más,
@@ -516,12 +515,12 @@
de info para automake, mientras que editar Makefile.in's es casi
lo mismo que editar ficheros Makefile, simplemente basta con poner
atención en las variables, es decir, cualquier cadena que empiece y
- acabe con el carácter «@», como por ejemplo @CFLAGS@ o @LN_S@, que se rellenan
- con cada vez que se ejecute «./configure». Por favor, lee
+ acabe con el carácter «@», como por ejemplo @CFLAGS@ o @LN_S@, que se
+ reemplazan cada vez que se ejecute «./configure». Por favor, lee
<file>&autotools-dev;</file> antes de empezar.
<p>Observa que aquí no hay espacio para entrar en
- <em>todos</em> los detalles respecto a los arreglos de la fuente original, pero a continuación,están algunos de los problemas frecuentes.
+ <em>todos</em> los detalles respecto a los arreglos de la fuente original, pero a continuación están algunos de los problemas frecuentes.
<sect id="destdir">Instalación en un subdirectorio
@@ -531,7 +530,7 @@
encuentre la documentación y páginas de manual en los lugares
habituales. Sin embargo, si lo instalas de esta forma, el programa
se instalará con los demás binarios que ya están en tu sistema.
- Esto dificultará a las herramientas de paquetes, averiguar que
+ Esto dificultará a las herramientas de paquetes averiguar que
archivos pertenecen a tu paquete y cuales no.
<p>Por lo tanto, necesitas hacer algo más: instalar el programa en
@@ -574,7 +573,7 @@
ICONS = /usr/local/share/gentoo/
</example>
- <p>Vemos que los ficheros está configurados para instalarse bajo
+ <p>Vemos que los ficheros están configurados para instalarse bajo
<file>/usr/local</file>.
Cambia estas rutas a:
@@ -697,7 +696,7 @@
</example>
<p>(El autor se ha dado cuenta de que este no es el mejor ejemplo ya que ahora
- el paquete libncurses es un enlace simbólico a libcurses.so, pero no pudo pensar
+ el paquete libncurses es un enlace simbólico a libcurses.so, pero no puedo pensar
uno mejor. Cualquier sugerencia sería muy bien recibida :-)
<chapt id="dreq">Las cosas necesarias bajo debian/
@@ -778,7 +777,7 @@
<p>La línea 5 incluye la lista de paquetes requeridos para construir
tu paquete. Algunos paquetes como gcc y make están implícitos,
consulta el paquete <package/build-essential/ para más detalles.
- Si algún compilador no estándar u otra herramienta, es necesaria
+ Si algún compilador no estándar u otra herramienta es necesaria
para construir tu paquete, deberías añadirla en la línea «Build-Depends».
Las entradas múltiples se separan con comas; lee la explicación de las
dependencias binarias para averiguar más sobre la sintaxis de este campo.
@@ -1103,7 +1102,7 @@
</example>
(He añadido los números de línea).
- <p>Puede leer más sobre como actualizar el fichero changelog más
+ <p>Puedes leer más sobre como actualizar el fichero changelog más
adelante en <ref id="update">.
<sect id="rules">El fichero «rules»
@@ -1229,7 +1228,7 @@
82 .PHONY: build clean binary-indep binary-arch binary install
</example>
(He añadido los números de línea. En el actual fichero <file>debian/rules</file>
- los espacios iniciales de las línas son códigos de TAB).
+ los espacios iniciales de las líneas son códigos de TAB).
<p>(N. del T.: se traduce el fichero de reglas, dh_make sólo lo
ofrece en inglés)
@@ -1501,7 +1500,7 @@
no marcar el fichero como un «conffile».
<p>Puedes tomar ejemplos de ficheros de configuración de los
- «programas de desarrollador» (N. del T. «maintainer scripts»),
+ «guiones de desarrollador» (N. del T. «maintainer scripts»),
para más información véase <ref id="maintscripts">.
<p>Si tu programa no tiene «conffiles», puedes eliminar el fichero
@@ -1743,7 +1742,7 @@
<sect id="maintscripts">postinst.ex, preinst.ex, postrm.ex y prerm.ex
- <p>Estos ficheros se llaman programas del desarrollador (maintainer
+ <p>Estos ficheros se llaman guiones del desarrollador (maintainer
scripts, N. del T.), y son guiones que se colocan en el área de
control del paquete y que <package/dpkg/ ejecuta cuando tu paquete se instala,
se actualiza o se elimina.
@@ -1870,7 +1869,7 @@
DEBUILD_DPKG_BUILDPACKAGE_OPTS="-i -ICVS -I.svn"
</example>
Con estos valores, puedes construir paquetes siempre con tu clave GPG y evitar
- incluir incluir componentes no deseadas. (Esto es bueno para esponsorizar también).
+ incluir componentes no deseados. (Esto es bueno para patrocinar también).
Por ejemplo, limpiar el código y reconstruir el paquete desde una cuenta de usuario es tan simple como:
<p><example>
@@ -1882,11 +1881,11 @@
<p>
El uso de las órdenes <prgn>dh_make</prgn> y <prgn>dpkg-buildpackage</prgn> creará un gran fichero
<file>diff.gz</file> que contendrá los archivos de mantenimiento del paquete en <file>debian/</file>
- y parcheara los ficheros fuentes. Este paquete es un poco engorroso de inspeccionar y entender para
- cada una de las modificaciones de código posteriores. Asi que no queda demasiado bonito.
+ y parcheará los ficheros fuentes. Este paquete es un poco engorroso de inspeccionar y entender para
+ cada una de las modificaciones de código posteriores. Así que no queda demasiado bonito.
<footnote>
- Si no eres todavia un Desarrollador de Debian y le pides a tu sponsor que te suba un paquete tras su
- revisión, deberias hacer el paquete lo más facil posible para su revisión.
+ Si no eres todavía un Desarrollador de Debian y le pides a tu patrocinador que te suba un paquete tras su
+ revisión, deberías hacer el paquete lo más fácil posible para su revisión.
</footnote>
<p>
@@ -1896,11 +1895,11 @@
<p>
Un paquete que haya sido empaquetado correctamente con el sistema <prgn>dpatch</prgn> tiene
- modificaciones ael código fuente claramente documentadas como un conjunto de ficheros parche
+ modificaciones al código fuente claramente documentadas como un conjunto de ficheros parche
en <file>debian/patches/</file> y el árbol de código permanece sin modificar fuera del
directorio <file>debian/</file>.
- Si le pides a un sponsor que suba tu paquete, este tipo de clara separación y documentación de
- tus cambios son muy impottantes para acelerar la revisión del paquete por el sponsor.
+ Si le pides a un patrocinador que suba tu paquete, este tipo de separación clara y documentación de
+ tus cambios son muy importantes para acelerar la revisión del paquete por el patrocinador.
El modo de empleo de <prgn>dpatch</prgn> se explica en <manref section="1" name="dpatch">.
<p>
@@ -1910,7 +1909,7 @@
<item>Edita el parche para crear un parche -p1 sobre el árbol el código fuente.
<item>Añade una cabecera empleando la orden <prgn>dpatch patch-template</prgn>.
<item>Mételo en <file>debian/patches</file>
- <item>Aañade el nombre de fichero de este parche dpatch a <file>debian/patches/00list</file>
+ <item>Añade el nombre de fichero de este parche dpatch a <file>debian/patches/00list</file>
</list>
<p>
Además, <prgn>dpatch</prgn> puede crear parches dependientes de la arquitectura
@@ -1918,7 +1917,7 @@
<sect id="option-sa">Incluir <file>orig.tar.gz</file> para subir
<p>Cuando subes por primera vez un paquete al archivo, necesitas incluir las fuentes originales
- <file>orig.tar.gz</file>. Si la version del paquete no es una revisión de Debian <tt>-0</tt> o
+ <file>orig.tar.gz</file>. Si la versión del paquete no es una revisión de Debian <tt>-0</tt> o
<tt>-1</tt>, debes proporcionarle a la orden <prgn>dpkg-buildpackage</prgn> la opción «<tt>-sa</tt>».
Por otro lado, la opción «<tt>-sd</tt>» forzará la exclusión del código original
<file>orig.tar.gz</file>.
@@ -1978,8 +1977,8 @@
<p>Puedes comparar la lista de ficheros de dos paquetes binarios de Debian
con la orden <manref name="debdiff" section="1">.
Esto es muy útil para verificar que no haya ficheros que se hayan cambiado de
- sitio o eliminado por error, y que ningún otro cambio no deseado, pase
- inadvertido cuando se actualize el paquete.
+ sitio o eliminado por error, y que ningún otro cambio no deseado pase
+ inadvertido cuando se actualice el paquete.
Puedes comprobar un grupo de ficheros <file>*.deb</file> simplemente con
«<tt>debdiff paquete-viejo.change paquete-nuevo.change</tt>».
@@ -2171,7 +2170,7 @@
<sect id="upload-private">Enviar a un archivo privado
- <p>Si quieres crear un archivo personal de paquetes en
+ <p>Si quieres crear un repositorio personal de paquetes en
<tt>URL="http://people.debian.org/~<var>nombre_de_cuenta</var>"</tt> como un
desarrollador con una simple llamada a
<tt>dupload -t <var>nombre_de_objetivo</var></tt>,
@@ -2179,7 +2178,7 @@
<!-- lo de arriba no ha quedao muy claro que se diga... Ana-->
<example>
- # Cuenta de desarollador
+ # Cuenta de desarrollador
$cfg{'<var>nombre_de_objetivo</var>'} = {
fqdn => "people.debian.org",
method => "scpb",
@@ -2189,7 +2188,7 @@
};
$cfg{'<var>nombre_de_objetivo</var>'}{preupload}{'changes'} = "
echo 'mkdir -p public_html/package' | ssh people.debian.org 2>/dev/null ;
- echo 'Directorio de paquetes creado!'";
+ echo '¡Directorio de paquetes creado!'";
$cfg{'<var>nombre_de_objetivo</var>'}{postupload}{'changes'} = "
echo 'cd public_html/package ;
@@ -2197,16 +2196,16 @@
dpkg-scansources . /dev/null >Sources || true ;
gzip -c Packages >Packages.gz ;
gzip -c Sources >Sources.gz ' | ssh people.debian.org 2>/dev/null ;
- echo 'Archivo de paquetes creado!'";
+ echo '¡Archivo de paquetes creado!'";
</example>
- Aqui, el repositorio APT se construye mediante una simple ejecución remota con SSH.
- Los ficheros override necesarios para <prgn>dpkg-scanpackages</prgn> y <prgn>dpkg-scansources</prgn>
+ Aquí, el repositorio APT se construye mediante una simple ejecución remota con SSH.
+ Los ficheros de sobreescritura que necesitan <prgn>dpkg-scanpackages</prgn> y <prgn>dpkg-scansources</prgn>
se especifican como <file>/dev/null</file>.
- Esta técnica puede ser empleada por alguien que no es desarrollador de Debian
+ Esta técnica la puede emplear alguien que no es desarrollador de Debian
para almacenar sus paquetes en su página personal. Como alternativa, se pueden
- usar <prgn>apt-ftparchive</prgn> o otros guiones para crear un archivo APT.
+ usar <prgn>apt-ftparchive</prgn> o otros guiones para crear un repositorio APT.
<chapt id="update">Actualizar el paquete
@@ -2262,7 +2261,7 @@
<p>Por supuesto, reemplaza este nombre de fichero con el nombre de las
fuentes de tu programa. <manref name="uupdate" section="1">
renombrará apropiadamente este fichero tar, intentará aplicar los
- cambios de tu fichero .<file>.diff.gz</file>, previo y actualizará el nuevo fichero
+ cambios de tu fichero <file>.diff.gz</file> previo y, actualizará el nuevo fichero
<file>debian/changelog</file>.
<item>Cambia al directorio <file>../gentoo-0.9.13</file>, el nuevo directorio
@@ -2290,7 +2289,7 @@
<list compact>
<item>De las fuentes, lee los ficheros <file>changelog</file>, <file>NEWS</file>,
- y cualquier otra documentacion que se haya publicado con la nueva versión.
+ y cualquier otra documentación que se haya publicado con la nueva versión.
<item>Ejecuta «<tt>diff -urN</tt>» entre las fuentes viejas y las nuevas para
obtener una visión del alcance de los cambios, donde se ha trabajado más
@@ -2301,17 +2300,17 @@
<item>
Porta el paquete Debian viejo a la nueva versión.
<list compact>
- <item>Descomprime el código fuente original y renombra la raiz del árbol de las fuentes como
- <file><nombrepaquete>-<version>/</file> y haz
+ <item>Descomprime el código fuente original y renombra la raíz del árbol de las fuentes como
+ <file><nombrepaquete>-<versión>/</file> y haz
«<tt>cd</tt>» en este directorio.
<item>Copia el código fuente en el directorio padre y renombrarlo como
- <file><nombrepaquete>_<version>.orig.tar.gz</file> .
+ <file><nombrepaquete>_<versión>.orig.tar.gz</file> .
<item>Aplica el mismo tipo de modificación a el nuevo código que al viejo.
Algunos métodos posibles son:
<list compact>
- <item>orden «<tt>zcat <var>/path/to/</var><nombrepaquete>_<version-vieja>.diff.gz | patch -p1</tt>»,
+ <item>orden «<tt>zcat <var>/path/to/</var><nombrepaquete>_<versión-vieja>.diff.gz | patch -p1</tt>»,
<item>orden «<prgn>uupdate</prgn>»,
<item>orden «<tt>svn merge</tt>» si gestionas el código con un repositorio Subversion o,
<item>simplemente copia el directorio <file>debian/</file> del árbol de código viejo si
@@ -2319,10 +2318,10 @@
</list>
<item>Conserva las entradas viejas del fichero «changelog» (puede parecer
- obvio, pero hay antecedentes...)
+ obvio, pero ha habido incidentes...)
<item>La nueva versión del paquete es la versión del código original añadiéndole
- el número de revision Debian<tt>-1</tt>, por ejemplo, `<tt>0.9.13-1</tt>'.
+ el número de revisión de Debian<tt>-1</tt>, por ejemplo, `<tt>0.9.13-1</tt>'.
<item>Añade una entrada en el fichero «changelog» para esta nueva versión
en la parte superior de <file>debian/changelog</file> que ponga «New upstream release».
@@ -2333,11 +2332,11 @@
fichero «changelog».
<item>Describe detalladamente los cambios hechos <em>a</em> la nueva versión del código
- por el mantenedor para arreglar fallos que se han informado y cierra esos fallos en el
+ por el mantenedor para arreglar fallos de los que se ha informado y cierra esos fallos en el
fichero «changelog».
<item>Si el parche/fusión no se aplicó limpiamente, inspecciona la situación para
- determinar que ha fallado (la clave está en los ficheros <file>.rej</file>).
+ determinar qué ha fallado (la clave está en los ficheros <file>.rej</file>).
A menudo el problema es que un parche que has aplicado a las fuentes fue integrado
en el código fuente original, y por lo tanto el parche ya no es necesario.
@@ -2353,12 +2352,12 @@
<p>
Cuando la actualización sea necesariamente intrusiva (por ejemplo, ficheros
- de configuración repartidos a través de varios directorios con estrcutura totalmente
- diferente), podrías considerar configurar el paquete seguro por defecto
- (por ejemplo, servicio desabilitado) y proporcionar la documentación adecuada
+ de configuración repartidos a través de varios directorios personales con estructuras totalmente
+ diferentes), podrías considerar configurar el paquete de forma segura por omisión
+ (por ejemplo, servicio deshabilitado) y proporcionar la documentación adecuada
requerida por las normas
(<file>README.Debian</file> y <file>NEWS.Debian</file> ) como último recurso.
- Pero no molestes con notas de configuración. <!-- este parrafo ha costado de traducir.
+ Pero no molestes con notas de configuración de Debconf. <!-- este parrafo ha costado de traducir.
En ingles:
When the upgrade is necessarily intrusive (eg., config files scattered through various home directories with totally different structure), you may consider to set package to the safe default (e.g., disabled service) and provide proper documentations required by the policy (README.Debian and NEWS.Debian ) as the last resort. But don't bother with the debconf note.-->
</footnote>
@@ -2390,33 +2389,33 @@
<item>Ejecuta <ref id="upgrading">.
- <item>Comprueba de nuevo si alguno de los bugs arreglados están actualmente abiertos en
+ <item>Comprueba de nuevo si alguno de los fallos arreglados están actualmente abiertos en
<url name="el sistema de seguimiento de fallos de Debian (BTS)" id="http://www.debian.org/Bugs/";> .
- <item>Comprueba el contenido del fichero «.changes» para segurarte de que
- lo estás subiendo a la distribución correcta, que cierres los fallos
+ <item>Comprueba el contenido del fichero «.changes» para asegurarte de que
+ lo estás enviando a la distribución correcta, que cierras los fallos
adecuadamente con el campo «Closes:», que los campos «Maintainer:» y «Changed-By:»
coinciden, que el fichero se ha firmado con GPG, etc
</list>
- <item>Si los cambios fueron realizados para corregir algo en el paquete,
+ <item>Si los cambios se realizaron para corregir algo en el paquete,
vuelve al segundo paso hasta que todo esté correcto.
- <item>Si tu subida necesita ser esponsorizada, comentar cualquier opción
+ <item>Si tu envío necesita que se patrocine, asegúrate de comentar cualquier opción
especial que se requiera en la construcción del paquete (como «<tt>dpkg-buildpackage
- -sa -v ...</tt>») y asegúrate de informar a tu sponsor asi el o ella podrá
- constuirlo correctamente.
+ -sa -v ...</tt>») y de informar a tu patrocinador, así el o ella podrá
+ construirlo correctamente.
- <item>Si lo subes tú, ejecuta <ref id="upload">.
+ <item>Si lo envías tú, ejecuta <ref id="upload">.
</enumlist>
<sect id="orig-tar">El archivo <file>orig.tar.gz</file>
<p>
Si intentas construir los paquetes desde el nuevo código fuente con
el directorio <file>debian/</file>, sin el fichero <file>orig.tar.gz</file>
- en el directorio padre, crearás un paquete de código nativo, que no tienen
+ en el directorio padre, crearás desintencionadamente un paquete de código nativo, que no tiene
fichero <file>diff.gz</file>.
- Este tipo de empaquetamiento es solo adecuado para paquetes específicos
+ Este tipo de empaquetamiento solo es adecuado para paquetes específicos
de debian, los cuales nunca será útiles en otra distribución.
<footnote>
@@ -2429,14 +2428,14 @@
<p>
Para obtener un paquete de código no nativo que consista tanto en un archivo
<file>orig.tar.gz</file> como en un archivo <file>diff.gz</file>, debes copiar
- manualmente la bola tar del código fuente original al directorio padre con el
+ manualmente el archivo tar del código fuente original al directorio padre con el
nombre cambiado a
- <file><nombrepaquete>_<version>.orig.tar.gz</file> como lo hizo
+ <file><nombrepaquete>_<versión>.orig.tar.gz</file> como lo hizo
la orden <prgn>dh_make</prgn> en <ref id="dh_make">.
<sect id="cvs-buildpackage">La orden <prgn>cvs-buildpackage</prgn> y similares
<p>Deberías considerar usar algún sistema de administración de código para
- administrar ela actividad de empaquetado. Hay varios guiones adaptados para su
+ administrar la actividad de empaquetado. Hay varios guiones adaptados para su
uso con algunos de los más populares.
<list compact>
<item>CVS
@@ -2454,12 +2453,12 @@
</list>
</list>
<p>
- Estas órdenes también automatizan el empaqueado de una nueva versión del código fuente.
+ Estas órdenes también automatizan el empaquetado de una nueva versión del código fuente.
<sect id="upgrading">Verificar actualizaciones del paquete
<p>Cuando construyas una nueva versión del paquete, deberías hacer
- lo siguiente para verificar que el paquete puede ser actualizado
+ lo siguiente para verificar que el paquete se pueda actualizar
de forma segura:
<list>
@@ -2474,7 +2473,7 @@
asegúrate de probar las rutas de actualización de éstos.
<p>Ten en cuenta que si tu paquete ha estado previamente en Debian,
- lo más frecuente es que gente actualize el paquete desde la versión
+ lo más frecuente es que gente actualice el paquete desde la versión
que estaba en la última versión de Debian. Recuerda testear también las
actualizaciones desde esa versión.
Reply to: