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

9

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?

Braiam
fuente

Respuestas:

10

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.

Faheem Mitha
fuente
La última oración del primer párrafo puede ser engañosa. Por favor, deje en claro que el problema solo ocurre a veces . La forma en que lo pones hace que parezca que los DD generalmente son así.
tshepang
@ Tshepang: Buen punto. ¿Está bien ahora?
Faheem Mitha
Si mucho mejor.
tshepang
5

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.

bahamat
fuente
3

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.

Sven
fuente
1

¿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ó .

tshepang
fuente
Las personas que dicen que el inestable de Debian es más estable que el de otras distribuciones están bromeando en el mejor de los casos. Cambios inestables todos los días, estable es un repositorio fijo. Inestable no significa que se bloqueará, pero significa que los desarrolladores realizan muchos cambios en los paquetes. Estable significa que se lanzó, y solo se agregarán correcciones de seguridad. Nunca tuve accidentes extraños corriendo inestables. Vi problemas de paquetes y problemas de dependencia después de actualizar, tenga cuidado ;-) Cómo todo eso se compara con las versiones "estables" de otras distribuciones me supera. No hay "más estable" en este contexto. Cambia o no cambia.
Arjan Drieman
@ArjanDrieman: en realidad esas personas no están bromeando, y en ese contexto se refieren a que es más a prueba de choques.
tshepang
Todavía están bromeando en el mejor de los casos. Realmente he visto a gente bromear al respecto. Una llama de micro distribución ;-) He usado algunas distribuciones a lo largo del tiempo, y nunca he tenido choques extraños ejecutando ninguna de las otras, las personas que dicen eso en serio no pueden respaldarlo con investigaciones o estadísticas. Eso podría ser ignorancia, arrogancia, prejuicio, cualquier cosa ... pero ¿eso es mejor que una broma? ¿Puedes decirme quiénes son estos misteriosos "Algunos"? ¿Para que pueda pedirles su investigación? "Algunos incluso llegan tan lejos" ... esas son palabras de comadreja. ¿Qué le gustaría en una respuesta, hechos u opinión popular y reclamos ambiguos?
Arjan Drieman
1
@Arjan Drieman: De hecho, estoy de acuerdo en que es inestable, 'a veces' puede cumplir con su nombre. Cambias la estabilidad por acercarte al límite, cualquiera que diga que no es así es falso en el mejor de los casos. En general, es sorprendentemente estable, pero la estabilidad no es la máxima prioridad para inestable. También tiendo a estar de acuerdo con usted, en lo que respecta al lenguaje "resbaladizo". Es casi un mecanismo de defensa aquí, ya que cualquier declaración absoluta / directa es atacada de inmediato.
JM Becker