Необходимо проверить следующее изменение: 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 ветку, протестировать и если всё будет работать как надо - я отмечу данный баг-репорт как решённый.
