Как узнать установленную версию пакета и источник обновлений в Ubuntu

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

Вывод показывает пакет, полную версию и статус. Сообщение об отсутствии пакета не доказывает отсутствие программы: она могла быть установлена вручную, в контейнере или под другим пакетным именем.

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

Для состояния локального кэша APT:

Команда показывает установленную версию, кандидата и доступные источники согласно имеющимся индексам и приоритетам. Она не обновляет пакеты и не гарантирует, что индексы свежие. Если списки давно не обновлялись, вывод не отражает последние изменения репозиториев.

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

Пример: пакет обновлён, но сервис запущен из другого пути. Тогда состояние dpkg не описывает реально обслуживающий сайт бинарный файл. Проверьте команду запуска и архитектуру развёртывания, прежде чем объявлять обновление завершённым.

Контейнер представляет ещё один уровень: обновление пакета на хосте не заменяет содержимое уже используемого образа. Для него важны версия образа, способ сборки и процедура развёртывания. Не смешивайте эти сведения в одной строке «сервер обновлён».

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

Если вопрос касается конкретного исправления, ищите его в официальном уведомлении поставщика для своего выпуска системы и полного номера пакета. Номер upstream без учёта дистрибутивной сборки может привести как к ложной тревоге, так и к ложному спокойствию.

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

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

The terminal displays the program number, but that is insufficient for maintenance. You need to know where it was installed and how it receives fixes. A package from a repository, a manually compiled build, and a program inside a container may share a similar name but have completely different update procedures.

The output shows the package, full version, and status. A message stating the package is missing does not prove the program is absent: it could have been installed manually, inside a container, or under a different package name.

The full package version contains more information than the short program number. A distribution may backport fixes into its build without moving to the latest upstream branch. Therefore, evaluating the presence of a fix based only on the first digits of the version is incorrect.

For the local cache state of APT:

The command displays the installed version, the candidate, and available sources based on existing indexes and priorities. It does not update packages and does not guarantee that indexes are current. If lists have not been updated for a long time, the output will not reflect the latest changes in repositories.

The candidate is determined by the version selection policy. It may differ from the highest version number you have seen on the developer's website. Repository restrictions, version pinning, and maintenance settings must be considered separately.

Example: the package is updated, but the service is launched from a different path. In this case, the dpkg state does not describe the binary file actually serving the site. Check the launch command and deployment architecture before declaring the update complete.

A container represents another layer: updating a package on the host does not replace the contents of an already used image. For the image, the version, build method, and deployment procedure are critical. Do not mix these details into a single statement like 'server updated'.

Adding a new source changes the trust chain and subsequent package selection. This is a separate change that requires understanding compatibility and the order of operations. For initial diagnostics, it is sufficient to read the current policy and note the discrepancy.

If the question concerns a specific fix, look for it in the vendor's official advisory for your system release and full package number. An upstream number without the distribution build can lead to both false alarms and false security.

Record the system release, package, installed version, candidate, source, and application launch method. Note the freshness of indexes and the presence of manual components separately. These data points allow you to formulate a justified update plan.

After a coordinated change, verify not only the record in the package database but also the actual version of the running service, followed by the user scenario. Package source diagnostics do not perform the update themselves; they make the subsequent decision verifiable and help avoid affecting an unsuitable environment.