[devel] Maintainer's toolbox (was: I: gear-tarimport)

Пт Фев 2 01:37:26 MSK 2007

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

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 это очень нехорошо.

Значит, нам нужен как минимум обратный инструмент - который после
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]