Los procedimientos de actualización descritos más abajo pueden ser usados para actualizar cualquier versión anterior de Debian a 2.2 en un paso; no tendrá que actualizar paso a paso a cada una de las versiones intermedias. Note sin embargo que las actualizaciones desde la versión 2.0 y anteriores a 2.2 no han sido comprobadas extensivamente, y por tanto no tienen soporte.
Compatibilidad hacia atrás de fuentes y binarios en la GNU LibC 2.1 significa que la mayoría de los programas de la publicación anterior funcionarán en la nueva publicación (pero no al revés). Todos los paquetes en Debian GNU/Linux 2.2 han sido preparados para funcionar en el nuevo entorno, por supuesto, y será posible recompilar la mayoría de los programas en la nueva publicación sin cambios. Sin embargo, hay algunas excepciones a la regla, así que algunos de sus programas locales pueden necesitar que los modifique y/o recompile en la nueva glibc para funcionar correctamente.
Cuando se ejecuta bajo el núcleo 2.2 y la glibc 2.1, el sistema montará automáticamente el dispositivo virtual `devpts' adicional, para dar soporte a las PTYs Unix98, y alguno de nuestros demonios (servidores Unix) cambiarán automáticamente a usar los nuevos dispositivos (/dev/pts/* en vez de /dev/ttyp*).
Con el núcleo 2.2.x, los dispositivos de impresoras del PC empiezan a partir de lp0 en lugar de lp1 como en los núcleos 2.0.x, así que deberá actualizar su printcap y otros ficheros de configuración para usar eso (/dev/lp0 en vez de /dev/lp1, /dev/lp1 en vez de /dev/lp2 y así sucesivamente).
La transición a usar un nuevo núcleo ha ido suavemente, principalmente porque habíamos preparado casi totalmente la publicación 2.1 para ejecutar un núcleo 2.2. Algunas cuestiones permanecen aún, relacionadas principalmente con la red:
Debería leer el fichero del núcleo Documentation/Changes para más información sobre cómo actualizar programas para que funcionen con el nuevo núcleo.
La actualización a aplicaciones con capacidades PAM ha sido hecha de manera tan suave e integrada como ha sido posible. Para la mayoría de los casos, las nuevas configuraciones imitan a las configuraciones antiguas pre-PAM. De todos modos, no se puede tener en cuenta todos y cada uno de los casos. Si hace falta realizar cambios, puede instalar el paquete libpam-doc, que contiene documentación sobre cada uno de los aspectos de la biblioteca PAM, incluso pistas sobre como modificar sus aplicaciones no-PAM existente para añadirles soporte para el nuevo modelo de autentificación.
Una gran parte de la actualización de PAM fue unir secure-su al paquete login principal. El su predeterminado suministrado por shellutils se suministra ahora por el paquete login de forma que la integración de PAM sea más completa y a lo largo de todo el sistema. Si usted usaba el su predeterminado, entonces no notará ningún cambio con la nueva versión. Sin embargo, los usuarios del paquete obsoleto secure-su puede que tengan que comprobar sus configuraciones para asegurarse de que la nueva configuración PAM es compatible.
Puede que observe que esta publicación incluye dos versiones de Perl: 5.004 (en los paquetes perl-5.004*) y 5.005 (en los paquetes perl-5.005*). Le recomendamos usar la última versión, más moderna, y eliminar la versión antigua, que se mantiene sólo por compatibilidad, como conveniencia para los programadores.A.1 Si tiene/usa cualquier módulo Perl de los nuevos paquetes lib*-perl en sus `scripts', deberá definir el enlace simbólico /usr/bin/perl (usando update-alternatives) para que apunte a Perl 5.005, de otro modo encontrará problemas.
Por favor, observe que el archivo Debian non-US ha sido reorganizado ligeramente para ofrecer soporte a la separación entre software libre y no-libre. Si usted ya usaba apt para acceder a él, tendrá que cambiar las lineas de /etc/apt/sources.list para non-US a la siguiente forma:
Las versiones anteriores de inetd (suministradas por el paquete netbase) tenían un `bug' que hacía que cuando inetd era interrumpido, una conexión existente a cualquiera de los servicios internos podía impedir que inetd se reiniciase. Este error ha sido corregido en el netbase actual, pero las versiones antiguas siguen siendo vulnerables. Si encuentra que inetd no se reinicia apropiadamente, busque cualquier proceso inetd existente que siga ejecutándose, o procesos como ``-discard'' o ``-echo''. Si tiene el paquete psmisc instalado, ejecutando como root:
le dirá qué procesos usan puertos en los que inetd está interesado.
Los usuarios del MTA smail observarán que la publicación 2.2 no contiene dicho paquete ya más, debido a errores serios que tenía durante nuestros ciclos de pruebas. Paquetes actualizados de smail pueden obtenerse aún en la distribución inestable o en http://www.fs.tum.de/bunk/smail.html.
Las nuevas XFree86 y otros paquetes xserver-* introducidas en esta publicación, comparados con los de la publicación 2.1 anterior, pueden muy bien contener mejor soporte para su hardware gráfico, especialmente controladores para nuevas tarjetas gráficas como muchas tarjetas aceleradoras 3D. Si no sabe exactamente que paquete servidor X escoger, pruebe el programa xviddetect (del paquete xviddetect), que le mostrará el nombre del servidor X que necesita, basado en información que encuentre sobre su bus PCI/AGP.
Los usuarios del chipset Intel i810 deberían ser conscientes de que, para funcionar adecuadamente, el servidor de X necesita un módulo del núcleo de Linux que no se distribuye junto con las fuentes del núcleo de Linux. El código fuente de este módulo, así como instrucciones sobre cómo compilarlo y usarlo, se pueden encontrar en la página del Grupo de Trabajo X.
Si el servidor X que está usando hace referencia a la máquina que está actualizando para obtener servicios de fuentes con xfs, perderá su conexión al servidor de fuentes cuando se interrumpa xfs. No es fatal, pero puede ser molesto. Nota: cosas similares pueden suceder con otros demonios, así que esté preparado.