60117 2026-08-07 11:34:10 +0300 rpmgs: merge -s ours отбрасывал содержимое апстрима (3.3.1–3.3.2), отравлена история gear-репозиториев 2026-08-07 11:34:10 +0300 1 1 4 Development Sisyphus etersoft-build-utils unstable x86_64 Linux NEW P5 normal --- 1 chal55rus lav lav sin qa-sisyphus oldest_to_newest 292404 0 chal55rus 2026-08-07 11:34:10 +0300 В etersoft-build-utils 3.3.1-alt1 (коммит d223e6c от 07.02.2026, «rpmgs: use 'ours' merge strategy for .gear/tags-based packages») в rpmgs, функция update_master_branch_to(), для репозиториев с каталогом .gear/tags обычный мердж апстримного тега был заменён на `git merge -s ours $tag`. В 3.3.3-alt1 (коммит bd83b59 от 29.06.2026) стратегия убрана. Проблема в долгоживущих последствиях, которые остались и после исправления: 1. `merge -s ours` создаёт мердж-коммит, дерево которого идентично ветке мейнтейнера — содержимое апстрима отбрасывается, но апстримные коммиты становятся предками ветки и считаются git «уже смерженными» навсегда. 2. После возврата к обычному мерджу (3.3.3+) git вычисляет дельту от merge-base, в который эти теги уже входят, и применяет только инкремент между последними тегами. Все изменения апстрима за период до ours-мерджей в дерево ветки не попадают никогда — молча, без конфликтов и предупреждений. 3. В результате дерево ветки — несогласованная смесь старой базы и свежих дельт. Пример: в python3-module-pykickstart после обновлений 3.74→3.77 код из r3.77 импортирует символ F45, добавленный в version.py ещё в r3.74 и отброшенный ours-мерджем: checkout ветки нерабочий (ImportError, тесты падают). Сами пакеты при этом собираются корректно, т.к. тарболл в .gear/rules берётся из апстримного тега (tar: r@version@:.), и проблема незаметна при сборке. 4. Репозитории, где тарболл собирается из дерева ветки (tar: . и т.п.), в период с 28.03.2026 по 01.07.2026 могли выпустить пакеты со старым кодом под новой версией — это стоит проверить отдельно. Детектор поражённых репозиториев (пустой ours-мердж: дерево результата совпадает с первым родителем, хотя второй родитель отличался): for m in $(git log --merges --format=%H); do git diff --quiet $m^1 $m && ! git diff --quiet $m^1 $m^2 && \ git log -1 --format='%h %ad %s' --date=short $m done Починка поражённого репозитория (переписывание истории не требуется): одним коммитом привести дерево к содержимому последнего апстримного тега: git read-tree --reset -u <апстримный_тег> git checkout HEAD -- .gear git commit -m "Restore tree content from upstream tag (ours-merge skew fix)" У себя обнаружил 23 поражённых репозитория из 73 (ours-мерджи в период 18.05–30.06.2026). Вероятно, проблема затронула и других мейнтейнеров, пользовавшихся rpmgs 3.3.1–3.3.2 с git-merge-стилем обновления. Предложения: - анонсировать в devel@lists.altlinux.org, чтобы мейнтейнеры проверили свои репозитории детектором выше; - рассмотреть добавление в rpmgs защиты: предупреждение, если мердж апстримного тега не изменил дерево (git diff --quiet HEAD^1 HEAD после мерджа) — на случай подобных регрессий в будущем.