Необходимо проверить следующее изменение: https://gitlab.eterfund.ru/lav/mkimage-profiles/commit/fae95ee8b4bf16af3810181022fcb59735ab26f7 Это исправляет выбор софта в установщике после изменения метода установки образа с live-installer-pkg на live-installer. Как минимум, надо проверить, остаётся ли софт из LiveCD в уже установленной системе.
Собрал новый образ (пришлось выполнить git cherry-pick из текущей next и 0.9.4 ветки). В установщике убрал галочку напротив Telegram, но после установки он всё равно остался. Интересно, но если прописать apt-get autoremove, то в системе откуда-то возьмутся 4 библиотеки: > [root@host-156 katze_942]# apt-get autoremove > Чтение списков пакетов... Завершено > Построение дерева зависимостей... Завершено > Calculating Autoremove... Завершено > Следующие пакеты будут УДАЛЕНЫ: > libaml libneatvnc libseat1 libturbojpeg Прикладываю логи установки: https://download.etersoft.ru/pub/people/katze/bug-18827/install-log/
Собрал новый образ с next веткой + https://gitlab.eterfund.ru/lav/mkimage-profiles/commit/8bf0240c6b1ab04e2961a098d5149aa0735ed95e Результат такой же, Telegram остался в установленной системе, хотя галочку в установщике я снимал. Даже вывод apt-get autoremove остался таким же. Вот логи: https://download.etersoft.ru/pub/people/katze/bug-18827/install-log-2/
Как я понимаю, выполняемые там скрипты берутся из пакета installer-common-base-stage2 Наши изменения/добавления просто туда не попали. Надо разобраться, как он формируется и почему он есть в Сизифе. Ожидаю увидеть в preinstall выполнение 01-mark-live-packages-auto А проверять нужно по четырём пакетам: 1. который есть в Live, но его нет в галочках вообще 2. который есть в Live и он есть в галочках, но галочка не стоит 3. который есть в Live и он есть в галочках, и галочка стоит 4. которого нет в Live и он есть в галочках, и галочка стоит
Было найдены две проблемы с текущим патчем. Первая проблема легко исправилась, нужно было заменить $(LIVE_PACKAGES) на $$(LIVE_PACKAGES) в ximper.mk. Иначе в distcfg.mk попадёт не обращение к переменной, а сразу её значение (которое будет пустым на момент чтения ximper.mk) Вторая проблема: LIVE_PACKAGES не затрагивает LIVE_LISTS (а там все приложения). Сам патч работает как надо, пакеты в LIVE_PACKAGES маркируются как надо и удаляются с установленной системы. Я изучал разные варианты решения проблем с LIVE_LISTS, удалось реализовать разные варианты и протестировать их, но мне нужно мнение остальных. Заранее скажу, что я проверял все места, в которых использовались листы и в mkimage-profiles нет функции, которая преобразовала бы листы в список пакетов. Поэтому, вероятно, нам нужно написать свою функцию (что я и сделал). Моей функции bin/lists2pkgs достаточно передать путь до листов и она преобразует их в список пакетов (без дубликатов). Теперь к вариантам того, как можно решить эту проблему (если у вас есть свой вариант, то пожалуйста, тоже опишите): - 1 вариант: объявить ещё CLEANUP_AUTO_LIVES, а в 89-cleanup-live-preinstall и 90-cleanup-live-install-pkgs преобразовывать все листы в список пакетов. Придётся импортировать functions.mk из image.in, чтобы можно было использовать функцию lists для получения абсолютных путей к файлам листов. - 2 вариант: вызывать функцию для преобразования листов в список пакетов в ximper.mk. Потребует импорта functions.mk из image.in (или написание своей list функции). Мне этот вариант не нравится, потому что значение переменной LIVE_LISTS не известно сразу и нужно будет каждый раз рассчитывать значение CLEANUP_AUTO_PACKAGES при вызове distcfg.mk (а вызывается он очень часто). Плюс располагать такие конструкции в conf.d не очень хорошая практика, как я прочёл. Вариант с удалением программ из Live мне не нравится, это обесценивает все текущие усилия и не решает саму проблему. Но сама проблема действительно специфична, но мне нравится первый вариант тем, что: 1. Листы и пакеты это разные сущности, поэтому не хотелось бы их смешивать их в _PACKAGES переменной. Единственное место, где они смешиваются в mkimage-profiles - это в IMAGE_PACKAGES при установке пакетов в образ. 2. Это в целом легко читается. Из изменений будет новый инструмент в bin/, ещё одна переменная и сама логика должна легко читаться. 3. В отличие от второго варианта, тут не потребуется писать свой форк функции list или применять ухищрения с подменой PKGDIR, потому что это будет происходить на этапе, когда все листы будут скопированы в нашу BUILDDIR (см. pkg.in/lists/Makefile). P.S: bin/lists2pkgs это очень простенький скрипт, который можно было бы даже не выделять в отдельный скрипт, но я не хочу дублировать код по двум файлам. Буду ждать мнение других. Если всех устроит какой-то вариант, то доработаю его, протестирую и выложу MR.
Изменил заголовок на более подходящий
Надо будет протестировать этот коммит: https://gitlab.eterfund.ru/lav/mkimage-profiles/commit/bf07e5127c34e768ad2245d4ff15ce5e7cbada2c Сохраняю здесь, чтобы потом не искать.
Протестировал текущий коммит: https://gitlab.eterfund.ru/lav/mkimage-profiles/commit/bf07e5127c34e768ad2245d4ff15ce5e7cbada2c К сожалению, не сработало. Я подозреваю это связано с тем, что chroot окружение другое совсем. Я попробовал реализовать свой первый способ, но столкнулся с тем, что это совершенно новое chroot окружение. Поэтому я не смог там использовать свой бинарник для разбиения листов на список пакетов. Я переделал свой первый вариант, вот все шаги, которые я предпринял: 1. Инициализирую CLEANUP_AUTO_LISTS и CLEANUP_AUTO_PACKAGES в ximper.mk 2. Создал generate.mk в фиче cleanup. Там происходит преобразование CLEANUP_AUTO_LISTS в список пакетов и добавляет его в CLEANUP_AUTO_PACKAGES (делает запись в distcfg.mk). При DEBUG=1 также выводит полезную дебаг-информацию. Протестировал и всё работает как надо, привёл код в порядок и сейчас занимаюсь исследованием слабых мест в текущем варианте. Сейчас беспокоят следующие вопросы: 1. Является ли переменная CLEANUP_AUTO_LISTS подходящим названием? Слово AUTO меня смущает, пока не узнаёшь, что речь про apt-mark auto 2. В CLEANUP_AUTO_PACKAGES попадают системно-важные пакеты. Например условный su. Это происходит из-за использования некоторых фич, которые добавляют в LIVE_LISTS такие листы. > COMMON_LISTS и THE_LISTS — общие листы и для Live и для целевой системы > LIVE_LISTS — листы исключительно для Live > > То есть сейчас у меня маркируются все пакеты из LIVE_LISTS. Но условный su в целевой системе остаётся, потому что он присутствует в других листах. И таком образом у нас выходят те пакеты, которые мы и хотели в целевой системе. Всё специфичное для Live отметается. > > Можно доработать скрипт, чтобы у нас в cleanup не попадали листы, которые также присутствуют в условном THE_LISTS. Поизучаю это Надо исследовать код и точно убедиться, что это надёжное решение. А если найдутся погрешности - то нужно доработать скрипт.
Готово, я доработал текущий вариант. В ходе этого я столкнулся с некоторыми багами, связанные с виртуальными пакетами. Все подробности описал в Merge Request: https://gitlab.eterfund.ru/ximperlinux/mkimage-profiles/merge_requests/7 После принятия Merge Request необходимо будет перенести его в next ветку, протестировать и если всё будет работать как надо - я отмечу данный баг-репорт как решённый.
Я разделил MR с удалением LibreOffice-still и с механизмом cleanup: Бага по LibreOffice-still - https://bugs.etersoft.ru/18871 Теперь что нам делать с виртуальными пакетами? Вариант 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. После этого завести отдельную багу и продолжить обсуждение, к какому решению придти.
(Ответ Жора Змейкин на комментарий #9) ... > Вариант 1: > Оставляем всё, как есть с текущим MR. Очищаем виртуальные пакеты сами. > Плюсы: это работает. Несмотря на большой код, у него очень простая логика и > ничего опасного он не использует. > Минусы: это не очень чистое решение. Вместо того, чтобы сразу маркировать > нужные пакеты, мы делаем отдельную логику для виртуальных пакетов. Оставляем для релиза 0.9.4 > Вариант 2: > Делаем патч в APT, чтобы apt-mark научился работать с виртуальными пакетами. > Я протестировал, это работает. > Плюсы: это избавляет от большого куска кода в mkimage-profiles, решение > становится архитектурно простым. > Минусы: необходима тщательная проверка патча, чтобы не возникло никаких > побочных эффектов, ибо обновлённый apt попадёт также и пользователям. В apt не примут, я думаю. потому что этого и в Debian APT нет. > > Вариант 3: > Делаем патч в installer-alterator-pkg, чтобы он провайдил виртуальные пакеты > и маркировал их. Можно использовать для этого и epm. > Плюсы: также избавляет от большого куска кода в mkimage-profiles, > архитектурно решение простое и не влияет на работу apt, только на установщик. > Минусы: нужно либо добавить в поддержку epm провайд виртуальных пакетов при > epm mark (я пока не исследовал этот вопрос, возможно это уже реализовано), > либо реализовывать свои функции для этого в коде установщика. epm mark уже научился работать с виртуальными пакетами. Выглядит достаточным. С учётом плана отказа от apt. > Вариант 4: > Избавляемся от всех виртуальных пакетов. Виртуальные пакеты можно > фиксировать в bin/check-pkg-list и других местах, например, в логах > установки. > Плюсы: избавляемся от неопределённости виртуальных пакетов (нет ситуаций, > когда они провайдить кучу разных пакетов и создать проблемы) > Минусы: это очень крайний вариант, ибо потребует переписать базовые листы в > pkg.in, а также может создать дополнительные неудобства при дальнейшем > сопровождении > > В данный момент я предлагаю оставить вариант 1 и выпустить Ximper 0.9.4. > После этого завести отдельную багу и продолжить обсуждение, к какому решению > придти. На будущее: эта задача должна была оставаться в рамках изначальной проблемы (механизма cleanup). То, что нужно уметь работать с виртуальными пакетами, должно быть отдельно. Сейчас получится, что всё своё исследование про виртуальные пакеты ты похоронишь в баге, которая в общем-то к ним не относится. Отдельную багу надо завести не потом, а сейчаc.
Фактическая задача выполнена, всё работает как надо. По вопросам текущей реализации заведена отдельная бага: https://bugs.etersoft.ru/18877
