From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <45C26BA6.7060203@altlinux.org> Date: Fri, 02 Feb 2007 01:37:26 +0300 From: Mikhail Yakshin User-Agent: Thunderbird 1.5.0.8 (X11/20061205) MIME-Version: 1.0 To: ALT Devel discussion list References: <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> <45C06DD7.9070906@altlinux.org> <20070131124213.GF6627@mw.local.seiros.ru> In-Reply-To: <20070131124213.GF6627@mw.local.seiros.ru> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Subject: Re: [devel] Maintainer's toolbox (was: 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: Thu, 01 Feb 2007 22:37:38 -0000 Archived-At: List-Archive: List-Post: Денис Смирнов wrote: > On Wed, Jan 31, 2007 at 01:22:15PM +0300, Mikhail Yakshin wrote: > >>> Я только за. Потому как по моему личному мнению наличие в сизифе каждого >>> пакета с именем "..." это неявная бага. Если пакет seiros-.* >>> используется только у меня, то ему не место в сизифе. А если используется >>> не только мной, то почему бы не объединить все подобные утилиты в один >>> пакет? > MY> Ура =) Очень близкая мысль :) > > :) > > Ещё бы ты принял мою мысль о том чтобы жестоко пилить пакеты вроде spt3 и > comfort на более мелкие пакеты, и мы могли бы наконец объединить наши > усилия вместо того чтобы трепаться :) 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 это очень нехорошо. Значит, нам нужен как минимум обратный инструмент - который после srpmimport конвертит "Patch: ..." + "%patch-что-то-там", заводя их в git. >>> Вообще многие такие вещи имеет смысл бить на пакеты из-за очень большого >>> объема requires. > MY> Согласен. Но некий базовый workflow-пакет с разумным объемом requires > MY> IMHO имеет право на существование. > > Думаю скорее группа пакетов для разных workflow. Например gear-svnupdate > не должен лежать там же где все остальное. Потому что он хочет svn, > который не всем нужен. Нам хотя бы один базовый пока набросать %) > 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-* > и т. д. Я не представляю как это сделать пригодным для всех способом. Ok, понял, в ближайшее время сделаю такую возможность неплоского размещения пакетов. determine_package() переделаю так, чтобы он, если указан полный путь (типа "ALTLinux/asterisk/some-package") - собирал бы его, если нет - то искал бы соответствующую директорию find'ом; если найдена одна - то собирал бы оттуда; если их несколько - то ругался бы на то, что не может однозначно определить, что собирать (как rpm -e, когда под критерий подпадает >1 пакета). > MY> 5. Утилиту(ы) с единым синтаксисом для сборки в rpmbuild и hasher - > MY> отличающуюся либо суффиксом в названии (build-rpmbuild, build-hasher), > MY> либо какой-то опцией (build --engine=rpmbuild, build --engine=hasher). > MY> Второе даже предпочительнее, т.к. можно этот самый engine по умолчанию > MY> задать через конфиг, кому как удобнее. > > Сейчас так и есть с etersoft-build-utils (правда первый вариант). Так как > отличия в одной букве утилиты, это вполне приемлимо. И даже удобнее чем > второй вариант. Я понял целую одну вещь: есть 2 подхода к именованию утилит: 1. Именовать в жестком unix-style - имена из 2-3, максимум 4 букв, все аббревиативно, подобрано специально для запоминания. Типичные представители - программы из coreutils, например. Плюсы - быстро набирать, при 2-3-4 keystrokes спложно конкурировать с ними по скорости набора. Минусы - надо запоминать их все; при наличии множественных вариантов, незначительно отличающихся друг от друга, получаем сложновоспринимаемые наборы символов; надо продумывать названия так, чтобы они как можно лучше ассоциировались с какими-то действиями. 2. Именовать, надеясь на комплишен. Имена тогда значительно длиннее и максимально описательны. Возникает проблема completion space. Фактически обязательно использование completion. Как правило, вводится некий префикс наименования семейства утилит (git-*, gear-*, hsh-*, Sisyphus-*). В качестве чуть альтернативной реализации - это когда делается одна "объединяющая" утилита (как в cvs, svn, git, gem) у которой первый параметр - команда, которую надо выполнить. Удобно, если есть умный комплишен а ля zsh или bash-completions, довольно неудобно, если нет. Плюсы - наглядно, не надо запоминать практически ничего, кроме первых букв префикса. Минусы - чуть медленнее набирать, большая надежда на completion, надо продумывать так, чтобы удобно было комплитить и в completion попадали только нужные команды. Есть поклонники как одного стиля, так и другого. Поэтому, чтобы не мешать друг другу и не ломать копий - все равно это абсолютно вопрос привычки/удобства для конкретного человека - предлагаю сделать и так, и так - ровно как с опциями (-f и --force). Сделать симлинками или алиасами 2 варианта вызова - и длинный, и короткий. -- WBR, Mikhail Yakshin AKA GreyCat ALT Linux [http://www.altlinux.ru] [xmpp:greycat@altlinux.org]