¿Cómo mantener mi sistema Debian con los últimos paquetes?

La mayor parte del "Software" que instalo en mi servidor debe ser la última versión (Java, Tomcat, MySQL-Cluster). Así que nunca tengo la suerte de que haya paquetes Debian precompilados (en la distribución) disponibles. Por lo tanto, todo el software se descarga desde la página web del proyecto y se crea desde la fuente.

Ahora mi pregunta es, ¿cuál es la forma correcta de instalarlos en mi sistema Debian?

Mi principal problema es que, al instalarlos directamente desde la fuente, no se incluyen en la gestión de paquetes (con aptitude). Checkinstall parece no ser realmente sugerido para ser utilizado y equiv también tiene inconvenientes. ¿Es la única forma correcta de manejar esto construyendo mis propios paquetes con dh_make y dpkg-buildpackage?

¿Qué haces si siempre necesitas la última versión?

Desear paquetes más recientes es un problema común en cualquier sistema operativo. El ciclo de lanzamiento de Debian ha promediado 2 años en los últimos años, por lo que hacia el final de este ciclo, quizás sea un problema más acuciante. Una forma de mitigar esto es pasar a las pruebas hacia el final del ciclo de lanzamiento estable, cuando la próxima versión es casi estable. No queda claro a partir de la pregunta si se trata de estable o, más generalmente, de pruebas y / o también inestable. De todos modos, tener la versión más reciente puede ser un problema, incluso si uno se ejecuta inestable, ya que la versión más reciente aún no se ha empaquetado. Los desarrolladores / empaquetadores de Debian son voluntarios, por lo que pueden aburrirse u ocuparse de otras cosas, con el resultado de que el paquete languidece.

Por simplicidad y concreción, supongo en lo que sigue que el plan es hacer un backport a un paquete estable, pero se aplica de manera más general. Entonces, esto es lo que hago si quiero una versión más reciente del software que no está presente en forma estable, en un orden aproximado.

1. Busque el paquete en Debian Backports . A veces puede encontrar un paquete que sea lo suficientemente reciente como para satisfacer sus propósitos. Sin embargo, a menudo es el caso de que estos paquetes están desactualizados en comparación con la versión inestable o experimental o ascendente.

2. Intente instalar el paquete directamente desde la prueba, inestable o experimental. Si estable no se ha desviado mucho de la versión desde la que intenta instalar, esto puede funcionar. Sabrá que este enfoque es malo si el sistema comienza a intentar instalar o actualizar paquetes básicos desde la versión más reciente. Supongamos que está intentando instalar desde inestable, entonces

   apt-get install packagename/unstable
   

   Es lo primero que hay que probar. Con versiones de apt en estable, esto a menudo fallará, ya que requiere otros paquetes inestables, y este encantamiento solo aumenta la preferencia de lo packagenamesuficientemente alto para que se instale en inestable. Si no comprende lo que esto significa, vaya y lea man apt_preferences. Continúe agregando dependencias desde inestable, asegurándose de que no está tratando de actualizar los paquetes básicos. Por ejemplo, si comienza a intentar actualizar libc6 o X o KDE o Gnome, cancele de inmediato. Por lo general, está bien si intenta actualizar otros paquetes desde el mismo paquete fuente, ya que estos generalmente están estrechamente unidos. Para ver de qué paquete fuente depende un paquete binario, haga

   apt-cache showsrc packagename
   

   Dado que muchas cosas dependen de la biblioteca GNU C (libc6) esto solía ser un problema. Más recientemente, la API parece haberse estabilizado, por lo que ahora es más posible evitar tener que actualizarla. Si un paquete satisface sus dependencias de tiempo de ejecución en estable, pero aún no funciona correctamente, presente un error. Si el empaquetador le dice que no es un error, está equivocado. :-)

3. Respalde el paquete usted mismo de la prueba, inestable o experimental

   Como se mencionó anteriormente, los backports son una opción, pero a menudo estos paquetes están desactualizados en comparación con la versión inestable o experimental o ascendente.

   Esto a menudo puede requerir una cosa de tipo de bucle de compilación de dependencia recursiva. Primero debe obtener las dependencias de compilación con

   apt-get build-dep packagename    
   

   Si esto falla debido a que una de las dependencias no es lo suficientemente reciente, primero tendrá que respaldar esa dependencia. Esto puede estar fuera de control. Normalmente me rindo si tengo que lidiar con más de 2 niveles de recursión. Sin embargo, tenga en cuenta que las dependencias reales no son necesariamente tan estrictas como se indica, es decir. Una versión anterior puede funcionar. El empaquetador a menudo no intenta encontrar la versión más antigua de una dependencia de compilación (o, de hecho, tiempo de ejecución) que funcione.

4. Verifique la disponibilidad de paquetes de la cadena ascendente correspondiente. Idealmente, estos coincidirían con su versión de distribución, pero también podría reconstruirlos si es necesario.

5. Cree paquetes para la versión del software más reciente que los paquetes más recientes en pruebas / inestable / experimental. Esto puede ser relativamente desafiante, pero a veces sorprendentemente factible. Lo primero que debe tener en cuenta es que si está intentando empaquetar una versión más reciente de un paquete que ya está en Debian, ya está comenzando con una gran ventaja, es decir, que tiene el paquete existente para trabajar. Solo haz

   apt-get source packagename
   

   y apt-getdescargará el paquete fuente correspondiente, incluido el subdirectorio de Debian donde vive el paquete. Tenga en cuenta además que en estos días, este paquete a menudo vive dentro de un repositorio de control verson (git parece popular entre Debian) y apt estable (actualmente 0.8.10.3 ) le ayuda a saber dónde está esto cuando invoca apt-get source. Debe observar esto, porque los empaquetadores pueden tener versiones más recientes del empaque que las que corresponden a cualquier paquete lanzado. P.ej.

   $ apt-get source mercurial
     Reading package lists... Done
     Building dependency tree       
     Reading state information... Done
     NOTICE: 'mercurial' packaging is maintained in the 'Svn' version control system at:
     svn://svn.debian.org/python-apps/packages/mercurial/trunk
   

   Alternativamente, podría simplemente usar

   apt-cache showsrc mercurial | grep Vcs
   

   para listar el repositorio.

   Si el paquete está desactualizado, es posible que tenga que realizar modificaciones en el
   paquete, actualizar los parches aplicados, pero aún así suele ser un buen punto de
   partida. Debian parece estar en el proceso de estandarizar la gestión de paquetes en
   quilt según el formato dpkg-source 3.0 (quilt) , por lo que ayuda con la actualización de parches.

   Concluiré con un ejemplo de la vida real de cómo porté el paquete Debian de pgf . La última versión empaquetada de pgf era 2.00 en 2008, y desde entonces se había lanzado 2.10. Vea la discusión en Por favor actualice a la versión estable más reciente de pgf (2.10) , y mi error de seguimiento con un parche, pgf: parches contra el paquete 2.0 Debian . Como resultado, el paquete Debian de pgf era muy simple, y solo tuve que cambiar una línea en el paquete 2.10 para que funcione. Terminé reprimiendo todas las quejas lintianas también, pero eso era estrictamente opcional.

Ciertamente puede construir sus propios paquetes, y eso funcionará. Sin embargo, recomendaría usar backports primero si lo que desea está disponible allí.

Los backports son mantenidos por Debian y obtienes actualizaciones de seguridad para ellos.

Construir sus propios paquetes es el camino a seguir (en mi humilde opinión). Dependiendo de la antigüedad de la versión de Debian de un paquete y de lo que ha cambiado, esto puede ser tan fácil como reemplazar el nombre del archivo tarball de origen en la descripción del paquete y, en el peor de los casos, aún puede usarlo como plantilla para su propia versión.

¿Qué haces si siempre necesitas la última versión?

1. Como ya se mencionó , use backports.

2. Solo un pequeño subconjunto de paquetes de Debian tiene respaldo, por lo que le sugiero que use las pruebas de Debian . Ofrece un buen equilibrio entre estabilidad y actualidad, y en cierto sentido, es como una distribución rodante.

3. Si eres un poco más atrevido, usa Debian Unstable . Se afirma que es razonablemente estable. Algunos incluso llegan a afirmar que es más estable que los lanzamientos "estables" de otras distribuciones. De todos modos, Unstable es donde normalmente aterrizan las nuevas versiones de paquetes. Normalmente se sientan allí durante unos 10 días, para permitir las pruebas, antes de migrar a Pruebas.

4. Incluso usando estos dos, es posible que aún no tenga las últimas versiones. En ese caso, eche un vistazo a Debian Experimental . Normalmente se usa cuando los nuevos paquetes son demasiado perjudiciales para los archivos normales (inestable y prueba).

5. Si Experimental aún no tiene versiones de software lo suficientemente nuevas, ve a ver los PPA de Ubuntu . He visto versiones de software allí más recientes que las que faltan en todos los archivos anteriores. Sin embargo, úselo con precaución, ya que Ubuntu no es 100% compatible con Debian (pero para la mayoría de los casos, no debería haber ningún problema).

6. Si lo anterior falla, supongo que solo crea tus propios paquetes, como se mencionó .