On Fri, Feb 02, 2007 at 01:37:26AM +0300, Mikhail Yakshin wrote:

>> Ещё бы ты принял мою мысль о том чтобы жестоко пилить пакеты вроде spt3 и
>> comfort на более мелкие пакеты, и мы могли бы наконец объединить наши
>> усилия вместо того чтобы трепаться :)
MY> spt3 распилен, пожалуйста, смотри. Как пилить comfort - я пока не очень
MY> понимаю, предлагай.

Ok, посмотрю.

>> Ещё пока не выработалась схема по правильной работе с патчами в git.
>> Вообще-то они должны быть в отдельных бранчах. Хранить патчи в виде патчей
>> при использовании git это очень нехорошо.
MY> Значит, нам нужен как минимум обратный инструмент - который после
MY> srpmimport конвертит "Patch: ..." + "%patch-что-то-там", заводя их в git.

См. первую строчку моей цитаты. Выработается -- можно будет писать.

>> Думаю скорее группа пакетов для разных workflow. Например gear-svnupdate
>> не должен лежать там же где все остальное. Потому что он хочет svn,
>> который не всем нужен.
MY> Нам хотя бы один базовый пока набросать %)

Базовый не требует ни одной утилиты из отсутствующих в пакете gear, все
остальное -- вариации на тему :)

>> Тогда вопрос о правильной схеме размещения. У меня, например, из-за обилия
>> пакетов структура такая:
>> 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'ом боюсь весело будет. Потому как в подкаталоги
репозиториев смотреть не надо.

MY> 2. Именовать, надеясь на комплишен. Имена тогда значительно длиннее и
MY> максимально описательны. Возникает проблема completion space. Фактически
MY> обязательно использование completion. Как правило, вводится некий
MY> префикс наименования семейства утилит (git-*, gear-*, hsh-*, Sisyphus-*).

А вот фиг там. git-* вообще-то deprecated, надо пользоваться git *, к
примеру. Вот как раз для удобного разделения completion namespace.

MY> В качестве чуть альтернативной реализации - это когда делается одна
MY> "объединяющая" утилита (как в cvs, svn, git, gem) у которой первый
MY> параметр - команда, которую надо выполнить. Удобно, если есть умный
MY> комплишен а ля zsh или bash-completions, довольно неудобно, если нет.

Ага.

MY> Плюсы - наглядно, не надо запоминать практически ничего, кроме первых
MY> букв префикса.
MY> Минусы - чуть медленнее набирать, большая надежда на completion, надо
MY> продумывать так, чтобы удобно было комплитить и в completion попадали
MY> только нужные команды.
MY> Есть поклонники как одного стиля, так и другого. Поэтому, чтобы не
MY> мешать друг другу и не ломать копий - все равно это абсолютно вопрос
MY> привычки/удобства для конкретного человека - предлагаю сделать и так, и
MY> так - ровно как с опциями (-f и --force). Сделать симлинками или
MY> алиасами 2 варианта вызова - и длинный, и короткий.

Понимаешь... в любом случае upper case utilites это зло. Тем более что
всем этим утилитам место в основном в gear-.* namespace.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
<shulik> что значит в спеке: %force_disable
<Ktirf> shulik: Отключение использования Великой Силы.