Предположим, я хочу более новую версию программного обеспечения, чем та, что доступна для моей текущей версии операционной системы. Что я могу сделать?

Случаи, которые следует рассмотреть:

1. Существуют полупротивофициальные/официальные источники дополнительных пакетов для этой версии ОС. Например, backports.org для Debian или PPAs для Ubuntu.
2. Нет более новых версий пакета для этой версии ОС, но более новые версии доступны для более новых версий ОС. Это стандартный случай для бэкторинга.
3. Нет упакованных версий более новых версий программного обеспечения. Доступные варианты – упаковать более новую версию.

^{Согласно Давайте соберем список канонических вопросов и ответов, это место предназначено для размещения канонических ответов на следующее. Ответы, вероятно, стоит сделать совместными вики.}

(Если у вас есть вопросы/комментарии к этому ответу, пожалуйста, добавьте комментарий. Или, если у вас достаточно репутации, вы можете написать мне в чате.)

Прямую установку бинарных пакетов из более новой версии Debian – не тот ответ.

Предположим, вы используете какую-то версию дистрибутива на основе Debian. Вы хотите более новую версию пакета, чем та, что доступна вам. Первое, что каждый новичок пытается сделать, – это установить бинарный пакет прямо на вашу версию Debian. Это может или не может сработать, в зависимости от того, какую версию вы используете и насколько новой является версия пакета. В общем, эта процедура не будет хорошо работать.

Рассмотрим, например, случай, когда пытаются установить бинарный пакет из тестирования/нестабильной версии прямо на стабильной. Скорее всего, это не сработает, если тестирование/нестабильная версия не будут очень близки к стабильной в данный момент. Причина этого связана с природой бинарного дистрибутива на основе Linux, такого как Debian. Такие операционные системы сильно зависят от общих библиотек, и эти зависимости часто очень жестко зависят от версий; часто гораздо больше, чем это нужно. В настоящее время в Debian нет хорошего способа сделать зависимости версий “жесткими” – это сокращенный способ выразить, что зависимость версии столь же ограничительна, как это необходимо.

Что это значит для пользователя? Предположим, вы пытаетесь установить, скажем, slrn из нестабильной версии Debian на стабильную версию. Как это будет выглядеть?

# apt-get install slrn/unstable
Чтение списков пакетов... Готово
Создание дерева зависимостей       
Чтение информации о состоянии... Готово
Выбрана версия '1.0.1-10' (Debian:testing [amd64]) для 'slrn'
Некоторые пакеты не могут быть установлены. Это может означать, что вы
запросили невозможную ситуацию или, если вы используете нестабильную
версию, некоторые необходимые пакеты еще не были созданы
или были перемещены из Incoming.
Следующая информация может помочь разрешить ситуацию:

Следующие пакеты имеют неудовлетворенные зависимости:
 slrn : Depends: libc6 (>= 2.15), но 2.13-38+deb7u1 должен быть установлен
E: Невозможно устранить проблемы, у вас есть заблокированные пакеты.

Несмотря на ошибку, выданную apt, здесь нет сломанных пакетов. Так что же пошло не так? Проблема в том, что версия libc6, на которую была скомпилирована нестабильная slrn, отличается (и имеет более высокий номер версии) от той, что доступна на стабильной версии Debian. (libc6 — это библиотека GNU C. Библиотека C является центральной для любой UNIX-подобной операционной системы, и библиотека GNU C — это версия, которую обычно используют операционные системы на основе Linux.)

Таким образом, нестабильная slrn требует версию libc6 с более высоким номером, чем та, что доступна для стабильной версии. Обратите внимание, что то, что пакет был скомпилирован с использованием более новой версии библиотеки, не обязательно требует более поздней версии этой библиотеки, но это часто так.

Синтаксис

apt-get install slrn/unstable

означает: используйте нестабильную slrn, но для всех остальных пакетов используйте только версии из стабильной. Чтобы быть более точным, это использует числа приоритета. См. man apt_preferences для детализации.

Также можно выполнить

apt-get install -t unstable slrn

Это гораздо более вероятно, что сработает, но вы, как правило, не хотите этого делать. Почему?

Это означает: временно рассматривать все пакеты в нестабильной версии наравне с пакетами в стабильной. Таким образом, это подцепит зависимости нестабильного slrn из нестабильной версии, если их номер версии выше, и они, как правило, будут. Это, как правило, также будет включать библиотеку GNU C по уже описанным причинам. Теперь, этот подход обычно будет “успешным”, поскольку зависимости по определению будут удовлетворены (недоступная slrn имеет зависимости, которые удовлетворены в нестабильной версии), но вы получаете смесь пакетов, которые внезапно вынуждены работать с версиями библиотек, отличными от тех, для которых они были собраны. Это вряд ли закончится хорошо.

Ответ: БЭКТОРИНГ!

Итак, каков правильный способ сделать это? Это пересобрать исходники Debian более новых версий на вашей системе, популярно известный как “бэкторинг”.
Рассмотрим следующие случаи:

Существует полупротивофициальные/официальные источники дополнительных пакетов для этой версии Debian.

Первое место, куда стоит обратиться, это Debian Backports, который является официальным сайтом для бэкторинга Debian.

Для конкретного примера:

Добавьте соответствующую строку бэкторинга для вашего релиза и обновите, чтобы найти новые пакеты, затем установите что-то из бэкторинга явно (поскольку бэкторинг по умолчанию отключен).

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

Это получит последнюю стабильную версию git, которая имеет полезные новые функции, чем стабильная, включенная в stretch (например, ‘include’, который позволяет вам объединять несколько конфигурационных файлов или изменить ваше имя пользователя для ~/work/projects/ и ~/personal/projects/).

Еще одно место для поиска – это различные PPAs от Maintainers Ubuntu. Вы можете выполнить поиск по “имя_пакета PPA”.

Нет более новых версий пакета для этой версии ОС, но существуют более новые версии для более новых версий/релизов ОС. Это стандартный случай для бэкторинга.

Бэкторинг означает, что вы пересобираете исходники Debian из более поздней версии Debian на версии, которую вы используете. Эта процедура может быть простой или сложной и трудоемкой в зависимости от пакета. Вот обзор как это сделать.

Краткое руководство по бэкторингу для новичков

Для ясности предположим, что вы используете текущую стабильную версию Debian, в данный момент wheezy. Я буду использовать пакет slrn в качестве примера.

Сначала обратите внимание, что все файлы упаковки Debian находятся в debian/ подкаталоге исходного каталога.

Первый шаг проверить, доступна ли более новая версия. Вы можете сделать это, используя apt-cache policy.

apt-cache policy slrn

slrn:
  Установлено: 1.0.0~pre18-1.3
  Кандидат: 1.0.0~pre18-1.3
  Таблица версий:
     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

Мы хотим сделать бэкторинг 1.0.1-10.

ШАГ 1:

NB: Убедитесь, что строки deb-src для версии исходников, которую вы хотите загрузить, появляются в вашем /etc/apt/sources.list. Например, если вы хотите загрузить нестабильную версию slrn, вам нужна строка deb-src для нестабильной версии, иначе это не будет работать. Обратите внимание, что вам не нужны сопоставляющие строки deb для загрузки исходников, хотя apt-cache policy использует эту информацию, так что если у вас нет соответствующих строк deb, то apt-cache policy не покажет вам соответствующие версии. Если у вас есть строки deb, не забудьте заблокировать новые версии с помощью записи в /etc/apt/preferences или аналогичном. Запись в /etc/apt/preferences как эта (для нестабильной) будет работать, например.

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

Если вы добавляете строки в /etc/apt/sources.list, не забудьте запустить apt-get update после этого.

Загрузите исходники для slrn. Хорошее место – /usr/local/src/slrn.

apt-get source slrn=1.0.1-10

ШАГ 2:

Немного измените номер версии, чтобы отличать ваш бэкторинг от исходной версии. Запустите dch --bpo, что автоматически добавит запись в файл debian/changelog с подходящим номером версии, например

slrn (1.0.1-10~bpo10+1) UNRELEASED; urgency=low

  * Бэкторинг для buster.

 -- Пользователь <user@domain>  Вск, 02 Фев 2014 23:54:13 +0530

ШАГ 3:

Попробуйте создать исходники. Если необходимые пакеты для сборки недоступны, попытка завершится неудачей. Перейдите в каталог исходников. Используйте debuild из пакета devtools.

cd slrn-1.0.1/
debuild -uc -us

Если зависимости для сборки удовлетворены, исходники будут собраны и произведут некоторые deb-файлы на уровень выше каталога исходников; в этом случае /usr/local/src/slrn.

ШАГ 4:

Предположим, зависимости для сборки не удовлетворены. Тогда вам нужно попытаться установить зависимости для сборки. Это может или не может сработать, так как зависимости могут не быть доступными для вашей версии, или, если доступны, могут быть недоступными в нужной версии.

NB: К сожалению, не редкость, когда пакеты Debian требуют версий зависимостей для сборки, которые выше необходимых. В Debian нет автоматического способа проверить это, и часто сопровождающие пакеты не заботятся, так долго, как это работает на соответствующей версии/релизе. Поэтому имейте критическое отношение к версиям зависимостей и используйте здравый смысл. Например, широко используемые пакеты, такие как Python и инструменты GNU, не будут зависеть от очень специфических версий своих зависимостей, независимо от того, что указывает упаковщик Debian.

В любом случае, вы можете попробовать установить их, выполнив

apt-get build-dep slrn=1.0.1-10

Если это сработает, то снова попробуйте собрать пакет (ШАГ 2). Если это не удалось, необходима дальнейшая работа. Обратите внимание, что debuild смотрит на зависимости сборки в файле debian/control, и вы можете изменить их, если это необходимо. Давайте поговорим об этом. Вот зависимости сборки для 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

Альтернативой использованию apt-get build-dep является установка этих пакетов вручную, выполнив

apt-get install debhelper libslang2-dev ...

Если вы начинаете изменять эти значения в контрольном файле, тогда вам следует переключиться на ручную установку, так как потом apt-get build-dep больше не будет делать правильное действие.

Нет упакованных версий более новых версий программного обеспечения. Доступные варианты – упаковать более новую версию.

Во многих случаях можно повторно использовать упаковку из более ранних версий программного обеспечения в сочетании с более новыми исходниками. Этот подход может натолкнуться на проблемы, особенно патчи, которые применялись к более ранним версиям программного обеспечения, могут не применяться здесь, поэтому необходимо будет обновить их с исходниками. Формат источника 3.0 (quilt), который сейчас становится стандартом, использует quilt, и патчи находятся в каталоге debian/patches.

Тем не менее, детальное обсуждение этих проблем выходит за рамки этого поста.

Один из способов, который всегда работает, не только в Debian, это компилировать необходимое программное обеспечение самостоятельно. (Я делаю это уже много лет на Debian, как когда мне нужна была более новая версия, чем та, что доступна, так и когда программное обеспечение вообще не предоставлялось).

Я храню локально скомпилированные пакеты в /use/local, используя stow, что позволяет мне хранить все файлы, относящиеся к пакету, в подкаталоге, а затем делать символические ссылки на это дерево. Это облегчает управление скомпилированными пакетами: Установленные файлы не конфликтуют с файлами, предоставленными Debian, и я могу удалить пакет одной командой.

Шаги для компиляции и установки пакета, скажем some_software, обычно представляют собой вариант следующее:

1. Скачать .tar файл и т.д. в /usr/local/src/.

2. Создайте файл /usr/local/packages/some_software, который описывает, откуда я скачал программное обеспечение, что оно делает, какая у него версия, и который содержит заметки о том, что мне пришлось сделать, чтобы заставить его скомпилироваться (см. ниже).

3. Распаковать содержимое .tar файла в /usr/local/tmp/some_software.

4. Кроме того, если компилируете из репозитория, клонируйте репозиторий в подходящий подкаталог (например, /usr/local/git/some_software), и компилируйте там,

5. cd в этот каталог, посмотрите на README, INSTALL и т. д.

6. В большинстве случаев есть скрипт autotools для configure пакета. Вызовите с ./configure --prefix /usr/local/stow/some_software-version, чтобы файлы установились в этот подкаталог. В противном случае читайте Makefile и выясняйте, как установить путь для установленных файлов.

7. Соберите с помощью make.

8. Установите с помощью make install.

9. cd /usr/local/stow, затем stow some_software-version

10. Проверьте, работает ли это.

Часто компиляция не срабатывает с первой попытки: Пакет может требовать библиотеки и соответствующие файлы заголовков, поэтому нужно установить правильные ...-dev пакеты из Debian. Или gcc может жаловаться на вещи, о которых не жалуется другая версия gcc, с помощью которой работал автор пакета. Так что иногда нужно читать код и исправлять это, но это происходит не так часто.