(Если у Вас есть вопросы/комментарии об этом ответе, добавьте комментарий. Или, если у Вас есть достаточный представитель, можно проверить с помощью ping-запросов меня в чате.)

Непосредственно устанавливающие двоичные пакеты от более новой версии Debian - не ответ.

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

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

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

# 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.

Несмотря на ошибку, произведенную 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, который является официальным сайтом для бэкпортов 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

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

Другое место для взгляда на является различным PPAs специалистами по обслуживанию Ubuntu. Можно сделать поиск "packagename PPA".

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

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

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

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

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

Первый шаг должен проверить, доступна ли более поздняя версия. Можно сделать это использование 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

Мы хотели бы бэкпортировать 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 -i, который автоматически добавит запись в debian/changelog файл. Затем измените запись, чтобы выглядеть примерно так, например.

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

  * Backport to wheezy.

 -- User <user@domain>  Sun, 02 Feb 2014 23:54:13 +0530

ШАГ 3:

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

cd slrn-1.0.1/
debuild -uc -us

Если зависимости от сборки будут удовлетворены, то источники создадут и произведут некоторый debs на уровне выше исходного каталога; в этом случае /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 (стеганое одеяло) исходный формат, который теперь становится стандартным стеганым одеялом использования и патчами, расположены в 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. В большинстве случаев для configureпакета имеется сценарий autotools. Вызовите с ./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, которую использовал автор используемого пакета. Поэтому иногда приходится читать код и исправлять ошибки, но это случается не слишком часто.