Bug 18877

Проблема, связанная с механизмом cleanup: https://bugs.etersoft.ru/18827

Суть в том, что apt-mark не провайдит виртуальные пакеты, из-за чего механизм cleanup отрабатывает не до конца. В текущем MR (https://gitlab.eterfund.ru/ximperlinux/mkimage-profiles/merge_requests/7) я решил эту проблему, но это не очень чистое решение с точки зрения архитектуры.

Я предлагаю несколько вариантов решения проблемы:
> Вариант 1:
> Оставляем всё, как есть с текущим MR. Очищаем виртуальные пакеты сами.
> Плюсы: это работает. Несмотря на большой код, у него очень простая логика и ничего опасного он не использует. 
> Минусы: это не очень чистое решение. Вместо того, чтобы сразу маркировать нужные пакеты, мы делаем отдельную логику для виртуальных пакетов.
> 
> Вариант 2:
> Делаем патч в APT, чтобы apt-mark научился работать с виртуальными пакетами. Я протестировал, это работает.
> Плюсы: это избавляет от большого куска кода в mkimage-profiles, решение становится архитектурно простым.
> Минусы: необходима тщательная проверка патча, чтобы не возникло никаких побочных эффектов, ибо обновлённый apt попадёт также и пользователям.
> 
> Вариант 3:
> Делаем патч в installer-alterator-pkg, чтобы он провайдил виртуальные пакеты и маркировал их. Можно использовать для этого и epm.
> Плюсы: также избавляет от большого куска кода в mkimage-profiles, архитектурно решение простое и не влияет на работу apt, только на установщик.
> Минусы: нужно либо добавить в поддержку epm провайд виртуальных пакетов при epm mark (я пока не исследовал этот вопрос, возможно это уже реализовано), либо реализовывать свои функции для этого в коде установщика.
> 
> Вариант 4:
> Избавляемся от всех виртуальных пакетов. Виртуальные пакеты можно фиксировать в bin/check-pkg-list и других местах, например, в логах установки.
> Плюсы: избавляемся от неопределённости виртуальных пакетов (нет ситуаций, когда они провайдить кучу разных пакетов и создать проблемы)
> Минусы: это очень крайний вариант, ибо потребует переписать базовые листы в pkg.in, а также может создать дополнительные неудобства при дальнейшем сопровождении
> 
> В данный момент я предлагаю оставить вариант 1 и выпустить Ximper 0.9.4. После этого завести отдельную багу и продолжить обсуждение, к какому решению придти.

Виталий высказался: первый вариант оставляем для Ximper 0.9.4; второй не примут в apt, поскольку его нет в Debian; третий же вариант выглядит достаточным — epm mark научился работать с виртуальными пакетами, и существуют планы по отказу от apt.

У кого ещё какие мысли?