amarao (amarao_san) wrote,
amarao
amarao_san

Category:

gbp & upstream in remote branch

Оно сработало просто идеально - апдейт пакета с 1.0.0 до 1.9.0 произошёл буквально в две минуты.

По размышлению, я понял, что это идеальный метод держать для данного софта:

а) Несколько апстримов - апстрим-апстрим и локальный, с собственными модификациями
б) Несколько веток debian'а, у каждой своя история.

Вся особенность - в указании правильных бранчей в gbp.conf'е, а так как все эти ветки хранятся в одном гите, мы полностью освобождаемся от магических артефактов в форме "tgz из апстрима" и переходим к чистому миру гита.

Даже pq (patch queue) в этой ситуации становится излишним. Если мы что-то хотим пофиксить, мы просто чекаутим апстрим в отдельный бранч, фиксим что нужно, после чего указываем этот бранч как апстрим для нашего "патченного" пакета. Ребейз патчей относительно изменяющегося апстрима решается просто - мы просто cherry-pick'аем изменения по мере надобности. Хотя насчёт правильности этого подхода я не уверен, и, возможно, классическая pq будет лучше. Но в любом случае, саму pq лёгко изготовить из форкнутого бранча, и все изменения хорошо версионированы.

Более того, если мы мейнтейним старую версию в которую хотим притащить фиксы из более новой версии апстрима, то мы легко можем выковырять патчи из апстрима - они все, тут, готовенькие.

Требования простые:

Апстрим в гите
Версии по тегам

Если это есть - git-with-remote-upstream workflow работает на ура.
Tags: devops
Subscribe

  • to_learn

    cobbler/koan

  • to_learn

    Очередная аббревиатура: linux-vdso.so

  • to learn

    Сесть и изучить минимум 10 клавиатурных комбинаций для nano.

  • Post a new comment

    Error

    default userpic

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 0 comments