[devel] srpms -> gear

Ср Июл 4 00:18:40 MSD 2007

PreScriptum: дайджест по треду.

On Tue, Jul 03, 2007 at 02:21:44PM +0400, Aleksey Novodvorsky wrote:
> > > Давайте отделять мух от котлет. Здесь нет никого,
> > > заинтересованного в сокрытии исходников. Наоборот.  Но
> > > форма предоставлени исходников может меняться. Важно, чтобы
> > > она была удобной, а не такой же, как всегда.

Да не в сокрытии исходников вопрос, а в практичной доступности
изменений.

Опять же по моей мерке -- дистрибутивы различаются качеством
сборки пакетов [в т.ч. патчами/интеграцией], апдейтами и
сообществом.  Последнее оценивается только субъективно,
второе -- скорее объективно, а вот первое -- смесью того 
и другого.

Например, netch@ был явно впечатлён, почитав патчи к альтовской
glibc при подготовке одного из курсов.  Не уверен, что он стал
бы читать git.  Хотя можно и спросить.

> > Собственно говоря, вопрос в том, как, распространяя исходный
> > код в форме, наиболее удобной разработчикам, минимизировать
> > неудобства для всех остальных.  Ибо неудобства из-за любого
> > изменения формы неизбежны.
> В первую очередь нужна хорошая и понятная документация с
> разъяснением преимуществ git. Она должна не просто лежать в
> сторонке, а попадаться на глаза.

Да теоретические преимущества понятны, просто нарываешься на
практические грабли и то, что приходится изобретать самому
в лучшем случае уже изобретённое в gear-*.

Кукбук нужен вроде "Everyday GIT".  Хотя бы по тому, что уже есть.
Готов пойти в подопытные кролики :)

On Tue, Jul 03, 2007 at 06:38:37PM +0400, Dmitry V. Levin wrote:
> > Я кстати согласен с Майк'ом - очень хочется иметь возможность
> > получить один или несколько патчей по сравнению с mainstream.
> Это тривиально, если соблюдается простое правило "один коммит
> не содержит логически несвязанных патчей"; в противном случае
> есть риск получить удовольствие собирать патч по разным
> коммитам, в которых находятся по несколько кусков логически
> несвязанных патчей.

Как обновить патч? (рекомендации, какие видел -- "откати в том
бранче старый патч и накати новый" -- больше похожи на увеличение
количества ручного труда, чем наоборот; хотя если бранчи строго
по патчам, то это вроде как --reset HEAD^, нет?)

On Tue, Jul 03, 2007 at 10:06:17PM +0400, Dmitry V. Levin wrote:
> > > > Если патч нужно обновить, то его нужно обновить.
> > > > Не надо одним коммитом обновлять разные патчи по частям.
> > > Вот... в общем нужно нормальное руководство по всему этому
> > > хозяйству.. а не архивы списков рассылки.
> > я об этом с самого начала говорил
> Сначала коллективное знание будет в архивах списков рассылки,
> потом кто-нибудь вызовется (или мы кого-нибудь попросим)
> привести это знание к более удобному для постижения виде.
> Наоборот не получится.  C'est la vie.  Так что продолжайте
> задавать вопросы и высказывать свои соображения.

Этому кому-то с радостью передам (немало пополнившийся из этого
треда) =packages/gear и заодно =packages/git.

> Валера, это проще чем xorg собирать.

xorg собирать (или истребитель водить) может быть привычней.

On Tue, Jul 03, 2007 at 02:40:55PM +0400, Dmitry V. Levin wrote:
> > > Давайте отделять мух от котлет.
> > я пока не вижу удобного способа "отделить котлеты от мух" в
> > git-репозитариях, а именно - получить тарболл и патчи к
> > пакету из репозитария.
> Разные gear-репозитории устроены по-разному, поскольку
> практически ничего не мешает мантейнерам организовать свои
> репозитории так как им удобно.

Не всегда так, как удобно -- мне кажется, немало (особенно
поначалу и возможно так и оставленных) в попытках найти вариант,
который так и не нашёлся.

Напоминает средний класс с ящиком кубиков Рубика, незнакомых 
с системой кручения этой цапы.

On Tue, Jul 03, 2007 at 03:11:33PM +0400, Dmitry V. Levin wrote:
> > Я давно уже зарёкся "выковыривать" что-либо из чьего-то
> > git-репозитария: лично мне на практике проще взять
> > оригинальный tarball от разработчика, или даже
> > за-checkout'ить CVS/SVN и заново пропатчить. Хотя, возможно,
> > я просто туплю...
> Давайте попробуем смоделировать ситуацию на конкретном примере,
> на ваш выбор.

Ну вот человек на опеннете пришёл с конкретно zsh и выяснил,
какой из патчей вызывал проблему.  Как выяснил -- я так и не
понял пока, наверное, из старого src.rpm.

> > а, возможно, потому, что "Разные gear-репозитории устроены
> > ПО-РАЗНОМУ, поскольку практически НИЧЕГО НЕ МЕШАЕТ не мешает
> > мантейнерам организовать свои репозитории так как ИМ удобно".
> На практике при всём потенциальном многообразии выделяется три
> основных типа устройства репозитория, см. EXAMPLES в
> gear-rules(5):

Спасибо!

> http://git.altlinux.org/people/ldv/packages/?p=gear.git;a=blob_plain;f=gear-rules.5.html;hb=html

http://git.altlinux.org/people/ldv/packages/gear.git/gear-rules.5.html
получается сделать или излишне?

On Tue, Jul 03, 2007 at 03:11:52PM +0400, Денис Смирнов wrote:
> Для разработчика проблем с git нет никаких, если он соизволил
> научиться им пользоваться.

If.

> Реальная проблема другая -- нужен инструмент не для
> разработчиков в team, а для тех кто со стороны хочет
> подсмотреть/утащить к себе патчи, тем самым убедившись
> в грамотности сборки у нас.

Приходим к тому, что есть "проблема представления", которую может
иметь смысл решать не именно на git.altlinux.org, а возможно и на
вторичном ресурсе вроде sisyphus.ru.

On Tue, Jul 03, 2007 at 08:59:18PM +0400, Dmitry V. Levin wrote:
> Так что если прикладывать патч не на скорую руку, то надо
> завести для патча бранч, закоммитить туда, а потом сделать git
> pull.

Вот это бы тоже как-то автоматизировать, чтоб ненароком не
засунуть в уже существующий бранч или ещё чего.  Кто так делает
-- там есть типичная последовательность действий или не особо?

On Tue, Jul 03, 2007 at 02:59:47PM +0400, Денис Смирнов wrote:
> Как я уже не раз говорил -- тебе это только кажется. Если ты
> действительно _хочешь_ перенести в git, то просто натрави на
> эти пакет gear-srpmimport.  И с получившимся результатом
> работай так, как будто ты работаешь без всякого git.

Несколько мелких фенечек вроде alterator-laserjet, которые я
делал и которые не содержат патчей -- именно так и были втянуты
и поддерживаются ещё с той осени.

> Да, ты не получишь преимуществ git, и у тебя патчи будут лежать
> файликами.  Но это будет работать уже сегодня.  Глянь на мой
> репозиторий с ppp. Там та же самая ситуация.

У меня и так сегодня работает ;)  Проблемы бывали -- например,
ненароком один src.rpm накрыл файлики из другого (наступал при
сборке apache для updates и backports в одном vserver'е, один
раз заметил, минимум один -- нет).  Зачем мне SCM, понимаю.

> >> Видимого смысла в srpm-паетах после миграции на
> >> gear-репозитории не будет.
> MS> Было бы всё-таки хорошо иметь какой-то простой вариант понять,
> MS> чем отличается пакет от upstream tarball.  Причём не глазами
> MS> разработчика (им проще), а скорее глазами опытного админа.
> В случае с приведенной выше "тупой" сборкой -- это видно
> невооруженным взглядом. А вот если используются особенности
> git, то да, для этого нужен какой-то инструмент.

git действительно заточен скорее на оперативный merge патчей
как минимум в рамках своей ветки (и между ветками).  Хорошая
цель и хорошо, если для ядра оно работает, но в жизни попадаются
и совсем другие ситуации.

У админа mindset другой, для него патч вполне может быть
непрозрачным.  Этакая штука, которую если прилепить -- с этим
полегчает или то починится.  Ему не надо ничего мержить, ему
чтоб работало.

Возможно, в случае толкового подхода к git.alt у нас будут
наблюдатся "спарки" админов, которые знают, как приготовить пакет
и где в ём вылазят проблемы при использовании, и разработчиков,
которые озадачены приведением разницы между нашим git и апстримом
к нулю.  Дожить бы до такого :)

On Tue, Jul 03, 2007 at 08:41:58PM +0400, Dmitry V. Levin wrote:
> > Пример: http://git.altlinux.org/people/ldv/packages/?p=file.git
> Добавил ещё одно правило для http-сервера, теперь можно
> использовать более естественные адреса, например:
> http://git.altlinux.org/people/ldv/packages/file.git

Только хотел спросить, а не руками ли то было набрано :)
Спасибо.

Ещё бы https://bugzilla.altlinux.org/bugid сделать:
http://www.bugzilla.org/docs/2.16/html/rewrite.html

-- 
 ---- WBR, Michael Shigorin <mike на altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/