Debian 12.1

когда удаление какой-нибудь GUI-шной программы тянуло за собой удаление DE (сам однажды видел, когда при попытке удалить firefox предлагалось выкосить xubuntu-desktop)

Удаление xubuntu-desktop ≠ удаление DE. Обычно это просто пустой метапакет.

он имел ввиду немного другой случай

Автор говорил конкретно о попытке удаления пакетов, от которых зависит полсистемы, и которые были когда-то установлены из стороннего репозитория deb-multimedia взамен дистрибутивных. Попробуйте сделать это в другом менеджере пакетов и полу́чите тот же результат.

Нет, тебе тоже предлагаю взять и запустить https сайт с взаимодействием с внешними ресурсами на el5. Сразу поймёшь, что миру ты такой не нужен.

Зависит от того, что за внешние ресурсы. У меня внешние ресурсы нынче даже не TLS, а ГОСТ хотят. Но это мне нужен ГОСТ для работы с ними, а не абстрактному миру.

К слову, вполне можно сделать TLS прокси даже на отдельной железке.

Сразу поймёшь, что миру ты такой не нужен.

А должен быть нужен? Миру вообще разве нужен хоть кто-то?

XP в виртуалке и туда msjava, оживил

Видимо, тогда ещё не догадались требовать заводить аккаунт на сервере производителя, раз получилось оживить обычной виртуалкой.
А более современный IoT-хлам потом только в мусорку

Железке ровно 20 лет, тогда ещё не было такого нецензурного ужаса.

А так да, ты абсолютно прав :)

https://t.me/infosecmemes/834

С Oracle Linux я не сталкивался. А в qemu-system-x86_64 -cpu core2duo федора пока запускается.

А зачем, если 10-й работает как часы. Ещё бы прекратил просить обновиться.

Или SLES

Они обещают форкнуть шляпу, так что будет вариант поинтереснее.

У меня внешние ресурсы нынче даже не TLS, а ГОСТ хотят.

Это специфический случай, я про общий.

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

А пока что просто найти пакеты из какой-то репы уже нетривиальная задача. Если вообще вспомнишь что они есть.

А я про то, что у каждого свой личный специфический случай. А «мир хочет, чтобы ты писал на JS с поддержкой TLS» — это язычество.

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

Автор говорил конкретно о попытке удаления пакетов, от которых зависит полсистемы

Прежде всего такой проблемы не должно было возникнуть - менеджер пакетов должен доложить пользователю о потенциальной проблеме в системе и предложить какое-то решение. Например, очистить систему от пакетов из этой отключённой репы, заменив на доступные. К сожалению в Дебиане всё это очень непросто.

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

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

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

Пытаться гадать на кофейной гуще — в большинстве случаев лишь вставлять пользователю палки в колёса.

Что же касается замены, то тут всё ещё проще: если эти пакеты можно обновить, то они обновятся, а если обновить их нельзя — т.е. их версии выше, чем во всех подключённых репозиториях — то downgrade официально не поддерживается, так что предлагать его ещё более неправильно.

А пока что просто найти пакеты из какой-то репы уже нетривиальная задача.

Что же там такого нетривиального?

Эти все задачи решаются разными способами. От «не общаться с сервисами, с которыми невозможно согласовать двусторонний API» до «сделать прокси (железный или в VM) для проблемных сервисов, если очень желаешь с ними общаться».

А другая часть мира в виде интерфейса к старому оборудованию и даже некоторым интернет-банкам потребует java-апплеты и поддержку TLS 1.0. Это тоже «мир хочет»?

Язычество, да?

Если свои желания приписываешь миру, то да.

Это вы просто сконцентрировались на вашем частном случае

Что же тут такого частного? Вполне себе обыкновенная ситуация. Возникала у меня несколько раз.

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

А зачем менеджеру пакета знать причину? Достаточно проверить что источник пропал, этого достаточно для того чтобы сообщить пользователю о проблеме.

Пытаться гадать на кофейной гуще

Зачем гадать? Всё просто, пропал источник - бьём тревогу.

downgrade официально не поддерживается,так что предлагать его ещё более неправильно.

А что же ещё предлагать, если другого выхода нет? Если это единственное возможное решение во многих случаях.

Да, с даунгрейдом это ещё одно проблема Дебиана, кстати. Но в другой плоскости.

Что же там такого нетривиального?

Много чего.

Начнём с того что я в принципе должен догадаться о том что в системе что-то не так. Как?

А другая часть мира в виде интерфейса к старому оборудованию

Уже много лет переехали на html5 и javaws, я знаю, что говорю, т.к. у меня есть старое личное оборудование :)

и даже некоторым интернет-банкам потребует java-апплет

Пруф можно?

Если свои желания приписываешь миру, то да.

Я просто реалист и работаю в реальном мире, а не в эльфляндии.

Что же тут такого частного? Вполне себе обыкновенная ситуация. Возникала у меня несколько раз.

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

А зачем менеджеру пакета знать причину?

Потому что это необязательно проблема. Я же привёл несколько примеров выше.

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

А какой из существующих менеджеров пакетов так делает, кстати?

Да, с даунгрейдом это ещё одно проблема Дебиана, кстати. Но в другой плоскости.

Раскройте мысль.

Начнём с того что я в принципе должен догадаться о том что в системе что-то не так. Как?

Т.е. отключить репозиторий вы догадались, а что могут остаться пакеты, установленные из отключённого репозитория — нет? Избирательная у вас догадливость какая-то.

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

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

1. пользователь отключил репозиторий?

Проблема? Да проблема, надо что-то делать. Если пользователь хочет оставить всё как есть, ему это надо указать, из-за этого репозитария не ругаться. Всё это можно выдать в диагностическом сообщении.

2. эти пакеты были установлены локально?

Проблема? Возможно! Если пользователь хочет оставить всё как есть, ему надо это специально где-то прописать, из-за локальных пакетов не ругаться вообще, или даже из-за вот этого конкретного пакета, на выбор.

3. это пакеты, бэкпортированные из других веток?

Какая вообще разница, откуда они бэкпортированы. Нет источника - ругаемся. Просто.

4. это пакеты, разработкой которых занимается пользователь?

Это вообще редкий случай, но давайте и его рассмотрим. В чём может быть здесь проблема? У пользователя нет своей репы и он ставит локально? Ну да, это нетривиально сделать репу из какого-то каталога. Тогда переход на пункт 2. У пользователя есть своя репа? Тогда переход на пункт 1.

Ещё примеры есть?

А какой из существующих менеджеров пакетов так делает, кстати?

Не знаю, я другими редко пользуюсь. Слыхал про дистрибутивы и пакетные менеджеры, которые позволяют и даунгрейд и даже параллельно несколько версий установить.

Раскройте мысль.

Что именно непонятно? Неплохо было бы иметь возможность делать даунгрейд официально и даже параллельно несколько версий.

Т.е. отключить репозиторий вы догадались, а что могут остаться пакеты, установленные из отключённого репозитория — нет? Избирательная у вас догадливость какая-то.

Даже если я об этом догадался (а мог бы и не подумать), то как я должен догадаться, что это проблема?

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

Уже много лет переехали на html5 и javaws, я знаю, что говорю, т.к. у меня есть старое личное оборудование :)

Значит недостаточно старое. Или офисное переводят не так шустро. У меня на работе есть МФУ и NAS, для которых есть виртуалка с Win XP.

Пруф можно?

https://brokerkf.ru/soprovozhdenie_klientov/technical-support/webbank/hardware-requirements/

Внимание! Для отправки поручений с помощью ЭП Signal-COM, требуется установленная Java-машина и Microsoft Internet Explorer версии 5 и выше под управлением ОС Windows.

Значит недостаточно старое.

Достаточно. Имею виртуалку для очень старого железа.

brokerkf.ru

Это не банк.

Ещё примеры есть?

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

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

Слыхал про дистрибутивы и пакетные менеджеры, которые позволяют и даунгрейд и даже параллельно несколько версий установить.

А данные они тоже откатят да параллельно несколько версий установят?

Вы, видимо, просто не понимаете сложности задачи.

Неплохо было бы иметь возможность делать даунгрейд официально и даже параллельно несколько версий.

Неплохо, да. Можете приступать к реализации.

Это нормально ожидать от пакетного менеджера что он сам способен детектировать проблемы с целостностью системы, по крайней мере элементарные. Убрал репу - всё.

С какого перепуга отключённый репозиторий — это проблема аж с целостностью системы?

Короче, мне надоело переливать из пустого в порожнее. Отправьте багрепорт с Severity: wishlist разработчикам, если считаете это такой важной задачей, — пусть они вам объясняют.

Достаточно. Имею виртуалку для очень старого железа.

Так переехали на html5 или приходится иметь виртуалку?

Это не банк.

Были брокерские услуги банка (с тем же названием). Теперь банковской лицензии нет, брокерские остались.

Так переехали на html5

Часть (новая) переехала на html5, часть (почти все, чуть более старые) переехали на javaws. 1 древний сервер (совсем древность, которую и держать в компании нерентабельно) глубокий EOL и никуда не переехала, остались на java applet, сгорел недавно и наконец-то :))

приходится иметь виртуалку?

Приходится, я же писал выше Debian 12.1 (комментарий)

Были брокерские услуги банка (с тем же названием). Теперь банковской лицензии нет, брокерские остались.

А неважно. К банкам гораздо более сильные требования, чем к брокерам, поэтому у банка в банк-клиенте быть такого не может уже давно, я очень чётко помню переезд БК в нескольких конторах с java applet.

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

локально установленные пакеты не являются проблемой в общем случае;

Да пожалуйста, отключим для локальных пакетов сообщения по-умолчанию. Я у себя включу.

Ещё примеры будут? Или это всё?

А данные они тоже откатят да параллельно несколько версий установят?

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

С какого перепуга отключённый репозиторий — это проблема аж с целостностью системы?

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

мне надоело … пусть они вам объясняют

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

И это мы ещё не перешли к остальным проблемам. Затронули только тему элементарной (!!!) диагностики.

И это мы ещё не перешли к остальным проблемам. Затронули только тему элементарной (!!!) диагностики.

Я ещё более-менее понимаю, как устроен Дебиан и могу благодаря своему опыту хотя бы понять, что не так с системой, и то мне понадобилось время и помощь, чтобы разобраться в элементарной проблеме, которой не должно было даже возникнуть. Разве это можно ожидать от обыкновенного пользователя?

Но разработчикам апт обязательно напишу.

Да пожалуйста, отключим для локальных пакетов сообщения по-умолчанию. Я у себя включу.

Вывод всех пакетов, установленных локально:

# cat >/etc/apt/apt.conf.d/99-list-orphaned-packages.conf <<CONF
APT::Update::Post-Invoke {
    "/usr/bin/apt list '?narrow(~i,!~O.*)'";
}
CONF

Можно даже вывести лишь те пакеты, которые установлены локально, но которые в какой-то версии присутствуют в репозиториях Debian:

# cat >/etc/apt/apt.conf.d/99-list-orphaned-packages.conf <<CONF
APT::Update::Post-Invoke {
    "/usr/bin/apt list '?any-version(?narrow(~i,!~O.*))~O^Debian$'";
}
CONF

В обоих случаях список будет выводиться при apt update.

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

Это ровным счётом никак не относится к тому, имеет ли пакет источник или установлен локально.

Вывод всех пакетов, установленных локально:

Странный список он мне выдаёт. Например пишет что у меня локально стоит clang-11. Но я никогда не скачивал и не ставил руками clang-11!

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

Это ровным счётом никак не относится к тому, имеет ли пакет источник или установлен локально.

Да как же не имеет. Это частый сценарий

1. Я подключаю репу с нужным софтом, из неё что-то ставлю
2. Пакет тянет за собой какие-то зависимости
3. Мне это что-то мне не нравится или больше не нужно, я отключаю репу, возможно удаляю пакет (или нет), зависимости точно остаются висеть в системе

Далее что можно ожидать?

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

2. Также должна быть также команда, которая выведет список таких зависших пакетов и соответствующих им отключенных источников. То есть список

пакет1  источник1
пакет2  источник2
...

Далее я уже смотрю и решаю, отключаю ли я сообщение для определённого источника/пакета или нет. Где-то прописываю в конфиге это.

Далее нужна команда чистки системы от таких пакетов. Причём не просто удаление, а переустановка (возможно с даунгрейдом) из доступных источников.

То есть типа

apt systemcleanup источникХ

Или даже просто

apt systemcleanup

чтобы почистить систему полностью

Странный список он мне выдаёт. Пишет что у меня локально стоит clang-11. Но я никогда не скачивал и не ставил руками clang-11!

А при чём здесь «руками»? Значит, когда-то прилетал по зависимостям, а документацию по обновлению вы читали не очень внимательно и шаг с удалением устаревших пакетов пропустили.

Более того, официальная документация рекомендует отключать сторонние репозитории на время обновления, что вы, похоже, тоже не стали делать. Ну и кто теперь ССЗБ?

Да как же не имеет

Да вот так. Ломает ли какой-то пакет что-то в системе или нет абсолютно не зависит от того, имеет он сейчас нелокальный источник или нет.

зависимости точно остаются висеть в системе

С чего бы это вдруг?

А при чём здесь «руками»? Значит, когда-то прилетал по зависимостям, а документацию по обновлению вы читали не очень внимательно и шаг с удалением устаревших пакетов пропустили.

Тогда я не понимаю, что Вы вкладываете в слово «локальный». Я знаю два способа получить пакет в системе - либо установить из репы (официальной или нет), т.е. из удалённого источника, либо скачать/собрать пакет и установить его ручками из файла, то есть локально.

Да вот так. Ломает ли какой-то пакет что-то в системе или нет абсолютно не зависит от того, имеет он сейчас нелокальный источник или нет.

Теоретически разработчики Дебиана могут закачать в свою репу пакет, который будет ломать систему. Точно так же (но с большей вероятностью) ошибку могут допустить сопровождающие стороннего репозитория. Но речь сейчас идёт не о такой ситуации. В моём случае таких ошибок не было. Пока сторонний источник был подключен и обновления ставились как положено, всё работало и работало бы дальше. Проблемы начались именно тогда и из-за того что я отключил сторонний репозиторий.

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

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

С чего бы это вдруг?

А чего бы они удалялись?

Тогда я не понимаю, что Вы вкладываете в слово «локальный».

То же, что разработчики apt: пакет установлен, но не имеет источника.

Я знаю два способа получить пакет в системе - либо установить из репы (официальной или нет), т.е. из удалённого источника, либо скачать/собрать пакет и установить его ручками из файла, то есть локально.

А ещё можно установить пакет из репозитория, а затем удалить этот репозиторий. Такой пакет также будет считаться локальным, потому что не имеет соответствующего ему источника.

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

Проблема там на самом деле в том, что в deb-multimedia за каким-то чёртом поставили для своего пакета бо́льшую эпоху, чем у пакета в Debian, отчего тот и не обновился до версии в bookworm. При этом версия ABI якобы такая же, как в пакете в Debian, но на самом деле нет.

Да и просто возможность привести Дебиан в первоначальный вид (например для того чтобы убедиться что баг не из-за стороннего пакета) будет очень полезна

Такая возможность есть и сейчас через установку приоритета для репозитория Debian > 1000, но чтобы сделать это командой в apt, нужно официально поддерживать downgrade, чего не будет.

А чего бы они удалялись?

apt autoremove отменили?

То же, что разработчики apt: пакет установлен, но не имеет источника.

Выше[1] Вы различаете пакеты «установленные локально» и пакеты, которым пользователь отключил репу после установки: «пользователь отключил репозиторий? эти пакеты были установлены локально?». Я понял это так, что «пакеты установленные локально» == пакеты скачанные и установленные вручную. В отличие от тех что скачаны из репы с помощью apt. Я неверно Вас понял? Как Вы предлагаете их различать в нашем обсуждении?

1. Debian 12.1 (комментарий)

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

Во всех остальных случаях наличие локальных пакетов (== пакетов без источника) следует рассматривать как нестандартную и потенциально опасную ситуацию.

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

Проблема там на самом деле в том, что в deb-multimedia за каким-то чёртом поставили для своего пакета бо́льшую эпоху, чем у пакета в Debian, отчего тот и не обновился до версии в bookworm. При этом версия ABI якобы такая же, как в пакете в Debian, но на самом деле нет.

Это всё понятно. Но пакеты вполне себе обновились бы из deb-multimedia, если бы я не отключил deb-multimedia. А с отключённым источником тоже самое будет и без эпохи, если версия установленного пакета из стороннего репозитория будет выше чем версия пакета в bookworm. Всё это ясно. Серьёзнейшая проблема, которая привела к установке бинарно-несовместимых библиотек осталась незамеченной мною (опытнейшим пользователем, программистом), а главное пакетный менеджер Дебиан не заметил этого, хотя мог бы достаточно легко это сделать. Что Вы ожидаете от обыкновенного пользователя? А потом кто-то удивляется что появляются флэтпаки, снапы и прочие аппимаджи. Так потому и появляются!!! Если ничего не делать для решения проблем десятилетиями, вполне логично что найдётся кто-то кто попробует эту проблему решить. Но уже по-своему.

Такая возможность есть и сейчас через установку приоритета для репозитория Debian > 1000, но чтобы сделать это командой в apt, нужно официально поддерживать downgrade, чего не будет.

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

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

Проблему с pysolfc решил.

sudo flatpak install PySolFC

исправили 89 ошибок и 26 уязвимостей

Как-то дофига, не находите? Количество ошибок стремиться к Ubuntu.

Выше[1] Вы различаете пакеты «установленные локально» и пакеты, которым пользователь отключил репу после установки: «пользователь отключил репозиторий? эти пакеты были установлены локально?». Я понял это так, что «пакеты установленные локально» == пакеты скачанные и установленные вручную. В отличие от тех что скачаны из репы с помощью apt.

Принимается, в данном случае я выразился недостаточно точно. Должно было быть «установлены не из репозитория».

apt считает локальными те пакеты, у которых нет источника; напротив них в выводе apt list указано «локальный».

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

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

пакетный менеджер Дебиан не заметил этого, хотя мог бы достаточно легко это сделать

Чтобы надёжно замечать подобные проблемы, зависимости должны выражаться не на уровне имён файлов, и даже не на уровне SONAME, а на уровне отдельных символов. Можете это предложить разработчикам, конечно, но индекс репозиториев в таком случае распухнет на порядок.

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

Это будет команда, которая делает исключительно downgrade, ибо для всего остального уже есть [full-]upgrade.

Вас не затруднит расшифровать вот эту часть - ‘(?narrow(~i,!~O.*))’?

Я понимаю что оно делает, но интересуют детали по флагам. А также прокомментировать чем оно принципиально отличается от ‘apt list ~o’?

Ну и было бы вообще шикарно, если подскажете где почитать про эти флаги. В мане по apt у меня ничего не находиться, ни по narrow, ни по ‘~O’. Да и гугель ничего адекватного не выдал, кроме двух примеров поиска на Debian Wiki

Вероятно этот синтаксис образцов поиска взят из aptitude. Документирован тут: https://www.debian.org/doc/manuals/aptitude/ch02s04.en.html (не знаю, всё ли реализовано в apt и нет ли каких-нибудь дополнительных возможностей).

Я понимаю что оно делает, но интересуют детали по флагам.

Это выражение выбирает установленные пакеты без origin (o= в выводе apt policy).

~O (?origin) и ~i (?installed) объяснять, наверное, не надо.

?narrow выбирает лишь те пакеты, которые удовлетворяют обоим выражениям в одной и той же версии. Без него ~i может удовлетворять одна версия, а !~O — другая.

А также прокомментировать чем оно принципиально отличается от ‘apt list ~o’?

~o (?obsolete) выбирает пакеты, которые ни в одной своей версии не существуют в репозиториях, что для нашей задачи не подходит, ибо нам нужны пакеты, которые не существуют в репозиториях для установленной версии.

Ну и было бы вообще шикарно, если подскажете где почитать про эти флаги

В man apt-patterns.

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

Об этом вообще невозможно догадаться. Причём невозможно догадаться ни о том что репа заменяет системные пакеты, ни тем более о том как и где это может вылезти.

И здесь всё те же мысли.

Если замещение системных пакетов неофициальным это очень плохая вещь (потому что даунгрейд официально не поддерживается?), то опять же apt при попытке заместить системные пакеты должен выводить большой красный транспарант (диагностика!) и требовать какую-нибудь специальную опцию «дасделайэтопожалуйстамнеоченьнадояпонимаюпоследствия» для этого (защита). А если apt молча и с удовольствием устанавливает замещающие неофициальные системные пакеты, то он точно также молча и с удовольствием должен делать их неофициальный даунгрейд до официальных.

Далее, если пользователю нужна функция ХХХ, то он (после того как не найдёт её в Дебиане), спросит Гугл. Гугл ему услужливо подбросит ссылку на соответствующую неофициальную репу с инструкцией по установке. Где предупреждение пользователя о какой-то потенциальной опасности? Опять же, это задача apt. Обнаружив сомнительную репу собирающуюся заместить системные пакеты, он должен предупредить об этом.

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

Чтобы надёжно замечать подобные проблемы, зависимости должны выражаться не на уровне имён файлов, и даже не на уровне SONAME, а на уровне отдельных символов. Можете это предложить разработчикам, конечно, но индекс репозиториев в таком случае распухнет на порядок.

Вы можете привести пример, когда моё предложение будет вредить? Возможно я что-то упускаю, но разве сложно заметить замещающие системные пакеты из отключенного источника? Как может навредить предупреждение о них?

Это будет команда, которая делает исключительно downgrade, ибо для всего остального уже есть [full-]upgrade.

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

Премного благодарен. За ссылку отдельное большое спасибо.

Вопрос про ‘~o’ остался: как я понял ‘(~i,!~O.*)’ - это все установленные пакеты AND не совпадающие ни с одним origin, a ‘~o’ - это ‘осиротевшие’ установленные пакеты, которые не существуют ни в одном из зарегистрированных в системе репозиториев. Что по моему одно и то же. Но это я уже сам. Потыкаю кнопочки, почитаю, разберусь.

Об этом вообще невозможно догадаться. Причём невозможно догадаться ни о том что репа заменяет системные пакеты, ни тем более о том как и где это может вылезти.

apt напишет об обновляемых пакетах при попытке установки чего-либо из такого репозитория. Это уже красный флаг.

Если замещение системных пакетов неофициальным это очень плохая вещь (потому что даунгрейд официально не поддерживается?)

Нет, не поэтому, а потому что разработчики Debian не могли протестировать и потому не могут поддерживать работоспособность с такими неизвестно кем и как собранными пакетами.

apt при попытке заместить системные пакеты должен выводить большой красный транспарант (диагностика!) и требовать какую-нибудь специальную опцию «дасделайэтопожалуйстамнеоченьнадояпонимаюпоследствия» для этого (защита).

Предложите это разработчикам.

Как может навредить предупреждение о них?

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

Да, она будет делать исключительно официально неподдерживаемый downgrade.

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

Вопрос про ‘~o’ остался: как я понял ‘(~i,!~O.*)’ - это все установленные пакеты AND не совпадающие ни с одним origin, a ‘~o’ - это ‘осиротевшие’ установленные пакеты, которые не существуют ни в одном из зарегистрированных в системе репозиториев. Что по моему одно и то же.

Давайте рассмотрим пример. Допустим, мы вручную скачали и установили пакет libfoo 1.1, обновив дистрибутивный libfoo 1.0.

~o выберет установленные пакеты, не существующие ни в одном репозитории ни в одной из версий. Пакет libfoo установлен, но его версия 1.0 имеет активный источник (репозиторий дистрибутива), поэтому он не попадёт в вывод ~o.

Далее, рассмотрим ~i!~O.*. Это выражение состоит из нескольких частей:

1. ~i — выберет пакеты, какая-то версия которых установлена.

2. ~O.* — выберет пакеты, какая-то версия которых имеет origin.

3. !~O.* — это отрицание 2., т.е. выберет пакеты, ни одна из версий которых не имеет origin (см. законы де Моргана).

libfoo под это сложное условие не попадёт, поскольку несмотря на то что одна из его версий установлена, существует версия (1.0), которая имеет origin (репозиторий дистрибутива).

?narrow(~i,!~O.*) же заставляет оба выражения применяться к одной и той же версии, т.е. получаем «какая-то версия пакета установлена, и она же не имеет origin» — теперь libfoo подходит, поскольку установлена версия 1.1, и она не имеет origin.

apt напишет об обновляемых пакетах при попытке установки чего-либо из такого репозитория. Это уже красный флаг.

Ну да, заметить апгрейд можно признаю.

Но это мне понятно, что красный флаг (и то, понадобилось время для обнаружения проблемы, потому что делал я это года 3 назад), Вам понятно. Как об этом может догадаться обыкновенный пользователь, устанавливающий свой любимый видеоредактор?

Просто понять последствия - уже непросто. Ведь всё будет работать. Проблемы начнутся тогда и только тогда, когда он просто отключит источник. Но он об этом не будет знать, пока не сделает апгрейд и сломает пол системы! А это случится года через 2-3, когда он уже забудет, что когда-то что-то подключал!

А если захочет исправить, то не сможет простой командой заместить неофициальный пакет официальным, ему апт предложит снести пол-системы.

Делать же официальную команду, которая исключительно выполняет официально не поддерживаемое действие — ну такое.

Официально неподдерживаемое действие для отмены официально поддерживаемого действия по установке официально неподдерживаемых пакетов :)

Ага, доехал. Проморгал narrow с его ‘any version’. Ещё раз спасибо.

файрфокс в снапе наверно

Если снап полностью отключить ошибками сыплет. Там и гном поумолчанию оттуда же обязан браться.

Ну гном то не нужен, а вот фф нужен.

Делать же официальную команду, которая исключительно выполняет официально не поддерживаемое действие — ну такое.

Что-то я недопонимаю:

aptitude install «pkg»=«version»

Это как бы даунгрейд? Или нет?

Необязательно. Это ручной выбор версии пакета вместо автоматического.

Не вполне понимаю, что вы хотите сказать. Что downgrade технически возможен? — так никто и не утверждал обратное. Речь о том, что он не поддерживается, т.е. с возникающими при этом проблемами в багзиллу можете не соваться.

aptitude выдает полный список пакетов, который нужно будет даунгрейднуть. Что еще нужно?

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