On Wed, Jan 31, 2007 at 01:22:15PM +0300, Mikhail Yakshin wrote: >> Я только за. Потому как по моему личному мнению наличие в сизифе каждого >> пакета с именем "..." это неявная бага. Если пакет seiros-.* >> используется только у меня, то ему не место в сизифе. А если используется >> не только мной, то почему бы не объединить все подобные утилиты в один >> пакет? MY> Ура =) Очень близкая мысль :) :) Ещё бы ты принял мою мысль о том чтобы жестоко пилить пакеты вроде spt3 и comfort на более мелкие пакеты, и мы могли бы наконец объединить наши усилия вместо того чтобы трепаться :) >> Сейчас я его использую в следующем случае: >> - rpmbb >> - В 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 в 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@