On Fri, Jul 06, 2007 at 11:15:02AM +0400, Dmitry V. Levin wrote:
> Это зависит.  Если у пакета upstream в git'е, и бранч, из которого ведётся
> сборка пакета, основан не на релизах а на upstream'ном git'е, то я вижу
> больше смысла пакетовать в srpm этот самый %name-%version-%release.tar,
> нежели %name-%version.tar (который имеет все шансы отличаться от
> релизного по составу файлов) с кумулятивным патчем.

Простой патч "не держит" как следует переименование файлов.
У меня есть пакет напр. perl-DBI, в котором я переименовал
Changes -> lib/DBI/Changes.pod.  Патч будет большим и ценность
такого патча будет низкой.

> Не вижу в этом проблемы.  У меня есть такой забавный пакетик faketime.
> В нём кода на несколько килобайт, но он использует gnulib на несколько
> мегабайт.  Я поместил gnulib на другой бранч (у gnulib'а upstream'ный
> исходный код в git'е), поставил тэг, который время от времени передвигаю.

И что, ты делаешь фиктивный merge бранча gnulib, который не добавляет
файлов в основное дерево, только для того, чтобы получить общего предка,
чтобы создавался тарболл gnulib в .gear-rules?  "Это какой-то позор." :)

> > В общем, кумулятивный патч из gear-tags более-менее подходит только
> > тогда, когда сборки строго отсчитываются от официальных релизов.
> 
> У меня другое мнение.  Если сборки отсчитываются от upstream'а в
> каком-нибудь виде, в т.ч. снапшотов, то можно сделать кумулятивный патч.
> Можно даже сделать 2 кумулятивных патча: от последнего релиза до
> последнего снапшота, и от последнего снапшота HEAD.

В случае с перлом очень большой апстримный патч будет от последнего
релиза.

$ git-describe 5.8
5.8.8-702-gb49e4f0
$ git-diff 5.8.8..5.8 |wc -c
12912147
$

Такой патч ничего никому не даст, отключить его (и откатиться на 5.8.8)
всё равно нельзя.

> > Кроме того, кумулятивный патч не слишком-то решает проблемы.  Во-первых,
> > он всё же не слишком хорошо удовлетворяет GPL 2a.
> Почему?

Строго говоря, GPL 2a требует вносить изменения в сами файлы при каждом
измнении кода (т.е. указывать автора+дату+краткое описание).  Т.е. типа
cvs $Log$.  Это никогда не делалось, но хотя бы по названию отдельного
патча обычно можно было установить откуда он взялся и, соответственно,
кто его написал.  Если в кумулятивном патче содержатся изменения разных
авторов, то уже нельзя непосредственно установить какой кусок кем был
написан (не говоря уж о дате).

В GPLv3 это требование по форме несколько ослаблено, так что не знаю,
стоит ли считать его принципиальным.

> > Я подумал и пришел к выводу, что git не очень-то хорошо подходит для
> > поддержки нескольких "логически нарезанных" патчей.  Хранить патчи
> > отдельно в таком случае выходит проще, чем думать, как орагинзовать
> > бранчи и как их потом вливать друг в друга.
> > 
> > Проблема с git'ом вот какая.  Мы сделали измнение относительно версии1.
> > Потом мы делаем pull версии2.  merge не проходит из-за конфликта с
> > изменением.  Мы вручную правим конфликт.  Теперь информаци о том, что
> > представляет из себя изменение относительно версии2, частично потерялась
> > (оно похоронено в ручном разруливании конфликта).  То есть уже нельзя
> > логически однозначно восстановить патч для версии2.
> 
> Можно сделать rebase, заново разрулить конфликты и получить патчи,
> сделанные для новой версии, но.  Это другая модель разработки, обычно
> не очень удобная, поскольку утрачивается история.

Можно делать вот как: не допускать конфликтных мержев (если они
задеваются локальными изменениями в коде).  Если мерж оказывается
конфликтным, то нужно сначала откатить (revert) те изменения, из-за
которых получается конфликт.  Потом сделать бесконфликтный мерж.
А потом заново эти патчи накатить, уже разруливая конфликт.

При таком раскладе получается, что любое локальное изменение всегда можно
откатить, как если бы можно было отключать патчи в spec-файле.  Впрочем,
если патчи между собой конфликтуют, то отключать их в spec-файле просто
так всё равно нельзя.  В этом случае получается то же самое, только git
лучше.

В общем, git довольно дубовая система, она не решает тонких проблем,
а просто не обращает на эти проблемы внимания.  Впрочем, всё равно никто
не знает, как надо "по-хорошему" решать эти "тонкие проблемы".  Вроде в
darcs какие-то идеи на этот счет были.

> > В идеале нужна такая система, которая позволяет "логически
> > восстанавливать" патч для каждой версии, а не хоронить конфликты
> > под мёржами.
> > 
> > ПОСЛЕ КОНФЛИКТНОГО МЁРЖА ПАТЧ УЖЕ НЕЛЬЗЯ ОТКАТИТЬ РЕВЁРТОМ,
> > правильно я понимаю?
> 
> Можно, при этом, скорее всего, придётся разрулить новый конфликт.

Ну вот получается, что в ряде случаев патчи в src.rpm пакете отключать
проще, чем откатывать "старые" локальные изменения в git'е.