[devel] Еще одно HOWTO про сборку пакета в git.alt и интеграцию с upstream scm

Aleksey Avdeev =?iso-8859-1?q?solo_=CE=C1_solin=2Espb=2Eru?=
Ср Апр 11 11:46:34 MSD 2007


Eugene Prokopiev пишет:
>>>>  Мне удобнее держать полученное из старонних источников отдельно, с
>>>> мимниумом изменений: продукты полученные от поставщика могут требовать
>>>> предварительной обработки (мытья, например) и до её проведения --
>>>> незачем их мешать их с остальными инградиентами (на своей кухне я хозяин
>>>> -- смешаю как сочту нужным ;-)).
>>> Это верно, однако разделение можно понимать по разному ;) Разные бранчи 
>>> требуют регулярного слияния, если же просто вынести исходники апстрима в 
>>> отдельный каталог, то получим и разделение (пока для меня в принципе 
>>> достаточное), и уменьшение количества операций.
>>
>>   Деление -- получаем. Но выцепить изменения сделанные в исходниках уже
>> сложнее...
> 
> Кажется, выше я писал, каким образом я выцепляю изменения:
> 
>> Патчи, если таковые имеются, можно держать в отдельных файлах, как и 
>> раньше. Если эти патчи мои, то делаю я их старым проверенным способом: 
>> собираю апстримные исходники и тестирую разультат где-то отдельно 
>> (иногда в системе, в которой не жалко сделать make install  ;)  ), 
>> изменяемые файлы перед изменением обзываю .orig, после изменений делаю 
>> gendiff. Даст ли мне ощутимые преимущества какой-нибудь более правильный 
>> способ с отдельным бранчем под каждый патч?
> 
> Если вы делаете иначе, пожалуйста, расскажите как (по возможности 
> подробно, с командами). Особенно интересуют преимущества по сравнению с 
> приведенным выше способом.

  Патчи, к которым я приложил руку после перехода на git, в виде файлов
я не храню (только унаследываемые). Для из поучения -- использую diff
между тегами, благо gear это позволяет. (Пока непозволял -- использовал
самописанный велосипед для автоматизированного создания патчей на базе
заданных коммитов.)

  Поскольку, для работы с данной схемой всё равно нужны фиктивные мержи
и gear-upate-tag, у меня нет усложнения техпроцесса при хранении
исходников в отдельном банче. Это, в свою очередь, позволяет
небеспокоется о имени каталога, куда апстрим пакует исходники (если они
распространяются в тарбл, то версия часто присутствует в имени
каталога): достаточно соглашения, что всё находящееся в корне бранча с
сорцами -- сорцы, полученные из внешнего источника (возможно --
правленные, но в данном контексте это не важно).

> 
>>> Вот правда вынести исходники апстрима в отдельный каталогу меня не 
>>> выходит :(
>>
>>   Я незнаю приемлимово, без большого дифа, решения. (Понятно, что в
>> данном случаи, этот большой diff несоздаёт кучи новых объектов
>> хранения... Но что-то меня сдесь настораживает.)
> 
> Что-то я потерял нить ... О каком дифе идет речь и как это связано с 
> хранением исходников в отдельном каталоге вместо отдельного бранча?

  О diff между соседними коммитами, при перемеи сорцов в другой каталог.

-- 

С уважением. Алексей.


----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : signature.asc
Тип     : application/pgp-signature
Размер  : 481 байтов
Описание: OpenPGP digital signature
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20070411/ebc5d9d3/attachment-0001.bin>


Подробная информация о списке рассылки Devel