[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