30806 2015-03-04 23:44:23 +0300 [FR] ручка для регулировки поведения при раскрытии списков пакетов 2019-11-08 17:07:30 +0300 1 1 4 Development Sisyphus mkimage unstable all Linux CLOSED FIXED http://git.altlinux.org/people/boyarsh/packages/mkimage.git?p=mkimage.git;a=commitdiff;h=d18a6f5d73829a051976a8e88848af675333162b P3 enhancement --- 1 mike mike antohami boyarsh cas glebfm klark.devel legion manowar mike rider sem vseleznv zerg qa-sisyphus oldest_to_newest 150586 0 mike 2015-03-04 23:44:23 +0300 Начиная с http://git.altlinux.org/gears/m/mkimage.git?p=mkimage.git;a=commitdiff;h=bfaa201fc7c7536d5f48dfb0c7bd7cbcaa2898f8 (входит в 0.0.6 и далее), mkimage умеет укладывать в субпрофиль конфликтующие пакеты; насколько помню, сделано было для возможности положить несколько MTA в RPMS.disk. На типичных субпрофилях, где пакеты не копируются, а устанавливаются, такая смена поведения приводит к возможности конфликтов уже при установке; проще всего пронаблюдать подобное, когда используются и IMAGE_PACKAGES, и IMAGE_PACKAGES_REGEXP, причём в IMAGE_PACKAGES что-либо вытягивает виртуальную зависимость (и происходит разрешение её в конкретный вариант), а в IMAGE_PACKAGES_REGEXP задаётся другой вариант, предоставляющий ту же зависимость. Эту багу давно следовало вынести из тудушки и сформулировать хотя бы так, на этот раз поймал bug 30805 и решил всё-таки зафиксировать. Пока непонятно, как может выглядеть интерфейс, меняющий поведение. Возможно, в нулевом приближении следует изменить tools/mki-image-pkgs и tools/mki-expand-pkgs таким образом, чтобы для copy резолвить по отдельности, для install -- одной транзакцией. 168869 1 manowar 2018-02-07 23:57:29 +0300 Потенциальное решение: http://git.altlinux.org/people/manowar/packages/mkimage-profiles.git?p=mkimage-profiles.git;a=commitdiff;h=d2f8dcc56c5c025e885940b5e9c0982db368033a . Правда, писалось чуть для другого. 168873 2 manowar 2018-02-08 01:55:31 +0300 Точнее, уже http://git.altlinux.org/people/manowar/packages/mkimage-profiles.git?p=mkimage-profiles.git;a=commitdiff;h=af945eec21304d4523018b1e3c0de6c1c07ad0d0 . 168895 3 manowar 2018-02-09 01:55:45 +0300 И снова: http://git.altlinux.org/people/manowar/packages/mkimage-profiles.git?p=mkimage-profiles.git;a=commitdiff;h=326ff794049244150b346e260d21ac126bb17e1a . (больше, наверное, не буду делать push --force) 169163 4 mike 2018-02-20 19:16:05 +0300 В случае 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). 169164 5 klark.devel 2018-02-20 22:31:10 +0300 (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? Можно, поправив алгоритм построения финального списка. Но суть останется, так что ничего лучше тут, наверное, не придумаешь. 169165 6 klark.devel 2018-02-20 22:38:51 +0300 И ещё: # echo " firefox" >> /etc/apt/pkgpriorites # apt-get install xsane firefox ... будут установлены: firefox xsane Теперь от места слагаемого, предоставляющего webclient, ничего не зависит! 169172 7 legion 2018-02-21 01:49:16 +0300 (В ответ на комментарий №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, ничего не зависит! Я конечно не вник в проблему, но подход мне нравится на первый взгляд :) 169173 8 klark.devel 2018-02-21 03:10:01 +0300 (В ответ на комментарий №7) > (В ответ на комментарий №4) > Если буде тестовый пример (я смогу запустить его на varmor), то обязательно > посмотрю. Я смогу сказать более предметно, когда пройму в чём проблема. > > (В ответ на комментарий №6) > Я конечно не вник в проблему, но подход мне нравится на первый взгляд :) Написал более подробно в devel@: https://lists.altlinux.org/pipermail/devel/2018-February/203947.html 169175 9 klark.devel 2018-02-21 03:26:06 +0300 Алексей, касательно правки mkimage. Считаю, что если никто не будет править apt, то обязательно надо поменять в mkimage везде, где идут "|xargs -r" при формировании окончательного списка пакетов на что-то типа "|sort -u |xargs -r". И дальше начинать уворачиваться от шишек, которые полезут из m-p из-за РАЗОВОЙ смены очерёдности перечисления пакетов. Зато потом у нас таких проблем с порядком их следования больше возникать не будет. 169176 10 rider 2018-02-21 08:59:08 +0300 Это кажется, что не будет возникать. А на самом деле всё у всех взорвётся. На самом деле, конечно, можно попробовать сделать pkgpriorites частью профиля. В этом случае действительно проблемы можно будет обходить с помощью него. Но ещё более правильную идею носит Глеб - отказаться от виртуальных пакетов. Можно начать этот процесс. 169179 11 klark.devel 2018-02-21 10:16:36 +0300 (В ответ на комментарий №10) > На самом деле, конечно, можно попробовать сделать pkgpriorites частью профиля. > В этом случае действительно проблемы можно будет обходить с помощью него. Для этого предложенное manowar@ хорошо бы сделать чуть более радикальным: перед удалением APT-бокса, pkgpriorites из него нужно копировать в целевой чрут. > Это кажется, что не будет возникать. А на самом деле всё у всех взорвётся. Добавление сортировки финального списка перед передачей его APT'у предложено для решения совсем другой задачи и по случаю обнаруженной такой его особенности. sort -u улучшит предсказуемость (воспроизводимость) сборки куда более динамично меняющегося m-p. 169183 12 legion 2018-02-21 11:26:06 +0300 Я согласен с предложением Леонида. Сортированный список даст предсказуемость обработки списка пакетов. Кроме того, если это добавлять, то я добавлю переменную чтобы вернуть старое поведение и тогда особо сложные профили можно будет не менять, добавив его. У нас уже есть GLOBAL_HSH_APT_CONFIG и HSH_APT_CONFIG, но я не помню покрывают ли случай, который нам нужен и достаточно ли их или нужно ещё что-то. Кажется его должно быть достаточно, чтобы на каждой стадии определить свой pkgpriorities и preferences (если нужно). 169187 13 klark.devel 2018-02-21 12:26:36 +0300 (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, будет критично. 169795 14 legion 2018-03-21 19:10:02 +0300 Миш, ping 169813 15 zerg 2018-03-22 09:34:37 +0300 (В ответ на комментарий №12) > У нас уже есть GLOBAL_HSH_APT_CONFIG и HSH_APT_CONFIG, но я не помню покрывают > ли случай, который нам нужен и достаточно ли их или нужно ещё что-то. Кажется > его должно быть достаточноо Да. Он же позволяет полностью изменить конфигурацию apt вплоть до RPM::Ignore в /etc/apt/apt.conf . 171283 16 mike 2018-05-24 17:47:59 +0300 (В ответ на комментарий №3) > И снова: Спасибо, принял в mkimage-profiles 1.2.14 наконец. 174284 17 legion 2018-09-19 13:38:29 +0300 (В ответ на комментарий №12) > Я согласен с предложением Леонида. Сортированный список даст предсказуемость > обработки списка пакетов. Кроме того, если это добавлять, то я добавлю > переменную чтобы вернуть старое поведение и тогда особо сложные профили можно > будет не менять, добавив его. Сортировка уже в релизе: http://git.altlinux.org/gears/m/mkimage.git?p=mkimage.git;a=commitdiff;h=a8f0974e9d191970f714f75eb5ca9705f7c8f3d8 174285 18 legion 2018-09-19 13:39:20 +0300 Что ещё нужно в рамках этой баги ? 177518 19 mike 2019-01-17 19:04:52 +0300 Думаю, на сейчас достаточно, а любое дальнейшее стоит описывать отдельно. Спасибо всем причастным! 182412 20 mike 2019-06-14 13:30:44 +0300 --- 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 185454 21 zerg 2019-11-08 17:07:30 +0300 (В ответ на комментарий №18) > Что ещё нужно в рамках этой баги ? Отключить сортировку по умолчанию.