[devel] I: gear-tarimport

Ср Янв 31 15:42:13 MSK 2007

On Wed, Jan 31, 2007 at 01:22:15PM +0300, Mikhail Yakshin wrote:

>> Я только за. Потому как по моему личному мнению наличие в сизифе каждого
>> пакета с именем "<firmname>..." это неявная бага. Если пакет seiros-.*
>> используется только у меня, то ему не место в сизифе. А если используется
>> не только мной, то почему бы не объединить все подобные утилиты в один
>> пакет?
MY> Ура =) Очень близкая мысль :)

:)

Ещё бы ты принял мою мысль о том чтобы жестоко пилить пакеты вроде spt3 и
comfort на более мелкие пакеты, и мы могли бы наконец объединить наши
усилия вместо того чтобы трепаться :)

>> Сейчас я его использую в следующем случае:
>>  - rpmbb <spec>
>>  - В BUILD имеем несобравшийся пакет
>>  - переименовываю то что пытаюсь править в .orig и запускаю make (чтобы не
>>    пересобирать весь пакет)
>>  - повторяю предыдущий шаг до тех пор пока пакет не соберется
>>  - ptch > 1.patch
>>  - переношу этот патч в каталог с git, и либо привязываю его как новый
>>    патч к пакету, либо набираю patch -p0 < 1.patch
MY> Вот, отлично, еще одна схема workflow у нас появилась :) Как бы ее 
MY> проапгрейдить для git'а? Например, чтобы собираемый патч автоматически 
MY> привязывался к пакету в git'е и прописывался как "PatchX: ..." и %patch 
MY> что-то там?

Ещё пока не выработалась схема по правильной работе с патчами в git.
Вообще-то они должны быть в отдельных бранчах. Хранить патчи в виде патчей
при использовании git это очень нехорошо.

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

Этот скрипт не пакуется в пакет. Он лежит как и все скрипты в том каталоге
так, как заготовка, на случай если я или кто ещё захочет этим
воспользоваться как базой.

>> Когда-нибудь я озверею и напишу даже скрипт Commit :)
>> Вообще эта группа недоскриптов если и нужна, то их следует упаковать в
>> отдельный пакет. Хотя бы потому что они тянут зависимость и на git, и на
>> svn. А если я чего-нибудь не того выпью, то и на cvs потянут.
MY> Т.е. отдельный маленький проект - организация общего интерфейса ко всем 
MY> version control системам. По-моему - нужная и полезная вещь.

Да.

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

Думаю скорее группа пакетов для разных workflow. Например gear-svnupdate
не должен лежать там же где все остальное. Потому что он хочет svn,
который не всем нужен.

>> Думаю да. В любом случае получится один low level и стайка high level
>> пакетов.
>> Кстати etersoft-build-utils мы с lav@ уже давно допинали до
>> работоспособности с gear. rpmbb <specname> в git repo отрабатывает именно
>> так как ожидается.
MY> Насколько я видел, когда смотрел последний раз - там просто меняется 
MY> оборачивается использование rpmbuild или hsh в gear, если есть каталог .git.

Да.

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

Гм. Думал Виталий не будет протестовать против патча :)

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

Тогда вопрос о правильной схеме размещения. У меня, например, из-за обилия
пакетов структура такая:
git/ALTLinux -- там хранится все пакеты что я отправил на git.alt
git/ALTLinux/asterisk -- все связаное с астериском
git/ALTLinux/appliance -- appliance-*

и т. д. Я не представляю как это сделать пригодным для всех способом.

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

Это уже обертка.

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

Сейчас так и есть с etersoft-build-utils (правда первый вариант). Так как
отличия в одной букве утилиты, это вполне приемлимо. И даже удобнее чем
второй вариант.

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

Опять же при сборке через rpmbb так и происходит.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
Никогда не меняйте uid вручную, пользуйтесь usermod(8).
		-- ldv in community@
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип     : application/pgp-signature
Размер  : 189 байтов
Описание: Digital signature
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20070131/c56b5f74/attachment-0001.bin>