Supongamos que quiero una versión de software más reciente que la disponible para mi versión actual de un sistema operativo, ¿qué puedo hacer?
Casos a considerar:
- Hay fuentes semioficiales/oficiales de paquetes adicionales
disponibles para esa versión del sistema operativo. P.ej. backports.org para Debian
o PPA para Ubuntu. - No hay versiones más recientes del paquete disponibles para esa
versión del sistema operativo, pero hay versiones más recientes disponibles para
versiones más recientes del sistema operativo. Este es el caso estándar para
backporting. - No hay versiones empaquetadas de versiones más recientes del
software disponibles. Las opciones disponibles son empaquetar la versión más reciente
.
Respuesta aceptada:
(Si tiene preguntas/comentarios sobre esta respuesta, agregue un comentario. O, si tiene suficientes representantes, puede hacerme ping en el chat).
Instalar paquetes binarios directamente desde una versión más reciente de Debian:no es la respuesta.
Suponga que está ejecutando alguna versión de una distribución basada en Debian. Quiere una versión más reciente de un paquete que la que está disponible para usted. Lo primero que todo principiante intenta hacer es instalar el paquete binario directamente en su versión de Debian. Esto puede funcionar o no, según la versión que esté ejecutando y cuánto más nuevo sea el paquete. En general, este procedimiento no funcionará bien.
Considere, por ejemplo, el caso en el que uno intenta instalar un paquete binario de prueba/inestable directamente en estable. Lo más probable es que esto no salga bien, a menos que las pruebas/inestables estén muy cerca de ser estables en ese momento. La razón tiene que ver con la naturaleza de una distribución binaria basada en Linux como Debian. Dichos sistemas operativos dependen en gran medida de bibliotecas compartidas, y estas dependencias a menudo dependen mucho de la versión; a menudo mucho más de lo necesario. Actualmente, Debian no tiene una buena manera de hacer que las dependencias de la versión sean "ajustadas", una forma abreviada de decir que la dependencia de la versión es exactamente tan restrictiva como sea necesario.
¿Qué significa esto para el usuario? Supongamos, por ejemplo, que está intentando instalar, digamos slrn de Debian inestable a Debian estable. ¿Cómo sería esto?
# apt-get install slrn/unstable
Reading package lists... Done
Building dependency tree
Reading state information... Done
Selected version '1.0.1-10' (Debian:testing [amd64]) for 'slrn'
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
slrn : Depends: libc6 (>= 2.15) but 2.13-38+deb7u1 is to be installed
E: Unable to correct problems, you have held broken packages.
A pesar del error producido por apt , no hay paquetes rotos aquí. Entonces, ¿qué salió mal? El problema es que la versión de libc6 que el inestable slrn fue compilado es diferente (y tiene un número de versión más alto) que el disponible en Debian estable. (libc6 es la biblioteca GNU C. La biblioteca C es central para cualquier sistema operativo similar a Unix, y la biblioteca GNU C es la versión que generalmente usan los sistemas operativos basados en Linux).
Por lo tanto, el inestable slrn requiere una versión numerada más alta de libc6 que está disponible para estable. Tenga en cuenta que el hecho de que un paquete se haya compilado con una versión superior de la biblioteca no requiere necesariamente una versión superior de esa biblioteca, pero suele ser el caso.
La sintaxis
apt-get install slrn/unstable
significa:usar el inestable slrn pero para todos los demás paquetes, use solo las versiones estables. Para ser más precisos, utiliza números de prioridad. Ver man apt_preferences para más detalles.
También se puede hacer
apt-get install -t unstable slrn
Esto es mucho más probable que funcione, pero generalmente no quieres hacerlo. ¿Por qué?
Esto significa:tratar temporalmente a todos bultos en inestable en pie de igualdad con los bultos en estable. Por lo tanto, esto atraerá el inestable slrn Las dependencias de son inestables si son de un número de versión más alto, y generalmente lo serán. Esto generalmente incluirá la biblioteca GNU C por las razones ya explicadas. Ahora, este enfoque generalmente "tendrá éxito", en el sentido de que las dependencias se satisfarán por definición (slrn de unstable tiene dependencias que se satisfacen en inestable), pero termina con una mezcla de paquetes que de repente se ven obligados a ejecutarse con versiones de bibliotecas diferentes de aquellas para las que fueron creados. Esto probablemente no terminará bien.
La respuesta es... ¡REPORTES!
Entonces, ¿cuál es la forma correcta de hacer esto? Es para reconstruir las fuentes de Debian de versiones más recientes en su sistema, conocido popularmente como “backporting”.
Considere los siguientes casos:
Hay fuentes semioficiales/oficiales de paquetes adicionales disponibles para esa versión de Debian.
El primer lugar para buscar es Debian Backports, que es el sitio oficial de Debian backports.
Para un ejemplo concreto:
Agregue la línea de backports adecuada para su versión y actualice para encontrar los nuevos paquetes, luego instale algo de backports explícitamente (porque los backports están desactivados de manera predeterminada).
echo "deb http://ftp.debian.org/debian stretch-backports main" | sudo tee /etc/apt/sources.list.d/stretch-backports.list
sudo apt-get update
sudo apt-get install -t stretch-backports git
Esto obtendrá la última versión estable de git que tiene características útiles más nuevas que la estable incluida con stretch (por ejemplo, 'incluir' que le permite combinar múltiples archivos de configuración o cambiar su nombre de usuario para ~/work/projects/ vs ~/personal/ proyectos/).
Otro lugar para mirar son los diversos PPA de los mantenedores de Ubuntu. Puede realizar una búsqueda de "nombre del paquete PPA".
No hay versiones más recientes del paquete disponibles para esa versión del sistema operativo, pero hay versiones más recientes disponibles para versiones/versiones más recientes del sistema operativo. Este es el caso estándar para backporting.
El backporting significa que usted reconstruye las fuentes de Debian a partir de una versión posterior de Debian en la versión que está ejecutando. Este procedimiento puede ser fácil o complicado y difícil según el paquete. Aquí hay un resumen de cómo hacer esto.
Un breve tutorial de backporting para principiantes
Para ser más concretos, asumiré que está ejecutando el Debian estable actual, actualmente sibilante. Usaré el paquete slrn como ejemplo.
Primero, tenga en cuenta que todos los archivos de empaquetado de Debian se encuentran en debian/ subdirectorio del directorio de origen.
El primer paso es comprobar si hay disponible una versión más reciente. Puedes hacer esto usando apt-cache policy .
apt-cache policy slrn
slrn:
Installed: 1.0.0~pre18-1.3
Candidate: 1.0.0~pre18-1.3
Version table:
1.0.1-10 0
50 http://debian.lcs.mit.edu/debian/ testing/main amd64 Packages
50 http://debian.lcs.mit.edu/debian/ unstable/main amd64 Packages
*** 1.0.0~pre18-1.3 0
500 http://debian.lcs.mit.edu/debian/ wheezy/main amd64 Packages
100 /var/lib/dpkg/status
1.0.0~pre18-1.1 0
500 http://debian.lcs.mit.edu/debian/ squeeze/main amd64 Packages
Nos gustaría respaldar 1.0.1-10 .
PASO 1:
NB:asegúrese de que deb-src las líneas para la versión fuente que desea descargar aparecen en su /etc/apt/sources.list . Por ejemplo, si desea descargar la versión inestable de slrn , necesita el deb-src línea para inestable, o no funcionará. Tenga en cuenta que no necesita el correspondiente deb líneas para descargar las fuentes, aunque apt-cache policy utiliza esa información, por lo que si no tiene el correspondiente deb líneas, luego apt-cache policy no le mostrará la(s) versión(es) relevante(s). Si tienes el deb líneas, no olvide anclar las versiones más nuevas usando una entrada en /etc/apt/preferences o similar. Una entrada en /etc/apt/preferences así (para inestable) funcionará, por ejemplo.
Package: *
Pin: release a=unstable
Pin-Priority: 50
Si agrega líneas en /etc/apt/sources.list , no olvide ejecutar apt-get update después.
Descarga las fuentes de slrn . Un buen lugar es /usr/local/src/slrn .
apt-get source slrn=1.0.1-10
PASO 2:
Cambie ligeramente el número de versión, para distinguir su backport de la versión anterior. Ejecute dch --bpo , que agregará automáticamente una entrada al debian/changelog archivo con un número de versión apropiado, por ejemplo
slrn (1.0.1-10~bpo10+1) UNRELEASED; urgency=low
* Backport to buster.
-- User <[email protected]> Sun, 02 Feb 2014 23:54:13 +0530
PASO 3:
Intenta construir las fuentes. Si los paquetes necesarios para la compilación no están disponibles, el intento fallará. Cambie el directorio al directorio de origen. Usar debuild de las devtools paquete.
cd slrn-1.0.1/
debuild -uc -us
Si se satisfacen las dependencias de compilación, las fuentes compilarán y producirán algunas versiones en el nivel superior al directorio de origen; en este caso /usr/local/src/slrn .
PASO 4:
Supongamos que no se satisfacen las dependencias de compilación. Luego, debe intentar instalar las dependencias de compilación. Esto puede funcionar o no, ya que las dependencias pueden no estar disponibles para su versión o, si están disponibles, pueden no estar disponibles en la versión correcta.
NB:Lamentablemente, no es raro que los paquetes de Debian requieran versiones de dependencias de compilación más altas de lo necesario. No hay una forma automatizada en Debian de verificar esto y, a menudo, a los mantenedores de paquetes no les importa, siempre y cuando funcione en la versión/lanzamiento correspondiente. Por lo tanto, adopte una actitud escéptica hacia las versiones de dependencia y use el sentido común. Por ejemplo, los paquetes ampliamente utilizados como Python y las herramientas GNU no dependerán de versiones muy específicas de sus dependencias, independientemente de lo que enumere el empaquetador de Debian.
Relacionado:Debian:¿cómo podemos predecir cuándo saldrá la próxima versión de Debian?En cualquier caso, puedes intentar instalarlos haciendo
apt-get build-dep slrn=1.0.1-10
Si esto tiene éxito, intente construir el paquete nuevamente (PASO 2). Si falla, entonces se necesita más trabajo. Tenga en cuenta que debuild examina las dependencias de compilación en debian/control y puede cambiarlos si es necesario. Así que hablemos de eso ahora. Estas son las dependencias de compilación para slrn.
Build-Depends: debhelper (>=9), libslang2-dev, libuu-dev,
exim4 | mail-transport-agent, libgnutls-openssl-dev, po-debconf, autoconf,
libcanlock2-dev, autotools-dev, dpkg-dev (>= 1.16.0), chrpath, dh-autoreconf, inn2-inews
Una alternativa al uso de apt-get build-dep es instalarlos manualmente, haciendo
apt-get install debhelper libslang2-dev ...
Si comienza a cambiar estos valores en el archivo de control, debe cambiar a una instalación manual, ya que apt-get build-dep ya no estará haciendo lo correcto.
No hay versiones empaquetadas de versiones más recientes del software disponibles. Las opciones disponibles son empaquetar la versión más reciente.
En muchos casos, se puede reutilizar el paquete de versiones anteriores del software junto con fuentes más nuevas. Este enfoque puede generar problemas, en particular, los parches que se aplicaron a versiones anteriores del software pueden no aplicarse aquí, por lo que es posible que deba volver a sincronizarlos con las fuentes. El formato fuente 3.0 (quilt) que ahora se está volviendo estándar usa quilt, y los parches se encuentran en debian/patches directorio.
Sin embargo, una discusión detallada de estos temas está fuera del alcance de esta publicación.