[devel] ***UNCHECKED*** Re: пакеты из тарбола легко и удобно собираются в git

[Vitaly Lipatov]

Andrey Savchenko писал 10.11.20 17:27:
> On Tue, 10 Nov 2020 16:01:33 +0300 Sergey V Turchin wrote:
>> On Tuesday, 10 November 2020 15:41:55 MSK Vitaly Lipatov wrote:
>> 
>> [...]
>> > Так же хочу напомнить, что ассоциация сборки из тарбола со сборкой из
>> > srpm является ложной: пакеты из тарбола легко и удобно собираются в git.
>> Да я вообще сборку всего Qt5/KDE5 перевёл с "git в git" на "из тарбола 
>> в git",
>> т.к. мне стало так удобнее.
> 
> Это удобнее пока отладку делать не нужно, а как возникает серьёзная
> проблема и нужен git bisect, то внезапно оказывается, что идея
> с тарболами не такая уж и хорошая.
Вы правы, но
1) bisect по релизам позволит собирать гарантированно собиравшиеся 
версии.
2) если речь о бисекте в апстриме (какой коммит сломал что-то к новой 
версии) — это легко делается в отдельном git-репозитории, 
синхронизированном с апстримом.
3) у нас задача — собирать пакеты, а не вести разработку, то есть 
приоритетно удобство сборки

Немного про исключения:
Идея делать бисект в репозитории, в котором только релизные коммиты, не 
очень хороша, потому что нужно смотреть на HEAD. А если обновлять 
upstream до HEAD, так не всё ли равно, в каком каталоге это делать, 
можно и в отдельном.

Безусловно, если вы активно разрабатываете, бисектите, то есть вся 
разработка (или багфикс апстрима) у вас в этом репозитории, то никто же 
не запрещает вести такой репозиторий.
НО не нужно ради гипотетической возможности отлаживать то, что никто 
отлаживать не будет, вести всё в таком виде.

Говоря короче, внесение апстримной разработки в процесс сборки пакета 
— это скорее исключение, чем правило. Особенно для тысяч пакетов, 
собираемых из репозиториев npmjs, pypi, java, gems и т.п.

Возможно, у нас просто разные подопытные.

-- 
С уважением,
Виталий Липатов,
ALT Linux Team