[devel] Обновление redis в p8

[mikhailnov на altlinux.org]

26.11.2019 04:22, mikhailnov на altlinux.org пишет:
> 26.11.2019 01:32, Leonid Krivoshein пишет:
>> Всем привет!
>>
>>
>> Извиняюсь за нюбовский вопрос. Каковы действия при бэкпортировании в p8?
>> Собрал тестовое задание #241616. Достаточно проверить с такими 
>> зависимостями:
>>
>> $ apt-cache whatdepends redis
>> redis-3.0.7-alt1 на 1454758009
>>   python-module-docker-registry-0.6.1-alt1 на 1382307574
>>     Требует: redis
>>
>> Просто, боюсь, с этой штукой на самом деле много чего может отъехать.
>> Но без тестовой пересборки не представляю, как это определить.
>> Просили закрыть CVE в баге #37533, а бранч "стабильный".
>>
>>
> См. https://security-tracker.debian.org/tracker/CVE-2019-10193 и 
> https://security-tracker.debian.org/tracker/CVE-2019-10192
>
> Их исправления бекпортировали в 3.2.13, которая гораздо ближе к 3.0.7 
> в p8, чем 5.0 из сизифа. Наверняка соответствующие коммиты без правок 
> или с минимальным редиффом лягут на 3.0.7 патчами.
>
>
> https://raw.githubusercontent.com/antirez/redis/3.2/00-RELEASENOTES
> ================================================================================ 
>
> Redis 3.2.13     Released Mon Mar 18 17:24:10 CEST 2019
> ================================================================================ 
>
>
> Ciritcal fixes backported from Redis 5.

Когда нужно бекпортировать что-то, я обычно делаю так:

git clone апстримные_исходники
git tag | grep версия
git checkout tags/<найденный_тег_с_целевой_версией_для_бекпорта>
git checkout -b patched-<версия>
git cherry-pick <хеш коммита для бекпортирования>

Если лег сразу, то отлично, иначе в git status смотрю, где возникли 
проблемы, правлю их (они помечаются ====== в текстовых файлах), затем:
git commit -a
Открывается редактирование описания коммита. Туда дописываю что-то вроде:
Backport of upstream commit <hash> to systemd-230
и при необходимости описание изменений относительно оригинального 
коммита, например, "dropped tests".

Затем делаю git format-patch -1 -s
-s - чтобы в патч с Author != я была добавлена пометка о моем участии, 
чтобы другим людям было понятнее, откуда такой патч взялся.

В крупных проектах типа systemd иногда приходится бекпортировать 
несколько десятков коммитов для закрытия одной CVE, такие действия 
чреваты тем, что всплывут какие-нибудь косяки: опечатки при 
бекпортировании, нарушение логики работы, если бекпортирование остановил 
на таком состоянии, которое было затем изменено в апстриме, т.к. было 
багованным, и т.д. В таких случаях обычно цепочка коммитов получается 
задом на перед, т.к. после каждого бекпорта проверяется сборка (а в 
Альте и в etersoft-build-utils, кстати, есть готовые интеграции rpm с 
ccache), если коммитов оказалось недостаточно, то бекпортируется следующий.

В случае с redis посмотрите, насколкьо большие правки были, может, там 
проще просто обновить с 3.х до 3.2 и не мучаться, а, может, можно 
несколько маленьких коммитов приложить, и всё.