Supongamos que quiero una versión de software más reciente que la que está disponible para mi versión actual de un sistema operativo, ¿qué puedo hacer?

Casos a considerar:

1. Hay fuentes semioficiales / oficiales de paquetes adicionales disponibles para esa versión del sistema operativo. Por ejemplo, backports.org para Debian o PPA para Ubuntu.
2. 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 el backporting.
3. No hay versiones empaquetadas de versiones más recientes del software disponibles. Las opciones disponibles son empaquetar la versión más reciente.

^{Per Vamos a compilar una lista de preguntas y respuestas canónicas. Esto pretende ser un lugar para poner respuestas canónicas para lo siguiente. Las respuestas probablemente deberían hacerse wiki de la comunidad.}

(Si tiene preguntas / comentarios sobre esta respuesta, agregue un comentario. O, si tiene suficiente representante, puede hacerme ping en el chat).

Instalar directamente paquetes binarios desde una versión más nueva de Debian, no es la respuesta.

Supongamos que está ejecutando alguna versión de una distribución basada en Debian. Desea una versión más reciente de un paquete que la que tiene disponible. Lo primero que todo principiante intenta hacer es instalar el paquete binario directamente en su versión de Debian. Esto puede o no funcionar, dependiendo de qué versión 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 está tratando de instalar un paquete binario de prueba / inestable directamente en estable. Lo más probable es que esto no salga bien, a menos que la prueba / inestable ocurra muy cerca de estable 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 las 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 forma de hacer que las dependencias de la versión sean "estrictas", 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 say slrnde Debian inestable a Debian estable. ¿A qué se parecería?

# 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 con la libc6que slrnse compiló el inestable es diferente (y tiene un número de versión más alto) que la disponible en Debian estable. ( libc6es 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, lo inestable slrnrequiere una versión numerada más alta de la libc6que está disponible para estable. Tenga en cuenta que debido a que un paquete ha sido compilado contra una versión superior de la biblioteca, no necesariamente requiere una versión superior de esa biblioteca, pero a menudo es el caso.

La sintaxis

apt-get install slrn/unstable

significa: use el inestable slrnpero para todos los demás paquetes solo use las versiones de stable. Para ser más precisos, usa números de prioridad. Ver man apt_preferencespara más detalles.

También se puede hacer

apt-get install -t unstable slrn

Es mucho más probable que esto funcione, pero generalmente no desea hacerlo. ¿Por qué?

Esto significa: tratar temporalmente todos los paquetes en inestable en pie de igualdad con los paquetes en estable. Por lo tanto, esto extraerá las slrndependencias inestables de inestables si son de un número de versión superior, y generalmente lo serán. Esto generalmente incluirá la biblioteca GNU C por razones ya explicadas. Ahora, este enfoque generalmente "tendrá éxito", ya que las dependencias se satisfarán por definición (los inestables slrntienen dependencias que se satisfacen en inestables), pero terminará con una mezcla de paquetes que de repente se ven obligados a ejecutarse con versiones de bibliotecas diferente de para lo que fueron construidos. Esto probablemente no terminará bien.

La respuesta es ... ¡RESPALDOS!

Entonces, ¿cuál es la forma correcta de hacer esto? Es reconstruir las fuentes de Debian de versiones más recientes en su sistema, popularmente conocidas 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 para los backports de Debian.

Para un ejemplo concreto:

Agregue la línea de backports apropiada para su lanzamiento y actualice para encontrar los nuevos paquetes, luego instale algo de backports explícitamente (porque los backports están desactivados por defecto).

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 hacer una búsqueda de "packagename 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 / lanzamientos más recientes del sistema operativo. Este es el caso estándar para el backporting.

El backporting significa que reconstruye las fuentes de Debian 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

Por razones concretas, supondré que está ejecutando el actual Debian estable, actualmente sibilante. Usaré el paquete slrncomo ejemplo.

Primero, tenga en cuenta que todos los archivos de empaquetado de Debian viven en el debian/subdirectorio del directorio fuente.

El primer paso es verificar 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 hacer un backport 1.0.1-10.

PASO 1:

NB: asegúrese de que las deb-srclíneas de la versión de origen que desea descargar aparezcan en su /etc/apt/sources.list. Por ejemplo, si desea descargar la versión inestable de slrn, necesita la deb-srclínea para inestable, o no funcionará. Tenga en cuenta que no necesita las deblíneas correspondientes para descargar las fuentes, aunque apt-cache policyutiliza esa información, por lo que si no tiene las deblíneas correspondientes , apt-cache policyno le mostrará las versiones relevantes. Si tiene las deblíneas, no olvide anclar las versiones más nuevas utilizando una entrada en /etc/apt/preferenceso similar. Una entrada /etc/apt/preferencescomo esta (para inestable) funcionará, por ejemplo.

Package: *
Pin: release a=unstable
Pin-Priority: 50

Si agrega líneas /etc/apt/sources.list, no olvide ejecutar apt-get updatedespués.

Descargue las fuentes para 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. Ejecutar dch -i, que agregará automáticamente una entrada al debian/changelogarchivo. Luego cambie la entrada para que se vea así, por ejemplo.

slrn (1.0.1-10.username) UNRELEASED; urgency=low

  * Backport to wheezy.

 -- User <user@domain>  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. Uso debuilddel devtoolspaquete.

cd slrn-1.0.1/
debuild -uc -us

Si se satisfacen las dependencias de compilación, las fuentes generarán y generarán algunas debs en el nivel superior al directorio de origen; en este caso /usr/local/src/slrn.

ETAPA 4:

Supongamos que las dependencias de compilación no están satisfechas. Luego debe intentar instalar las dependencias de compilación. Esto puede o no funcionar, 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: Desafortunadamente, no es raro que los paquetes Debian requieran versiones de dependencias de compilación que sean más altas de lo necesario. No hay una forma automatizada en Debian para verificar esto, y a menudo a los mantenedores de paquetes no les importa mientras 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.

En cualquier caso, puede intentar instalarlos haciendo

apt-get build-dep slrn=1.0.1-10

Si esto tiene éxito, intente compilar el paquete nuevamente (PASO 2). Si falla, entonces se necesita más trabajo. Tenga en cuenta que debuildanaliza las dependencias de compilación en el debian/controlarchivo y puede cambiarlas si es necesario. Así que hablemos de eso ahora. Aquí están las dependencias de construcció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 apt-get build-depes 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 apt-get build-depque ya no hará 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, uno puede reutilizar el paquete de versiones anteriores del software junto con fuentes más nuevas. Este enfoque puede tener problemas, en particular los parches que se aplicaron a versiones anteriores del software pueden no aplicarse aquí, por lo que es posible que sea necesario volver a sincronizarlos con las fuentes. El formato de origen 3.0 (quilt) que ahora se está convirtiendo en estándar usa quilt, y los parches se encuentran en el debian/patchesdirectorio.

Sin embargo, una discusión detallada de estos temas está fuera del alcance de esta publicación.

Una forma que siempre funciona, no solo en Debian, es compilar el software necesario usted mismo. (He estado haciendo esto durante años en Debian, tanto cuando necesitaba una versión más nueva que estaba disponible, como cuando el software no se proporcionó en absoluto).

Almaceno paquetes compilados localmente /use/localusando stow, lo que me permite almacenar todos los archivos relacionados con un paquete en un árbol subdirectorio, y luego hacer enlaces simbólicos a ese árbol. Eso facilita la administración de paquetes compilados: los archivos instalados no chocan con los archivos proporcionados por Debian, y puedo eliminar un paquete con un solo comando.

Los pasos para compilar e instalar un paquete, por ejemplo some_software, suelen ser una variante de lo siguiente:

1. Descargar .tararchivo, etc. en /usr/local/src/.

2. Cree un archivo /usr/local/packages/some_softwareque describa dónde descargué el software, qué hace, qué versión es y que contiene notas de lo que tuve que hacer para compilarlo (ver más abajo).

3. Descomprima el contenido del .tararchivo en /usr/local/tmp/some_software.

4. Alternativamente, si compila desde un repositorio, revise el repositorio en un subdirectorio adecuado (por ejemplo /usr/local/git/some_software), y compile allí,

5. cden este directorio, mira README, INSTALLetc.

6. En la mayoría de los casos, hay un script de autotools en configureel paquete. Llame ./configure --prefix /usr/local/stow/some_software-versionpara que los archivos se instalen en este subdirectorio. De lo contrario, lea Makefiley descubra cómo establecer la ruta para los archivos instalados.

7. Compilar con make.

8. Instalar con make install.

9. cd /usr/local/stow, luego stow some_software-version

10. Prueba si funciona.

A menudo, la compilación no funciona en el primer intento: el paquete puede necesitar bibliotecas y los archivos de inclusión correspondientes, por lo que hay que instalar los ...-devpaquetes correctos de Debian. O gccpuede quejarse de cosas de las que gccno se queja una versión diferente de la que utilizó el autor del paquete. Entonces, a veces uno tiene que leer el código y corregirlo, pero eso no sucede con demasiada frecuencia.