[Devel] Текущий порядок сборки uniset

Ср Мар 23 21:38:09 MSK 2011

В сообщении от Понедельник 21 марта 2011 Evgeny Sinelnikov написал(a):
...
> В нашем случае, для еtersoft-build-utils, не указаны ограничения, о
> которых я упоминал:
> - в rpmbb предполагается, что имя пакета совпадает с именем удалённого
> репозитория и находится в каталоге packages/ИМЯ_РЕПОЗИОРИЯ
Я так понимаю, что rpmbb — имя нарицательное, поскольку речь скорее всего о 
rpmbs.
Некоторые предположения действительно есть. И они не безосновательны.
1. Инструмент предназначен для сборки пакетов, и место для них определено — 
packages.
2. Очень нехорошо, когда название пакета не совпадает с названием репозитория.
3. На самом деле предположения вряд ли есть, потому что публикация идёт через 
нечто вроде git push git.alt, которой совершенно всё равно до названий.

> - имена бранчей для бекпортирования фиксированы и я не помню какие, а
> у меня где-как - M51, 5.1, p5...
И это нормально, чтобы люди не делали не помню как, где-как и кое-как.
Любой вариант из M51, 5.1, p5 поддерживается. Они же приняты в girar, так что 
не вижу проблем.

> - действия по сборке в карман не предусмотрены, потому что
> предполагаются из имени пакета
Не очень понял.
А что же делает
rpmbs -p название_кармана?
Мне кажется, собирает в карман, и успешно.

> Поскольку, команды высокоуровневые и сложные, мне кажется, что при их
> описании, нужно не просто указывать выполняемые действия, а развёрнуто
> представлять, какие реально команды выполняются.
Возможно. Но вряд ли этому место в описании. Может и стоит предусмотреть 
режим, когда будет выводится каждая значимая команда. Это не так сложно.

> Например, с ходу. Мне понравилась утилита ginit:
> Работа с удалённым репозиторием
>     * ginit [git.NAME] - создание удалённого репозитория
для git-репозитория с пакетом.

> - создаю каталог /home/sin/git/testpack
> - делаю его текущим
> - пробую выполнить
> $ ginit
> Error in /usr/bin/ginit: Can't detect project name. Run inside git repo.
> $ ginit --help
> Error in /usr/bin/ginit: Can't detect project name. Run inside git repo.
$ ginit -h
ginit - initialize repo in git.alt for current project
Use: ginit [GIRAR]
     ginit git.eter - for init in git.eter gear repo

> Где предусловия и постусловия? Пробую так:
А что ты ожидаешь получить, запуская создание удалённого репозитория в пустом 
git-репозитории?

> $ git init
> Initialized empty Git repository in /home/sin/git/testpack/.git/
> $ ginit
> Create remote testpack repo in git.alt:
> girar-init-db:  /people/sin/packages/testpack.git
> Create git.alt remote repo alias
> 
> Отлично! Где был создан удалённый репозиторий?

> $ git remote show
> git.alt
> $ git remote show git.alt
> * remote git.alt
>   Fetch URL: git.alt:packages/testpack.git
>   Push  URL: git.alt:packages/testpack.git
>   HEAD branch: (unknown)
> 
> Хорошо. Как создать на git.eter?
> $ ginit git.eter
> Create remote testpack repo in git.eter:
> girar-init-db:  /people/sin/packages/testpack.git
> Create git.eter remote repo alias
> $ git remote show git.eter
> * remote git.eter
>   Fetch URL: git.eter:packages/testpack.git
>   Push  URL: git.eter:packages/testpack.git
>   HEAD branch: (unknown)
> 
> Замечательно! Но я должен был об этом всём догадаться. Какая же это
Может, это интуитивно понятно, раз догадался? :)

> детальная документация? Я только после прочтения всего текста понял,
Нито и не говорил, что это детальная документация. Детальную может создать 
только сторонний наблюдатель, натыкающийся на недосказанности.

> что [git.NAME] - это предполагаемый псевдоним из ~/.ssh/config для
> соответствующего удалённого узла. Об этом тоже нигде не сказано.
См.
http://www.altlinux.org/Git.alt/Краткое_руководство

Первый пример:
$ ssh git.alt find-package bugzilla

Что такое git.alt, объяснено конечно в стороне по ссылке. Но мне казалось, что 
человек, имеющий опыт с ALT, вполне в курсе, что он писал в ~/.ssh/config

> Что же, в итоге делает утилита:
> #!/usr/bin/ginit
> ssh git.NAME init-db GIT_DIR_NAME
> git remote add git.NAME git.NAME:package/GIT_DIR_NAME
> 
> Я обычно выполняю это вручную.... Иначе я должен помнить, что имя
ginit на самом деле внутренняя команда, которая используется в других 
скриптах.
Но ничего зазорного ввести ginit вместо двух строк с кучей повторяющихся слов 
я не вижу. Ещё надо учесть, сколько опечаток и ошибок можно сделать в этих 
двух строках.

> репозитория будет соответствовать имени каталога, но ведь так не
> всегда бывает.
Основной проблемой как и является вот эта ссылка «так не всегда бывает». Если 
следовать этому ложному (при наличии цели в в виде снижения порога вхождения) 
принципу, то надо отказаться от всех обобщений, высокоуровневых языков, 
различных классификаций и вообще контекста.

> Удалённый репозиторий должен иметь такое же имя, а что
> если такой уже есть?
Если хочешь запутать других людей, а потом и себя, конечно, можешь создать 
удалённый репозиторий test3, в котором хранить последнюю версию uniset. Но 
смысл?

> Слишком много контекста... Нельзя рассчитывать, что у того, кто читает
> документацию, есть какой бы то ни было контекст. Либо об этом нужно
Как раз таки надо установить контекст, и действовать в его окружении. Иначе 
все программы придётся писать на ассемблере, и начинать с начального 
загрузчика в первых 446 байтах MBR.

Без контекста ничего нельзя ни понять, ни запомнить, ни автоматизировать.

> указывать ссылками на другие документы.
Не вижу проблемы указать.
Как и не вижу проблемы дописать узнанное в виде ссылки и строки.

> >> Думаю, что это тема отдельной задачи.
> > 
> >  Хорошо. Мне просто хочется сейчас ряд простых действий, для того чтобы
> > отправить на сборку новую версию. Если достаточно того, что ты написал
> > выше git push
> > ssh git.eter rebuild
> > пусть так..
> 
> нет....
> $ ssh git.eter rebuild PACKAGE_NAME [BRANCH_NAME]
Всё-таки /projects/PACKAGE_NAME
Поверх этого, учитывая пример из документации
$ ssh git.office rebuild -p standpm /projects/asu/standpm-weblog
должен быть инструмент, который позволит связать для данного контекста 
репозиторий, карман, версию бранча системы... 

Я вообще не понимаю, что это было? Критика инструмента? Ну собери пакет с 
новой версией исходников, потратив на это 20 секунд, без него.
Критика недостатка документации? Ну да, может и нет вводной статьи.
Но из практики — когда достаточно знать, что отправить пакет на сборку можно 
командой
$ rpmbs -u
и ничего больше знать не надо. Другой подход — изучать _море_ другой, кстати, 
тоже ненаписанной и вообще непонятной документации. Проверить это легко на 
новом человеке.

-- 
С уважением,
Виталий Липатов
Россия, Санкт-Петербург. www.etersoft.ru
GNU! ALT Linux Team! WINE! WIKI! LaTeX! LyX!