Summary: | [FR] ручка для регулировки поведения при раскрытии списков пакетов | ||
---|---|---|---|
Product: | Sisyphus | Reporter: | Michael Shigorin <mike> |
Component: | mkimage | Assignee: | Michael Shigorin <mike> |
Status: | CLOSED FIXED | QA Contact: | qa-sisyphus |
Severity: | enhancement | ||
Priority: | P3 | CC: | antohami, boyarsh, cas, glebfm, klark.devel, legion, manowar, mike, rider, sem, vseleznv, zerg |
Version: | unstable | ||
Hardware: | all | ||
OS: | Linux | ||
URL: | http://git.altlinux.org/people/boyarsh/packages/mkimage.git?p=mkimage.git;a=commitdiff;h=d18a6f5d73829a051976a8e88848af675333162b |
Description
Michael Shigorin
2015-03-04 23:44:23 MSK
Потенциальное решение: http://git.altlinux.org/people/manowar/packages/mkimage-profiles.git?p=mkimage-profiles.git;a=commitdiff;h=d2f8dcc56c5c025e885940b5e9c0982db368033a . Правда, писалось чуть для другого. И снова: http://git.altlinux.org/people/manowar/packages/mkimage-profiles.git?p=mkimage-profiles.git;a=commitdiff;h=326ff794049244150b346e260d21ac126bb17e1a . (больше, наверное, не буду делать push --force) В случае regular-mate-20180214 напоролись на такую штуку: среди переданных на сборку списков есть включающий mate-full файл-список tagged/desktop+mate; mate-full R: mate-default, который ранее требовал firefox, а недавно стал требовать webclient; в итоге где-то мы слишком рано/изолированно раскрыли список и получили rekonq вдобавок к позже приехавшему в списке просто имён пакетов firefox. Чтение mki-image-pkgs -> mki-expand-pkgs -> mki-sh-functions::mki_list_pkgs() мне пока не дало ответа на то, где же такое могло произойти -- mki-expand-pkgs ведь не дёргает резолвер apt, а оперирует максимум кэшем, применяя регэксы самостоятельно. 2 legion: Лёш, не подскажешь, куда копать? Маленький тестовый пример, наверное, могу изобразить. 2 manowar: спасибо; предсказуемый побочный эффект -- изменение настроек apt для формируемого корня (может быть существенно для ve/vm и устанавливаемых livecd). (In reply to comment #4) > В случае regular-mate-20180214 напоролись на такую штуку: Оказалось это фича apt'а -- сносим всё и делаем по-новой: # apt-get install xsane firefox ... будут установлены: firefox rekonq xsane Не, лучше не так, а эдак: # apt-get install firefox xsane ... будут установлены: firefox xsane Т.е. от перемены мест слагаемых в образ может затянуться куча всего, ага. Решение с приоритетами, предложенное выше manowar@, дистрибутивно правильное, тем более, что файлик там патчится во временном APT-боксе, в образ это не приезжает (см. #3). Можно ли и (стоит ли) делать подобное средствами mkimage? Можно, поправив алгоритм построения финального списка. Но суть останется, так что ничего лучше тут, наверное, не придумаешь. И ещё: # echo " firefox" >> /etc/apt/pkgpriorites # apt-get install xsane firefox ... будут установлены: firefox xsane Теперь от места слагаемого, предоставляющего webclient, ничего не зависит! (В ответ на комментарий №4) > Чтение mki-image-pkgs -> mki-expand-pkgs -> mki-sh-functions::mki_list_pkgs() > мне пока не дало ответа на то, где же такое могло произойти -- mki-expand-pkgs > ведь не дёргает резолвер apt, а оперирует максимум кэшем, применяя регэксы > самостоятельно. > > 2 legion: Лёш, не подскажешь, куда копать? > Маленький тестовый пример, наверное, могу изобразить. Если буде тестовый пример (я смогу запустить его на varmor), то обязательно посмотрю. Я смогу сказать более предметно, когда пройму в чём проблема. Миш, ты можешь более подробно описать проблему ? (В ответ на комментарий №6) > И ещё: > > # echo " firefox" >> /etc/apt/pkgpriorites > # apt-get install xsane firefox > ... будут установлены: > firefox xsane > > Теперь от места слагаемого, предоставляющего webclient, ничего не зависит! Я конечно не вник в проблему, но подход мне нравится на первый взгляд :) (В ответ на комментарий №7) > (В ответ на комментарий №4) > Если буде тестовый пример (я смогу запустить его на varmor), то обязательно > посмотрю. Я смогу сказать более предметно, когда пройму в чём проблема. > > (В ответ на комментарий №6) > Я конечно не вник в проблему, но подход мне нравится на первый взгляд :) Написал более подробно в devel@: https://lists.altlinux.org/pipermail/devel/2018-February/203947.html Алексей, касательно правки mkimage. Считаю, что если никто не будет править apt, то обязательно надо поменять в mkimage везде, где идут "|xargs -r" при формировании окончательного списка пакетов на что-то типа "|sort -u |xargs -r". И дальше начинать уворачиваться от шишек, которые полезут из m-p из-за РАЗОВОЙ смены очерёдности перечисления пакетов. Зато потом у нас таких проблем с порядком их следования больше возникать не будет. Это кажется, что не будет возникать. А на самом деле всё у всех взорвётся. На самом деле, конечно, можно попробовать сделать pkgpriorites частью профиля. В этом случае действительно проблемы можно будет обходить с помощью него. Но ещё более правильную идею носит Глеб - отказаться от виртуальных пакетов. Можно начать этот процесс. (В ответ на комментарий №10) > На самом деле, конечно, можно попробовать сделать pkgpriorites частью профиля. > В этом случае действительно проблемы можно будет обходить с помощью него. Для этого предложенное manowar@ хорошо бы сделать чуть более радикальным: перед удалением APT-бокса, pkgpriorites из него нужно копировать в целевой чрут. > Это кажется, что не будет возникать. А на самом деле всё у всех взорвётся. Добавление сортировки финального списка перед передачей его APT'у предложено для решения совсем другой задачи и по случаю обнаруженной такой его особенности. sort -u улучшит предсказуемость (воспроизводимость) сборки куда более динамично меняющегося m-p. Я согласен с предложением Леонида. Сортированный список даст предсказуемость обработки списка пакетов. Кроме того, если это добавлять, то я добавлю переменную чтобы вернуть старое поведение и тогда особо сложные профили можно будет не менять, добавив его. У нас уже есть GLOBAL_HSH_APT_CONFIG и HSH_APT_CONFIG, но я не помню покрывают ли случай, который нам нужен и достаточно ли их или нужно ещё что-то. Кажется его должно быть достаточно, чтобы на каждой стадии определить свой pkgpriorities и preferences (если нужно). (In reply to comment #12) > У нас уже есть GLOBAL_HSH_APT_CONFIG и HSH_APT_CONFIG, но я не помню покрывают > ли случай, который нам нужен и достаточно ли их или нужно ещё что-то. Я бы ещё обратил внимание на скрипт mkaptbox из пакета hasher (строки 246-290), где _создаётся_ APT-боксовый apt.conf. Возможно, воспроизводимость была потому, что мы традиционно в последние годы использовали одинаковый pkgpriorities. Но, если этот файл будет отличаться от машины к машине, такой воспроизводимости из-за виртуальных пакетов может не стать. Это тоже придётся учесть, добавив хотя бы в часть "create initial apt.conf" нечто "стандартное" из apt-conf-sisyphus. Хотя, возможно, для базовой системы это не критично, но для образов, собираемых mki, будет критично. Миш, ping (В ответ на комментарий №12) > У нас уже есть GLOBAL_HSH_APT_CONFIG и HSH_APT_CONFIG, но я не помню покрывают > ли случай, который нам нужен и достаточно ли их или нужно ещё что-то. Кажется > его должно быть достаточноо Да. Он же позволяет полностью изменить конфигурацию apt вплоть до RPM::Ignore в /etc/apt/apt.conf . (В ответ на комментарий №3) > И снова: Спасибо, принял в mkimage-profiles 1.2.14 наконец. (В ответ на комментарий №12) > Я согласен с предложением Леонида. Сортированный список даст предсказуемость > обработки списка пакетов. Кроме того, если это добавлять, то я добавлю > переменную чтобы вернуть старое поведение и тогда особо сложные профили можно > будет не менять, добавив его. Сортировка уже в релизе: http://git.altlinux.org/gears/m/mkimage.git?p=mkimage.git;a=commitdiff;h=a8f0974e9d191970f714f75eb5ca9705f7c8f3d8 Что ещё нужно в рамках этой баги ? Думаю, на сейчас достаточно, а любое дальнейшее стоит описывать отдельно. Спасибо всем причастным! --- tools/mki-copy-pkgs - if ! conflicts="$(LANG=C fgrep ': Conflicts: ' "$errfile")"; then + if ! conflicts="$(LANG=C egrep ': (Conflicts|Depends): ' "$errfile")"; then --- http://git.altlinux.org/people/boyarsh/packages/mkimage.git?p=mkimage.git;a=commitdiff;h=d18a6f5d73829a051976a8e88848af675333162b (В ответ на комментарий №18) > Что ещё нужно в рамках этой баги ? Отключить сортировку по умолчанию. |