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

[Andrey Savchenko <bircoph@altlinux.org>]

[-- Attachment #1: Type: text/plain, Size: 5243 bytes --]

On Tue, 10 Nov 2020 18:19:09 +0300 Vitaly Lipatov wrote:
> 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 по релизам позволит собирать гарантированно собиравшиеся 
> версии.

Ошибка может быть не только в том, что не собирается, а и в том,
что не работает или работает не так как нужно. Вот пожаловался
пользователь: такая-то проблема возникла, а когда-то давно работало.
Без git bisect по полному дереву можно или пойти за верёвкой
и мылом, или послать пользователя. Оба варианта мне не нравятся.

> 2) если речь о бисекте в апстриме (какой коммит сломал что-то к новой 
> версии) — это легко делается в отдельном git-репозитории, 
> синхронизированном с апстримом.

А если в Альте накладываются патчи и бисектить нужно всё сразу,
т.к. не очевидно, кто виноват, а методом тыка поиск займёт
неприемлемое время? Собственно говоря, я не просто так пишу: у меня
подобные случаи регулярно возникают.

> 3) у нас задача — собирать пакеты, а не вести разработку, то есть 
> приоритетно удобство сборки

Уточняйте, пожалуйста, у кого — у вас. Потому что я вижу разработку
— хотя бы на уровне написания или переноса патчей — как неотъемлемую
часть сопровождения существенной доли сложных пакетов.

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

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

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

Мне подобные семейства пакетов представляются важным, но
специфическим частным случаем. Конечно, для них нужны свои средства
автоматизации. Однако, даже там не всё так просто, например, numpy
требует серьёзных патчей на новых архитектурах.

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

Да, думаю, что в этом дело. 

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]