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

Случаи для рассмотрения:

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

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

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

Непосредственная установка бинарных пакетов из более новой версии Debian - не ответ.

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

Рассмотрим, например, случай, когда кто-то пытается установить бинарный пакет из тестирования / unstable непосредственно на стабильный. Скорее всего, это не будет хорошо, если только тестирование / нестабильность не будут очень близки к стабильным в этот момент. Причина связана с природой бинарного дистрибутива на основе 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зависимостей от unstable от unstable, если они имеют более высокий номер версии, и они обычно будут. Как правило, это включает библиотеку GNU C по причинам, уже объясненным. Теперь этот подход, как правило, будет «успешным», в том смысле, что зависимости будут удовлетворяться по определению (у unstable slrnесть зависимости, которые удовлетворяются в unstable), но в итоге вы получаете смесь пакетов, которые внезапно вынуждены запускать с версиями библиотек. отличается от того, для чего они были построены. Это, вероятно, не закончится хорошо.

Ответ ... СПЕЦИАЛИСТЫ!

Итак, как правильно это сделать? Он предназначен для перекомпоновки исходных текстов Debian с более свежими версиями в вашей системе, широко известными как «backporting». Рассмотрим следующие случаи:

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

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

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

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

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 / vs ~ / personal / проекты /).

Еще одно место, на которое стоит обратить внимание, это различные PPA от разработчиков Ubuntu. Вы можете сделать поиск для "packagename PPA".

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

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

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

Для конкретности я предполагаю, что вы используете текущую стабильную версию Debian, в настоящее время wheezy. Я буду использовать пакет 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

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