Differences between revisions 18 and 19
Revision 18 as of 2013-05-21 00:35:01
Size: 22478
Comment:
Revision 19 as of 2013-05-29 23:03:07
Size: 22471
Comment:
Deletions are marked like this. Additions are marked like this.
Line 5: Line 5:
В этой статья описывается как использовать предпочтения APT (Preferences). На данный момент, здесь изложено только закрепление (pinning). В этой статье описывается как использовать предпочтения APT (Preferences). На данный момент, здесь изложено только закрепление (pinning).
Line 12: Line 12:
Перед тем как выбрать 'pinning' вы можете проверить [[Backports|бэкпортирован]] ли нужный вам пакет для используемой вами версии дистрибутива. Перед тем как выбрать 'pinning' вы можете проверить [[Backports|бэкпортирован]] ли нужный пакет для используемой вами версии дистрибутива.

Translation(s): Русский - English - Italiano - 简体中文


В этой статье описывается как использовать предпочтения APT (Preferences). На данный момент, здесь изложено только закрепление (pinning).

Pinning

Перед тем как выбрать 'pinning' вы можете проверить бэкпортирован ли нужный пакет для используемой вами версии дистрибутива.

<!> При использовании apt-pinning вам необходимо обеспечить совместимость пакетов самостоятельно, так как Debian не гарантирует это. Заметьте, что функция apt-pinning полностью опциональна и Debian и не поощряет ее использование без тщательного рассмотрения.

Pinning позволяет вам иметь некоторые пакеты из другой ветки (stable, testing, unstable) без необходимости обновления всей системы. Тем не менее, пакеты из "старших" дистрибутивов тянут за собой также и библиотеки, что может привести к тому, что вы ваша система будет иметь недостатки стабильного (устаревшее программное обеспечение) и недостатки нестабильного/тестируемого (поддержка безопасности не настолько хороша как в стабильном, ошибки) без преимуществ одного из них.

На самом базовом уровне, функция pinning состоит из двух файлов, /etc/apt/sources.list и /etc/apt/preferences.

Дополнительную роль играет целевой выпуск, который может быть указан в файле apt.conf (или в /etc/apt/conf.d/... и посредством командной строки apt.

/etc/apt/sources.list

 #### testing  #########
 deb http://ftp.us.debian.org/debian testing main contrib non-free

 #### unstable #########
 deb http://ftp.us.debian.org/debian unstable main contrib non-free

В этом примере, мы используем testing или unstable. Вы можете, конечно же, изменить это на stable.

/etc/apt/preferences

В файле 'preferences' находятся настройки pinning. Ниже приведен пример:

 Package: *
 Pin: release a=testing
 Pin-Priority: 900

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

Значение Package по умолчанию любое, что указано звездочкой. Pin задает версию выпуска (testing и unstable). Pin-Priority задает уровень приоритета. 'apt-get' по умолчанию позволяет "пакетам с более высокой версией быть более приоритетными". Приведенные выше параметры перестраивают этот приоритет, так образом, пакеты из testing имеют более высокий приоритет.

Вы должны также обратиться к man-странице apt_preferences(5).

Установка из unstable

Давайте предположим, что у нас есть testing и мы хотим попробовать установить графическую оболочку enlightenment из unstable. Здесь даны два способа установки:

 # apt-get install enlightenment/unstable
 # apt-get -t unstable install enlightenment

Первый не будет пытаться обновить все пакеты в систему, таким образом, если конкретные зависимости не совпадают, установка выполнена не будет. Второй метод будет пытаться установить/обновить любые зависимости. Конечно же, в приведенном выше примере 'apt-get' спросит вас перед продолжением.

Примечания от Joshua Rodman

Лично я нашел общую конфигурацию Testing pin с более высоким приоритетом и Unstable pin с более низким приоритетом проблематичной. Время от времени, тестируемые пакеты будут зависеть от других пакетов, которые не являются в настоящее время тестируемыми (вероятно, это приведет к небольшому сбою в testing), что заставит их автоматически подхватываться из нестабильной ветки. В период тестирования до стабилизации выпуска Woody мне пришлось установить конечном итоге более чем 100 нестабильных пакетов, даже не осознавая этого.

В результате, я использую более консервативный "только если я так говорю" подход к смешанному дистрибутиву с вот таким Pin-файлом:

  Package: *
  Pin: release a=testing
  Pin-Priority: 900

  Package: *
  Pin: release o=Debian
  Pin-Priority: -10

Таким образом, все пакеты Debian по умолчанию получают приоритет -10, в тоо время как тестируемые получают 900 точек бонуса. Это вызывается:

из apt_preferences(5)

  500 < P <=990 :
       версия устанавливается, в случае отсутствия доступной, 
       принадлежащей целевому выпуску или если установленная версия 
       более актуальна
  [...]
  P < 0 :
        предотвращает установку версии

Заметьте, что приоритет выше 1000 позволяет понижение независимо даже от версии приоритетного пакета. Это означает, что Вы можете использовать приоритет 1001 для стабильного источника, если Вы хотите откатить пакеты до стабильных версий, которые Вы установили (скажем, из testing) на систему. Не рекомендуется если количество изменений не минимально

Установка пакетов с помощью apt-get install packagename/unstable и apt-get install -t unstable packagename все ещё работает, но нестабильные пакеты будут установлены только этими командами.

Примечания от ZugSchlus

Disclaimer

Эта страница была написана ZugSchlus, который даже отдаленно не схватывает концепцию закрепления пакетов. Так что, пожалуйста, считайте слова "вероятно", "должно быть проверено" и подобные формулировки буквальными, и документируйте свои результаты (может они будут чем-то вроде "эта страница верна", или "эта страница неверна", опционально "эта страница неверна, потому что") здесь.

Описание процесса выбора пакета

ToDo: должно быть проверено

  • Игнорировать пакеты, которые не отвечают критериям версии
  • Игнорировать пакеты версий ниже, чем у текущих, если их приоритет > 1000

  • Установите наивысший приоритет оставшегося пакета
  • В случае приоритетной связи возьмите закрепленный пакет
    • Этот шаг вероятно должен быть пропущен, если закрепление ничему не соответствует
  • В случае отсутствия закрепленного пакета возьмите самую высокую версию
  • В случае с несколькими пакетами с той же самой версией, apt-get сначала выбирает один из ветки дистрибутива, перечисленного в sources.list

Примеры файла /etc/apt/preferences

Пример 1

 Package: *
 Pin: release o=Debian,a=testing
 Pin-Priority: 900

 Package: *
 Pin: release o=Debian,a=unstable
 Pin-Priority: 300

 Package: *
 Pin: release o=Debian
 Pin-Priority: -1

Отсутствует: Документация о том, что этот файл настроек делает.

ZugSchlus пытается объяснить:

  • Все пакеты тестируемого дистрибутива закреплены на 900
  • Все пакеты нестабильного дистрибутива закреплены на 300
  • Все остальные пакеты из Debian закрепляется на -1 и следовательно, никогда не установятся.

Проблема: Данное закрепление ведет себя по-другому, в зависимости от того, какой целевой выпуск установлен, в других частях конфигурации apt. Следовательно, этот пример в действительности не может быть зарегистрирован, без добавления дополнительной информации. У незакрепленного пакета, являющегося частью целевого выпуска, приоритет по умолчанию 990, в то время как у других незакрепленных пакетов приоритет по умолчанию 500.

Пример 2

Цель: На системе, основанной на нестабильной ветке, вытащить dpatch из экспериментальной.

Возможное (и не совсем правильное) решение:

  • Имеются нестабильная и экспериментальная ветки в sources.list

    • In absence of explicit pinning, experimental will be automatically pinned to priority 1. This is because experimental's Release file contains NotAutomatic: yes.

  • Pin the wanted packages to a value x with 100<x<500:

     Package: dpatch
     Pin: release o=Debian,a=experimental
     Pin-Priority: 450
    • Значение > 500 будет всегда выбирать пакет из экспериментального, даже препятствовать установке пронумерованного нестабильного пакета с более высокой версией и не станет выбирать "пакет" из всех доступных вообще, если дистрибутив, не содержащий тот пакет, будет закреплен выше.

    • К сожалению, поле Package не понимает ни групповые символы, ни регулярные выражения. Вы необходимо указать по одной строфе закрепления для каждого пакета.
    • Закрепление пакета на 450, вероятно, не приведет автоматическому обновлению пакета до экспериментального, но он, вероятно, будет отслеживаться в экспериментальной, до тех пор пока имеет версию выше чем в нестабильной ветке.

Пример 3

От Mihamina rakotomandimby

Предположим, что у Вас есть репозиторий, в котором есть Ваша персональная версия Postfix. И Вы хотите, чтобы APT предпочитал Вашу версию поверх официальной.

Вы можете установить предпочтения при помощи Origin

Package: *
Pin: origin www.rktmb.org
Pin-Priority: 610

Package: *
Pin: origin ftp.fr.debian.org
Pin-Priority: 600

Устранение ошибок, отладка

apt-cache policy package дает информацию о процессе отбора. К сожалению, оно не является широко известным средством вывода. Ниже попытаемся интерпретировать:

 $ apt-cache policy exim4-daemon-light
 exim4-daemon-light
  Installed: 4.50-1
  Candidate: 4.50-1
  Package Pin: (not found)
  Version Table:
      4.50-4 555
        500 http://mirror sid/main Packages
  *** 4.50-1 555
        100 /var/lib/dpkg/status
      4.44-2 555
        500 http://mirror sarge/main Packages

Приоритет каждой версии/местоположения - число слева от него. В этом случае, 500, 100, и 500. Число справа от номера версии отображает фактический приоритет закрепления, применяемого к пакету.

Примечания от Ryan B.

Если Вы задаетесь вопросом, какие существуют варианты для файла предпочтений выпуска, обратитесь к этой ссылке: http://www.debian.org/doc/manuals/repository-howto/repository-howto

Мы найдем:

Archive: archive

Component: component

Origin: Your Company

Label: Your Company Debian repository

Architecture: architecture

Таким образом, строка: "Pin: release a=testing" обнаружит значения архива в файле выпуска под названием "testing".

Примечания от Georgios Zarkadas

Я обнаружил, что использование более высокого чем 500 значения для закрепления testing/unstable приводит к тому, что apt-get upgrade хочет обновить все пакеты на более новые версии до testing/unstable, даже когда у меня был закреплен stable с более высоким значением чем testing/unstable.

После, подвергая сомнению результат apt-cache policy <some-package> для многих пакетов, которые как полагает apt-get upgrade, должны быть обновлены, я пришел к заключению что, если есть многократные версии с кандидатами, закрепленными к 500 или выше, то скрепление рассматривается после номера версии. Таким образом, выбрана самая высокая версия с самым высоким весом закрепления среди кандидатов (и только эта).

Например (имеются stable прикрепленный к 700, testing к 650 и unstable к 600)

root@freedom:/etc/apt# apt-cache policy deborphan
deborphan:
  Εγκατεστημένα: 1.7.28.3+squeeze1
  Υποψήφιο:      1.7.28.5
  Πίνακας Έκδοσης:
     1.7.28.5 0
        650 http://ftp.gr.debian.org/debian/ wheezy/main amd64 Packages
        600 http://ftp.gr.debian.org/debian/ sid/main amd64 Packages
 *** 1.7.28.3+squeeze1 0
        500 http://ftp.gr.debian.org/debian/ squeeze-proposed-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     1.7.28.3 0
        500 cdrom://[Debian GNU/Linux 6.0.1a _Squeeze_ - Official amd64 DVD Binary-1 20110322-16:05]/ squeeze/main amd64 Packages
        700 http://ftp.gr.debian.org/debian/ squeeze/main amd64 Packages

Так как моя цель состояла в том, чтобы использовать многократные источники и прикрепить, чтобы иметь возможность иногда установить пакет из testing или unstable и не обновлять все мои пакеты, закрепление testing/unstable к значениям, равно или больше, чем 500, является неприменимым методом по установленной причине.

Однако, я нашел, что, использование значения менее чем 500 для testing/unstable дает желаемый эффект. Например (я удалил закрепление stable, установил testing на 450 и unstable к 400):

root@freedom:/etc/apt# apt-cache policy deborphan
deborphan:
  Εγκατεστημένα: 1.7.28.3+squeeze1
  Υποψήφιο:      1.7.28.3+squeeze1
  Πίνακας Έκδοσης:
     1.7.28.5 0
        450 http://ftp.gr.debian.org/debian/ wheezy/main amd64 Packages
        400 http://ftp.gr.debian.org/debian/ sid/main amd64 Packages
 *** 1.7.28.3+squeeze1 0
        500 http://ftp.gr.debian.org/debian/ squeeze-proposed-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     1.7.28.3 0
        500 cdrom://[Debian GNU/Linux 6.0.1a _Squeeze_ - Official amd64 DVD Binary-1 20110322-16:05]/ squeeze/main amd64 Packages
        500 http://ftp.gr.debian.org/debian/ squeeze/main amd64 Packages

Примечания от Дмитрия Матросова

Я думаю что заключение Georgios Zarkadas' (от предыдущих примечаний) о "закреплении при помощи apt после номера версии":

Я пришел к выводу, что если существует несколько версий с кандидатами закрепленными на 500 или выше, то закрепление считается '''после''' номера версии.

неверное. Давайте посмотрим еще раз на пример, который он привел:

root@freedom:/etc/apt# apt-cache policy deborphan
deborphan:
  Εγκατεστημένα: 1.7.28.3+squeeze1
  Υποψήφιο:      1.7.28.5
  Πίνακας Έκδοσης:
     1.7.28.5 0
        650 http://ftp.gr.debian.org/debian/ wheezy/main amd64 Packages
        600 http://ftp.gr.debian.org/debian/ sid/main amd64 Packages
 *** 1.7.28.3+squeeze1 0
        500 http://ftp.gr.debian.org/debian/ squeeze-proposed-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     1.7.28.3 0
        500 cdrom://[Debian GNU/Linux 6.0.1a _Squeeze_ - Official amd64 DVD Binary-1 20110322-16:05]/ squeeze/main amd64 Packages
        700 http://ftp.gr.debian.org/debian/ squeeze/main amd64 Packages

Во-первых, APT пытается обновить из stable (squeeze/main), так как stable имеет самый высокий приоритет (700), но он видит, что установленный пакет новее:

sgf@shilvana:~$ dpkg --compare-versions 1.7.28.3 lt '1.7.28.3+squeeze1' ; echo $?
0

и приоритет 700 недостаточен для понижения. Таким образом, похоже далее и для версии кандидата. А теперь APT пытается обновить из testing (wheezy/main) и видит, что версия из testing новее:

sgf@shilvana:~$ dpkg --compare-versions '1.7.28.3+squeeze1' lt 1.7.28.5 ; echo $?
0

И, следовательно, эта версия (из testing) станет кандидатом.

Итак, для того, чтобы обновиться из stable (как Georgios Zarkadas хочет), он должен иметь пакет версии <=, чем один в stable.

References