From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <45C302A1.7090806@altlinux.org> Date: Fri, 02 Feb 2007 12:21:37 +0300 From: Mikhail Yakshin User-Agent: Thunderbird 1.5.0.5 (X11/20060822) MIME-Version: 1.0 To: ALT Devel discussion list References: <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> <45C26BA6.7060203@altlinux.org> <20070201235832.GA16720@mw.local.seiros.ru> In-Reply-To: <20070201235832.GA16720@mw.local.seiros.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [devel] Maintainer's toolbox 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: Fri, 02 Feb 2007 09:22:57 -0000 Archived-At: List-Archive: List-Post: Денис Смирнов пишет: > On Fri, Feb 02, 2007 at 01:37:26AM +0300, Mikhail Yakshin wrote: > >>> Ещё пока не выработалась схема по правильной работе с патчами в git. >>> Вообще-то они должны быть в отдельных бранчах. Хранить патчи в виде патчей >>> при использовании git это очень нехорошо. > MY> Значит, нам нужен как минимум обратный инструмент - который после > MY> srpmimport конвертит "Patch: ..." + "%patch-что-то-там", заводя их в git. > > См. первую строчку моей цитаты. Выработается -- можно будет писать. Ну, оно само по себе не выработается, если не будет некоего инструмента, который бы фиксировал эту практику. То же самое, как сейчас бардак по большому счету с выпускающими тэгами из-за отсутствия gear-release. >>> Думаю скорее группа пакетов для разных workflow. Например gear-svnupdate >>> не должен лежать там же где все остальное. Потому что он хочет svn, >>> который не всем нужен. > MY> Нам хотя бы один базовый пока набросать %) > > Базовый не требует ни одной утилиты из отсутствующих в пакете gear, все > остальное -- вариации на тему :) Такой "базовый" не требует ничего, кроме бинарного редактора - все файлы можно отредактировать вручную, и TCP-пакеты тоже разослать %) >>> Тогда вопрос о правильной схеме размещения. У меня, например, из-за обилия >>> пакетов структура такая: >>> git/ALTLinux -- там хранится все пакеты что я отправил на git.alt >>> git/ALTLinux/asterisk -- все связаное с астериском >>> git/ALTLinux/appliance -- appliance-* >>> и т. д. Я не представляю как это сделать пригодным для всех способом. > MY> Ok, понял, в ближайшее время сделаю такую возможность неплоского > MY> размещения пакетов. > MY> determine_package() переделаю так, чтобы он, если указан полный путь > MY> (типа "ALTLinux/asterisk/some-package") - собирал бы его, если нет - то > MY> искал бы соответствующую директорию find'ом; если найдена одна - то > MY> собирал бы оттуда; если их несколько - то ругался бы на то, что не может > MY> однозначно определить, что собирать (как rpm -e, когда под критерий > MY> подпадает >1 пакета). > > Разумно. Только с find'ом боюсь весело будет. Потому как в подкаталоги > репозиториев смотреть не надо. Ну, если будет тормозить - ограничим по -depth что-нибудь. Чтобы не хватал лишнего - будем следить, чтобы в каталоге репозитария был .git. > MY> 2. Именовать, надеясь на комплишен. Имена тогда значительно длиннее и > MY> максимально описательны. Возникает проблема completion space. Фактически > MY> обязательно использование completion. Как правило, вводится некий > MY> префикс наименования семейства утилит (git-*, gear-*, hsh-*, Sisyphus-*). > > А вот фиг там. git-* вообще-то deprecated, надо пользоваться git *, к > примеру. Вот как раз для удобного разделения completion namespace. Ссылку на то, что он deprecated, кстати, можно? Там предлагается какая-то аргументация? > MY> В качестве чуть альтернативной реализации - это когда делается одна > MY> "объединяющая" утилита (как в cvs, svn, git, gem) у которой первый > MY> параметр - команда, которую надо выполнить. Удобно, если есть умный > MY> комплишен а ля zsh или bash-completions, довольно неудобно, если нет. > > Ага. Что-то мне подсказывает, что zsh сейчас у нас не default shell, да и даже bash-completions стоят хорошо если у трети народа. > MY> Плюсы - наглядно, не надо запоминать практически ничего, кроме первых > MY> букв префикса. > MY> Минусы - чуть медленнее набирать, большая надежда на completion, надо > MY> продумывать так, чтобы удобно было комплитить и в completion попадали > MY> только нужные команды. > MY> Есть поклонники как одного стиля, так и другого. Поэтому, чтобы не > MY> мешать друг другу и не ломать копий - все равно это абсолютно вопрос > MY> привычки/удобства для конкретного человека - предлагаю сделать и так, и > MY> так - ровно как с опциями (-f и --force). Сделать симлинками или > MY> алиасами 2 варианта вызова - и длинный, и короткий. > > Понимаешь... в любом случае upper case utilites это зло. Давай все-таки не смешивать. Есть 3 отдельные темы: 1) Стиль наименования утилит - нужен и "короткий", и "длинный". Согласен? У кого-то еще какие-то мнения есть? 2) Upper case для именования утилит. Твое мнение я понял, свое - озвучил, есть еще у кого-то какие-то мнения? > Тем более что всем этим утилитам место в основном в gear-.* namespace. 3) Предложение убрать разделение на утилиты "низкого уровня" вроде gear-*, hsh-* и т.п. и "высокого уровня" - те, что лежат в etersoft-build-utils / comfort? Я тогда его совсем не понимаю... -- WBR, Mikhail Yakshin