При мерже eterwine в eterhack возникает проблема при обновлении версии Wine. Для корректного обновления требуется: 1) Выставить корректную версию в файле VERSION 2) выполнить autoconf -f 3) исправить *.spec. Изменить в нём текущую версию и добавить changelog.
> 2) выполнить autoconf -f Я бы предложил такую последовательность: tools/make_requests autoheader autoconf
> tools/make_requests Но с этой штукой есть одна сложность. Она вроде бы всегда обновляет версию в include/wine/server_protocol.h, даже если ничего не изменилось. Поэтому в идеале было бы неплохо если поменялась только версия, то откатывать это изменение назад.
(В ответ на comment #2) > > tools/make_requests > Но с этой штукой есть одна сложность. Она вроде бы всегда обновляет версию в > include/wine/server_protocol.h, даже если ничего не изменилось. Поэтому в > идеале было бы неплохо если поменялась только версия, то откатывать это > изменение назад. Можно добавить отдельное правило для разрешения конфликта в include/wine/server_protocol.h. Т.е если есть конфликт в этом файле, то вызывать tools/make_requests. Причём, если я правильно понимаю, делать это нужно в самом конце, когда уже разрешены конфликты в остальных файлах.
Да, лучше вызывать после правки всего, что не генерируется автоматически. Тут ещё о таком моменте я что-то сразу не подумал: если будут конфликты в include/wine/server_protocol.h, то скорее всего будут и конфликты в server/protocol.def, т.е., видимо, надо либо научиться автоматически править конфликты в protocol.def, либо тогда нет особого смысла запускать tools/make_requests.
(В ответ на comment #4) > Да, лучше вызывать после правки всего, что не генерируется автоматически. Тут > ещё о таком моменте я что-то сразу не подумал: если будут конфликты в > include/wine/server_protocol.h, то скорее всего будут и конфликты в > server/protocol.def, т.е., видимо, надо либо научиться автоматически править > конфликты в protocol.def, либо тогда нет особого смысла запускать > tools/make_requests. Я часто встречал, что конфликты только в include/wine/server_protocol.h. Притом конфликты связано только со строкой версии. И чтобы при этом были конфликты в server/protocol.def - такое бывает очень редко
> Я часто встречал, что конфликты только в include/wine/server_protocol.h. Притом > конфликты связано только со строкой версии. > И чтобы при этом были конфликты в server/protocol.def - такое бывает очень > редко Не знаю, подойдёт ли в таком случае tools/make_requests. Она версию просто на единицу увеличивает. А если в этой строке конфликт, то не знаю, как она себя поведёт. Тут лучше проверить.
(В ответ на comment #6) > Не знаю, подойдёт ли в таком случае tools/make_requests. Она версию просто на > единицу увеличивает. А если в этой строке конфликт, то не знаю, как она себя > поведёт. Тут лучше проверить. Создал отдельную багу #7539.
(В ответ на comment #1) > > 2) выполнить autoconf -f > Я бы предложил такую последовательность: > tools/make_requests > autoheader > autoconf Только вот не совсем понимаю зачем вызывать autoheader?
> Только вот не совсем понимаю зачем вызывать autoheader? Оно обновляет include/config.h.in при изменении configure.ac
Сделал отдельный метод resolve_conflict_in() для разрешения конфликтов в специальных файлах. В классе git_repository этот метод разрешает конфликты никак не связаннаые с wine. Например в configure. В классе wine_repository метод разрешает конфликты связанные с wine
Реализовал исправления конфликта в файле 'VERSION' По счастливой случайности он оказался раньше, чем 'configure' (надеюсь так будет каждый раз', поэтому конфликт в configure затем сам исправится. Ещё нужно разобраться со spec-файлами, и изменять версию там.
(В ответ на comment #11) > Ещё нужно разобраться со spec-файлами, и изменять версию там. Реализовал обновление полей Version и Reliase в спеке. Осталось добавить Changelog
(В ответ на comment #12) > Осталось добавить Changelog Changelog добавляется. Осталось только всё проверить на реальном репозитории.
Проверил. Изменил конфигурацию для builder-robot. Всё работает!
