Невозможно открыть файл c описанием приоритетов пакетов etc apt pkgpriorities

Обновлено: 05.07.2024

Все команды, котрые вносят изменения в систему, выполняются:

  • в Astra Linux Common Edition - с правами администратора системы;
  • в Astra Linux Special Edition - с правами администратора системы с высоким уровнем целостности;

То есть выполняются либо через команду sudo для каждой выполняемой команды, либо для группы команд в сессии администратора после выполнения команды:

Установка пакетов при подключенном репозитории производится в терминале командой:

также установка пакетов и настройка репозиториев может производиться с помощью графического менеджера пакетов Synaptic.

Для находящихся в эксплуатации систем рекомендуется использовать именно этот репозиторий.
  • Репозитории и установочные образы с актуальными стабильными версиями пакетов;
  • Установочные образы и наборы программ из данной папки ПОЛУЧАЮТ техническую поддержку.
  • Репозитории с новыми (тестируемыми) версиями обновлений и пакетов;
  • После выпуска обновлений данный репозиторий какое-то время соответствует репозиторию stable;
  • Установочные образы и наборы программ из данной папки НЕ ПОЛУЧАЮТ техническую поддержку.

Экспериментальные репозитории, установочные образы и наборы программ (experimental/addons).

Установочные образы и наборы программы из данной папки НЕ ПОЛУЧАЮТ техническую поддержку.

Репозитории experimental/addons предназначены для установки на текущую stable версию дистрибутива и могут быть несовместимы с пакетами, входящими в репозитории testing.
  • В данных репозиториях размещены архивные версии репозиториев, для которых уже не будут выпускаться обновления безопасности (версии Astra Linux Common Edition очередное обновление 1.11 и снимки репозиториев Astra Linux Common Edition 2.12);
  • Установочные образы и наборы программы из данной папки техническую поддержку в соотвествии с действующими лицензиями договорами.
Использование этих репозиториев лишает Вас возможности получать критические обновления, в том числе обновления безопасности! Актуальный репозиторий находится в папке stable.

Сохранён для совместимости с более ранними версиями структуры папок. К использованию не рекомендуется. Cовпадает с репозиторием stable.

Установщик по умолчанию, если иное не задано в файлах настройки приоритетов, старается устанавливать более новые версии пакетов.
При этом изменения номеров минорных версий установщиком не учитываются, т.е.:

  • При возможности установки пакетов пакет_1.1.1-100 и пакет_1.1.2-1 (отличие в последней цифре номера мажорной версии) будет установлен пакет_1.1.2, как имеющий старшую мажорную весрсию;
  • При возможности установки пакетов пакет_1.1.1-1 и пакет_1.1.1-100 (мажорные версии совпадают, отличия в минорных версиях) будет установлен первый найденный в репозиториях вариант пакета.

Приоритеты выбора репозиториев задаются в каталоге /etc/apt/preferences.d/ или в файле /etc/apt/preferences (устаревший способ).
Подробности см. по ссылке

Если приоритеты выбора репозитория не заданы явно, то

  • неподписанные репозитории имеют меньший приоритет, чем подписанные;
  • репозитории обрабатываются в порядке их перечисления в конфигурационных файлах.

Проверить приоритеты репозиториев для конкретного пакета можно командой:

Подключение репозиториев на DVD дисках

вставить загрузочный диск в привод и выполнить команду:

sudo apt-cdrom add
sudo apt update

для подключения диска со средствами разработки нужно еще вставить диск со средствами разработки и выполнить команду:

sudo apt-cdrom add
sudo apt update

Подключение образов ОС скопированных на локальный жесткий диск

создать копию DVD диска на локальном жестком диске можно выполнив команду:

sudo dd if=/dev/cdrom of=/opt/cd.iso bs=1M

или просто скопировав содержимое диска в выбранную папку.

Смонтировать iso файл в выбранную папку можно выполнив команду:

sudo apt update

Подключение репозиториев текущей версии orel-stable- 2.12

В /etc/apt/sources.list прописать путь к основному репозиторию (stable):

Или, по необходимости, к репозиторию testing или experimantal:

Не рекомендуется подключать одновременно репозитории testing и experimental, так как их совместимость друг с другом не гарантируется.

sudo apt update

sudo apt dist-upgrade

Подключение репозиториев Debian 9 "Stretch"

С установкой пакета debian-archive-keyring

Для Astra Linux Common Edition 2.12.8 установить пакет dirmngr для управления ключами и пакет debian-archive-keyring, содержащий ключи к репозиториям Debian:

В /etc/apt/sources.list добавить ссылку на репозиторий Debian:

После добавления ссылки выполнить команду

sudo apt update

Если пакет debian-archive-keyring установлен, то команда должна отработаться без ошибок.
Если пакет debian-archive-keyring не установлен, то команда сообщит, что не может проверить подписи репозитория, и сообщит, какие именно ключи нужны для проверки.

На момент написания этой статьи к репозиторию Stretch относится третий, последний отпечаток.

Для Astra Linux Special Edition пакет debian-archive-keyring может быть установлен из репозитория Astra Linux Common Edition после подключения этого репозитория или командами:

В примере команды указана версия пакета, доступная на момент написания примера, при изменении версии команда должна быть откорректирована.

Без установки пакета debian-archive-keyring

Для того, чтобы установить ключ проверки подлинности:

  1. Установите пакет dirmngr (если он ранее не установлен) и
  2. Используйте команду apt-key с указанием нужного отпечатка:

    Временно изменить настройки DNS, оставив только сервер DNS 8.8.8.8, после чего попробовать получить ключи вышеуказанной командой.
    После успешного получения ключей настройки можно восстановить.

После установки ключа репозитория обновите список пакетов:

sudo apt update

Ключ репозитория Stretch действителен до 2025-го года, если установлен пакет debian-archive-keyring ключи будут обновляться автоматически по мере обновления пакета.

Проверить список установленных ключей можно командой

Подключить репозиторий можно и без установки ключей, однако данный способ не рекомендуется к применению, так как при этом проверка подлинности данных, получаемых из репозитория, становится невозможной. Для отключения проверки ключей в определении репозитория нужно указать дополнительный ключ trusted=yes:

Для отключения проверки ключей в определении репозитория нужно указать дополнительный ключ trusted=yes:

Подключение репозитория выпуска orel-frozen - 1.11

далее в терминале выполнить:

Для обновления дистрибутива:

Подключение репозитория с пакетами из проекта debian (wheezy)

Процедура получения ключа для репозитория Wheezy в целом аналогична процедуре для Stretch (см. выше), отличаются только строка с адресом репозитория и ключ.

далее в терминале выполнить:

И, если пакеты с ключами ранее не установлены, по полученной подсказке получить ключи для репозитория.
Ключ (на момент написания этой статьи) следует получать по отпечатку 6FB2A1C265FFB764 :

Подключение репозиториев скопированных на локальный жесткий диск

Перед копированием файлов на локальный жесткий диск рекомендуется убедиться, что в файловой системе достаточно свободного места. Сделать это можно командой:

Допустим, у вас запущен сервер, и вы не хотите переходить на Testing (Squeeze) из Stable (Lenny), чтобы просто установить необходимый пакет или два.

Каков наилучший способ установки только определенных пакетов из Testing?

Вот что говорит последняя официальная документация: пакеты из смешанного источника архивов .

Многие люди, похоже, боятся смешивать стабильное с тестированием, но, честно говоря, тестирование само по себе довольно стабильно, и с правильными настройками и проверкой решений вы можете избежать «дрейфа стабильности», который ставит ваши основные пакеты на нестабильный путь.

"Тестирование довольно стабильно ??" , ты спрашиваешь. Да. Для того чтобы пакет мог перейти от нестабильного к тестируемому, он должен иметь ноль открытых ошибок в течение 10 дней подряд. Скорее всего, что, особенно для более популярных пакетов, кто-то собирается представить отчет об ошибке для нестабильной версии, если что-то не так.

Даже если вы не хотите смешивать окружения, все равно хорошо иметь такую ​​возможность на случай, если вы столкнетесь с чем-то, что требует более новой версии, чем в стабильной.

Вот что я рекомендую для настройки:

Сначала создайте следующие файлы в /etc/apt/preferences.d :

stable.pref :

testing.pref :

unstable.pref :

experimental.pref :

(Не бойтесь нестабильных / экспериментальных вещей здесь. Приоритеты достаточно низкие, чтобы никогда не устанавливать автоматические компоненты. Даже ветвь тестирования будет вести себя так, как она будет устанавливать только те пакеты, которыми вы хотите быть. в тестировании.)

Теперь создаем соответствующий набор для /etc/apt/sources.list.d :

stable.list Копирование из оригинала /etc/apt/sources.list . Переименуйте старый файл в нечто подобное sources.list.orig .

testing.list То же, что stable.list и с testing .

unstable.list : То же, что stable.list , кроме как unstable , и удалить списки безопасности.

experimental.list То же, что unstable.list и с experimental .

Чтобы установить тестовую версию пакета, просто используйте aptitude install lib-foobar-package/testing или просто перейдите в графический интерфейс aptitude и выберите версию в деталях пакета (нажмите enter в пакете, который вы просматриваете).

Если вы получаете жалобы на конфликты пакетов, сначала посмотрите на решения. В большинстве случаев первым будет «не устанавливать эту версию». Научитесь использовать варианты разрешения и разрешения для каждого пакета. Например, если вы устанавливаете foobar-package / testing, а первое решение - «не устанавливать foobar-package / testing», то пометьте этот выбор как отклоненный, и другие решения больше никогда не повернут по этому пути. В таких случаях вам, вероятно, придется установить несколько других пакетов тестирования.

Если он становится слишком проблематичным (например, пытается обновить libc или ядро ​​или какую-то другую огромную базовую систему), то вы можете либо отклонить эти пути обновления, либо просто полностью отказаться от первоначального обновления. Помните, что обновление будет происходить только до тестирования / нестабильности, если вы разрешите это.

РЕДАКТИРОВАТЬ: Исправлены некоторые приоритетные булавки и обновлен список.

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

  1. Pinning
    1. /etc/apt/sources.list
    2. /etc/apt/preferences
    3. Установка из unstable
    4. Примечания от Joshua Rodman
    5. Примечания от ZugSchlus
    6. Примечания от Ryan B.
    7. Примечания от Georgios Zarkadas
    8. Примечания от Дмитрия Матросова

    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 или unstable. Вы можете, конечно же, изменить это на stable.

    /etc/apt/preferences

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

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

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

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

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

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

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

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

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

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

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

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

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

    Disclaimer

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

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

    -->Здесь написано мнение одного пользователя.

      Игнорировать пакеты, которые не отвечают критериям версии
    • Этот шаг вероятно должен быть пропущен, если закрепление ничему не соответствует

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

    Пример 1

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

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

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

    Пример 3

    От Mihamina rakotomandimby

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

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

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

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

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

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

    Origin: Your Company

    Label: Your Company Debian repository

    Таким образом, строка: "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)

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

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

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

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

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

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

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

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

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

    linux-logo

    Сегодня в статье рассмотрим, как можно избавиться от надписи в командной строке:

    При выполнении в Ubuntu команды вида:

    в терминале появляется ошибка:

    Ошибка может появляться не только при выполнении apt install , но и при любых других действиях с apt или apt-get .

    Данные ошибки появляются, когда программа apt-get (apt) не может получить доступ к файлу блокировки /var/lib/dpkg/lock* . Данный файл используется, чтобы запретить одновременное выполнение операций, связанных с управлением пакетами в системе, так как при одновременном изменении данных о пакетах будет нарушена целостность «пакетной базы».

    Обычно существует две основные причины появления, описанных выше ошибок:

    • В данный момент уже выполняется экземпляр программы apt-get (apt).
    • Предыдущий вызов apt-get (apt) завершился некорректно.

    Способ первый

    Сначала нужно проверить, что уже не запущен другой экземпляр программы apt-get (apt). Выполним следующую команду, чтобы проверить есть ли apt в списке запущенных процессов:

    Вывод команды может быть следующим:

    В первой строке мы видим, что уже есть работающий экземпляр программы apt-get, который имеет PID (идентификатор) 9425.

    Вторая строка относится к нашей команде grep , которую мы запустили с аргументом apt, поэтому она вывела саму себя. Итак, нас интересует только первая строка.

    Если вы уверены, что не запускали программу apt-get сами, или она не запущена в фоновом режиме, например, выполняется автоматическое обновление системы, то нужно принудительно завершить ее выполнение. Для этого воспользуемся командой kill −9 . Команде нужно указать числовой идентификатор процесса. В нашем случае это 9425. Выполняем команду:

    После выполнения данной команды, процесс с идентификатором 9425 завершится.

    Можно воспользоваться еще одним простым способом — это завершить все экземпляры программ apt и apt-get сразу. Для этого можно выполнить команду:

    Способ второй

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

    Нам нужно удалить все файлы блокировки. Для этого выполняем команды:

    После этого нужно выполнить переконфигурацию (донастройку) пакетов:

    Заключение

    Мы рассмотрели два способа решения ошибок, связанных с доступом к файлу блокировки dpkg. Как правило, эти способы помогают в решении.

    Если есть вопросы, то пишем в комментариях.

    Также можете вступить в Телеграм канал, ВК или подписаться на Twitter. Ссылки в шапки страницы.
    Заранее всем спасибо.

    Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

    Читайте также: