From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Tue, 3 Jul 2007 23:18:40 +0300 From: Michael Shigorin To: ALT Devel discussion list Message-ID: <20070703201839.GI21702@osdn.org.ua> Mail-Followup-To: ALT Devel discussion list References: <777d80610707030302n7c25bb4ele0affb553bca5e9@mail.gmail.com> <468A5D96.1010201@altlinux.com> <20070703143837.GA22577@basalt.office.altlinux.org> <20070702193052.GB15594@osdn.org.ua> <20070703092329.GD21702@osdn.org.ua> <20070703092836.GE10014@basalt.office.altlinux.org> <200707031253.21420.ledest@gmail.com> <777d80610707030302n7c25bb4ele0affb553bca5e9@mail.gmail.com> <20070703101444.GC12339@basalt.office.altlinux.org> <777d80610707030321q4b6aaf6fp737984b68a6c4f47@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20070703164158.GA25385@basalt.office.altlinux.org> <20070703105947.GA14247@mw.local.seiros.ru> <20070703165918.GB25385@basalt.office.altlinux.org> <20070703111152.GC14247@mw.local.seiros.ru> <20070703111133.GA15625@basalt.office.altlinux.org> <20070703104055.GA14300@basalt.office.altlinux.org> <20070703180617.GA28433@basalt.office.altlinux.org> <20070703143837.GA22577@basalt.office.altlinux.org> <777d80610707030321q4b6aaf6fp737984b68a6c4f47@mail.gmail.com> User-Agent: Mutt/1.4.2.1i Subject: Re: [devel] srpms -> gear 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: Tue, 03 Jul 2007 20:15:17 -0000 Archived-At: List-Archive: List-Post: 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 ------ Linux.Kiev http://www.linux.kiev.ua/