[devel] I: gear-tarimport

[Mikhail Yakshin]

Денис Смирнов пишет:
> MY> Посмотрел, спасибо, я раньше не знал о существовании этого пакета. Там
> MY> есть масса полезных вещей (например, gear-rel, svn-update, gi,
> MY> git-repos-cleanup, send-devel, pkg_release, sisyphus-list-incoming - они
> MY> все по образу действия по-моему достаточно близки к comfort и хотелось
> MY> бы их действительно по возможности объединить туда).
> 
> Я только за. Потому как по моему личному мнению наличие в сизифе каждого
> пакета с именем "<firmname>..." это неявная бага. Если пакет seiros-.*
> используется только у меня, то ему не место в сизифе. А если используется
> не только мной, то почему бы не объединить все подобные утилиты в один
> пакет?

Ура =) Очень близкая мысль :)

> MY> Относительно некоторых утилит - мне с первого взгляда оказалось не
> MY> очевидным, что они делают %)

> MY> ptch - для каких работ это предназначено? В git сейчас не проще просто
> MY> скоммитить все "до" и "после" и вытащить этот патч, если он нужен
> MY> файлом, просто с помощью разницы между ref'ами?
> 
> Это для старой эпохи, хотя и сейчас изредка нужно. Есть некий workdir,
> который не использует никакого SCM. Мы берем в нем и редактируем
> некоторые файлы, переименовывая оригиналы в *.orig. Потом запускаем этот
> файл, и получаем вывод по смыслу тот же что если бы мы набрали svn
> diff/git diff в workdir где они используются.
>
> Сейчас я его использую в следующем случае:
>  - rpmbb <spec>
>  - В BUILD имеем несобравшийся пакет
>  - переименовываю то что пытаюсь править в .orig и запускаю make (чтобы не
>    пересобирать весь пакет)
>  - повторяю предыдущий шаг до тех пор пока пакет не соберется
>  - ptch > 1.patch
>  - переношу этот патч в каталог с git, и либо привязываю его как новый
>    патч к пакету, либо набираю patch -p0 < 1.patch

Вот, отлично, еще одна схема workflow у нас появилась :) Как бы ее 
проапгрейдить для git'а? Например, чтобы собираемый патч автоматически 
привязывался к пакету в git'е и прописывался как "PatchX: ..." и %patch 
что-то там?

> MY> ptch_filter - один из самых интересных, по идее, скриптов - он как-то
> MY> хитро фильтрует патчи - но как - я с первого взгляда не понял.
> 
> Он глючный, поэтому и лежит в отдельном пакете :( Он мне здорово помогал
> обрабатывать результат  сравнения бранчей астериска.

Его как-то более универсально можно использовать? И - в идеале - 
учитывая то, что пакет лежит в репозитарии?

> MY> Что *именно* делают Add и Mv, кроме наиболее общих "добавляют все, что
> MY> не добавлено" и "перемещают все массово из одного места в другое" с
> MY> пустыми commit messages - я так и не понял? Update - зачем там делаются
> MY> эти хитрые chmod'ы?
> 
> Add/Mv делают именно это. Наследие тяжелого прошлого когда я хранил _все_
> свои данные в svn, естественно далеко не для всех имела смысл история с
> commit messages. Кстати Mv умеет ключик -b, когда он не пытается
> коммитить.
> 
> В случае с git эти скрипты не имеют смысла, потому как есть:
> git add (делает то же что Add)
> git mv (который точно так же как Mv прекрасно обрабатывает группы файлов,
> чего не умеет svn mv).
> 
> Их имеет смысл паковать только в том случае, если доработать до
> универсальности (работы как с svn, так и с git репозиториями). Если
> приходится работать с группой репозиториев в разных SCM, то честно говоря
> сильно достает использовать разный набор команд для простых операций.
> 
> Когда-нибудь я озверею и напишу даже скрипт Commit :)
> 
> Вообще эта группа недоскриптов если и нужна, то их следует упаковать в
> отдельный пакет. Хотя бы потому что они тянут зависимость и на git, и на
> svn. А если я чего-нибудь не того выпью, то и на cvs потянут.

Т.е. отдельный маленький проект - организация общего интерфейса ко всем 
version control системам. По-моему - нужная и полезная вещь.

> Вообще многие такие вещи имеет смысл бить на пакеты из-за очень большого
> объема requires.

Согласен. Но некий базовый workflow-пакет с разумным объемом requires 
IMHO имеет право на существование.

> MY> В перспективе - мне хотелось бы еще поговорить с lav@ насчет
> MY> etersoft-build-utils - т.к. там масса наработок по сборке пакетов и
> MY> абсолютно не хочется дублировать эту функциональность в comfort, набивая
> MY> все те же самые грабли, что уже наметили на карте добрые люди и
> MY> изобретать велосипед (особенно впечатляет там сборка из одного ALT'ового
> MY> spec в кучу дистрибутивов). В идеале - хотелось бы интегрироваться в ту
> MY> или другую сторону, т.к. я умышленно сейчас в comfort делал сборку
> MY> пакетов в очень минимальном виде, а в etersoft-build-utils нет некоего
> MY> workflow для git. Вместе получилось бы хорошо.
> 
> Думаю да. В любом случае получится один low level и стайка high level
> пакетов.

> Кстати etersoft-build-utils мы с lav@ уже давно допинали до
> работоспособности с gear. rpmbb <specname> в git repo отрабатывает именно
> так как ожидается.

Насколько я видел, когда смотрел последний раз - там просто меняется 
оборачивается использование rpmbuild или hsh в gear, если есть каталог .git.

Что бы мне лично хотелось видеть в утилите, которая собирает:

1. Возможность запуска без параметров для сборки того пакета, в 
директории с репозитарием которого я сейчас нахожусь. (Распространяется 
не только на саму директорию с .git, но и все ее поддиректории).

2. Возможность запуска, указав только имя пакета (пакет найдется в 
репозитарии $HOME/git/имя-пакета) - типа "rpmbb samba". При 
невозможности найти такой репозитарий должна быть выведена подсказка, 
какими способами заполучить такой репозитарий себе (скачать, создать, 
импортировать и т.п).

3. Возможность запуска, указав путь к репозитарию.

4. После успешной сборки - подсказку, что дальше можно сделать с 
собранным пакетом: поставить себе в систему, поставить в виртуальную 
систему, поставить

5. Утилиту(ы) с единым синтаксисом для сборки в rpmbuild и hasher - 
отличающуюся либо суффиксом в названии (build-rpmbuild, build-hasher), 
либо какой-то опцией (build --engine=rpmbuild, build --engine=hasher). 
Второе даже предпочительнее, т.к. можно этот самый engine по умолчанию 
задать через конфиг, кому как удобнее.

6. Сокрытие SRPMок как таковых от пользователя - они создаются и живут 
только где-то внутри. Наружу они выходят только для отправки в инкаминг 
и то, пока этот механизм не умрет.

Кто-нибудь может высказать еще какие-то соображения?

-- 
WBR, Mikhail Yakshin AKA GreyCat