Проблема, связанная с механизмом 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. У кого ещё какие мысли?
