From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <45C06DD7.9070906@altlinux.org> Date: Wed, 31 Jan 2007 13:22:15 +0300 From: Mikhail Yakshin User-Agent: Thunderbird 1.5.0.5 (X11/20060822) MIME-Version: 1.0 To: ALT Devel discussion list References: <45B8E365.1080509@solin.spb.ru> <45B90C15.8020708@altlinux.org> <20070125211925.GA28763@hell.immo.ru> <45B93635.4070607@altlinux.org> <20070127135712.GB716@hell.immo.ru> <45BB6203.1060605@altlinux.org> <20070128051043.GA8647@mw.local.seiros.ru> <45BCBD9D.2000608@altlinux.org> <20070129184508.GA8783@mw.local.seiros.ru> <45BE58BC.8060602@altlinux.org> <20070130115510.GA2088@mw.local.seiros.ru> In-Reply-To: <20070130115510.GA2088@mw.local.seiros.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [devel] I: gear-tarimport X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.9rc1 Precedence: list Reply-To: ALT Devel discussion list List-Id: ALT Devel discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jan 2007 10:23:28 -0000 Archived-At: List-Archive: List-Post: Денис Смирнов пишет: > MY> Посмотрел, спасибо, я раньше не знал о существовании этого пакета. Там > MY> есть масса полезных вещей (например, gear-rel, svn-update, gi, > MY> git-repos-cleanup, send-devel, pkg_release, sisyphus-list-incoming - они > MY> все по образу действия по-моему достаточно близки к comfort и хотелось > MY> бы их действительно по возможности объединить туда). > > Я только за. Потому как по моему личному мнению наличие в сизифе каждого > пакета с именем "..." это неявная бага. Если пакет seiros-.* > используется только у меня, то ему не место в сизифе. А если используется > не только мной, то почему бы не объединить все подобные утилиты в один > пакет? Ура =) Очень близкая мысль :) > MY> Относительно некоторых утилит - мне с первого взгляда оказалось не > MY> очевидным, что они делают %) > MY> ptch - для каких работ это предназначено? В git сейчас не проще просто > MY> скоммитить все "до" и "после" и вытащить этот патч, если он нужен > MY> файлом, просто с помощью разницы между ref'ами? > > Это для старой эпохи, хотя и сейчас изредка нужно. Есть некий workdir, > который не использует никакого SCM. Мы берем в нем и редактируем > некоторые файлы, переименовывая оригиналы в *.orig. Потом запускаем этот > файл, и получаем вывод по смыслу тот же что если бы мы набрали svn > diff/git diff в workdir где они используются. > > Сейчас я его использую в следующем случае: > - rpmbb > - В 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 в 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