[devel] [devel-announce] I: girar builder

[devel] [devel-announce] I: girar builder

[@ 2009-02-03 19:31 UTC (permalink / raw)]

Re: [devel] [devel-announce] I: girar builder

[@ 2009-02-03 20:04 UTC (permalink / raw)]

Re: [devel] [devel-announce] I: girar builder

[@ 2009-02-03 20:11 UTC (permalink / raw)]

Re: [devel] [devel-announce] I: girar builder

[@ 2009-02-04 21:57 UTC (permalink / raw)]

Re: [devel] [devel-announce] I: girar builder

[@ 2009-02-04 21:59 UTC (permalink / raw)]

Re: [devel] [devel-announce] I: girar builder

[@ 2009-02-03 21:06 UTC (permalink / raw)]

Re: [devel] [devel-announce] I: girar builder

[@ 2009-02-03 21:09 UTC (permalink / raw)]

Re: [devel] [devel-announce] I: girar builder: noarch check

[@ 2009-02-04 14:06 UTC (permalink / raw)]

Re: [devel] I: girar builder: GIT archives

[@ 2009-02-03 21:20 UTC (permalink / raw)]

Re: [devel] I: girar builder: GIT archives

[@ 2009-02-04 9:04 UTC (permalink / raw)]

Re: [devel] I: girar builder: GIT archives

[@ 2009-02-04 9:37 UTC (permalink / raw)]

Re: [devel] I: girar builder: GIT archives

[@ 2009-02-04 12:48 UTC (permalink / raw)]

Re: [devel] I: girar builder: GIT archives

[@ 2009-02-04 12:59 UTC (permalink / raw)]

Re: [devel] I: girar builder: GIT archives

[@ 2009-02-04 13:02 UTC (permalink / raw)]

Re: [devel] I: girar builder: GIT archives

[@ 2009-02-06 6:49 UTC (permalink / raw)]

Re: [devel] I: girar builder: GIT archives

[@ 2009-02-06 10:50 UTC (permalink / raw)]

Re: [devel] I: girar builder: GIT archives

[@ 2009-02-04 13:13 UTC (permalink / raw)]

Re: [devel] I: girar builder: GIT archives

[@ 2009-02-04 13:16 UTC (permalink / raw)]

Re: [devel] [JT] всем шампанского! (I: girar builder)

[@ 2009-02-04 4:39 UTC (permalink / raw)]

Re: [devel] [JT] всем шампанского! (I: girar builder)

[@ 2009-02-04 7:10 UTC (permalink / raw)]

Re: [devel] [JT] всем шампанского! (I: girar builder)

[@ 2009-02-04 7:57 UTC (permalink / raw)]

Re: [devel] [devel-announce] I: girar builder

[@ 2009-02-04 4:41 UTC (permalink / raw)]

Re: [devel] [devel-announce] I: girar builder

[@ 2009-02-04 9:38 UTC (permalink / raw)]

Re: [devel] [devel-announce] I: girar builder

[@ 2009-02-04 9:58 UTC (permalink / raw)]

Re: [devel] [devel-announce] I: girar builder

[@ 2009-02-04 12:01 UTC (permalink / raw)]

Re: [devel] [devel-announce] I: girar builder

[@ 2009-02-04 16:29 UTC (permalink / raw)]

Re: [devel] [devel-announce] I: girar builder

[@ 2009-02-04 7:08 UTC (permalink / raw)]

Re: [devel] [devel-announce] I: girar builder

[@ 2009-02-04 7:28 UTC (permalink / raw)]

Re: [devel] [devel-announce] I: girar builder

[@ 2009-02-04 9:43 UTC (permalink / raw)]

Re: [devel] [devel-announce] I: girar builder

[@ 2009-02-04 7:35 UTC (permalink / raw)]

Re: [devel] [devel-announce] I: girar builder

[@ 2009-02-04 7:46 UTC (permalink / raw)]

Re: [devel] [devel-announce] I: girar builder

[@ 2009-02-04 8:21 UTC (permalink / raw)]

Re: [devel] [devel-announce] I: girar builder

[@ 2009-02-04 8:38 UTC (permalink / raw)]

Re: [devel] [devel-announce] I: girar builder

[@ 2009-02-05 13:41 UTC (permalink / raw)]

Re: [devel] [devel-announce] I: girar builder

[@ 2009-02-06 21:43 UTC (permalink / raw)]

Re: [devel] [devel-announce] I: girar builder

[@ 2009-02-08 20:50 UTC (permalink / raw)]

Re: [devel] [devel-announce] I: girar builder

[@ 2009-02-04 22:07 UTC (permalink / raw)]

Re: [devel] [devel-announce] I: girar builder

[@ 2009-02-04 22:22 UTC (permalink / raw)]

Re: [devel] [devel-announce] I: girar builder

[@ 2009-02-05 0:03 UTC (permalink / raw)]

Re: [devel] [devel-announce] I: girar builder

[@ 2009-02-05 16:31 UTC (permalink / raw)]

Re: [devel] [devel-announce] I: girar builder

[@ 2009-02-05 6:49 UTC (permalink / raw)]

Re: [devel] [devel-announce] I: girar builder ExclusiveArch

[@ 2009-02-05 11:12 UTC (permalink / raw)]

Re: [devel] [devel-announce] I: girar builder ExclusiveArch

[@ 2009-02-05 12:14 UTC (permalink / raw)]

Re: [devel] [devel-announce] I: girar builder ExclusiveArch

[@ 2009-02-05 12:15 UTC (permalink / raw)]

Re: [devel] [devel-announce] I: girar builder ExclusiveArch

[@ 2009-02-05 12:42 UTC (permalink / raw)]

Re: [devel] [devel-announce] I: girar builder ExclusiveArch

[@ 2009-02-05 12:58 UTC (permalink / raw)]

Re: [devel] [devel-announce] I: girar builder ExclusiveArch

[@ 2009-02-05 13:05 UTC (permalink / raw)]

Re: [devel] [devel-announce] I: girar builder ExclusiveArch

[@ 2009-02-05 13:23 UTC (permalink / raw)]

Re: [devel] [devel-announce] I: girar builder

[@ 2009-02-05 9:33 UTC (permalink / raw)]

Re: [devel] [devel-announce] I: girar builder

[@ 2009-02-05 11:15 UTC (permalink / raw)]

Re: [devel] [devel-announce] I: girar builder

[@ 2009-02-05 11:18 UTC (permalink / raw)]

Re: [devel] [devel-announce] I: girar builder

[@ 2009-02-05 11:39 UTC (permalink / raw)]

Re: [devel] [devel-announce] I: girar builder

[@ 2009-02-06 7:05 UTC (permalink / raw)]

Re: [devel] [devel-announce] I: girar builder

[@ 2009-02-06 7:32 UTC (permalink / raw)]

Re: [devel] [devel-announce] I: girar builder

[@ 2009-02-06 7:38 UTC (permalink / raw)]

Re: [devel] [devel-announce] I: girar builder

[@ 2009-02-06 9:45 UTC (permalink / raw)]

Re: [devel] [devel-announce] I: girar builder

[@ 2009-02-06 9:49 UTC (permalink / raw)]

Re: [devel] [devel-announce] I: girar builder

[@ 2009-02-05 13:34 UTC (permalink / raw)]

Re: [devel] [devel-announce] I: girar builder

[@ 2009-02-05 16:00 UTC (permalink / raw)]

Re: [devel] [devel-announce] I: girar builder

[@ 2009-02-05 13:39 UTC (permalink / raw)]

Re: [devel] [devel-announce] I: girar builder

[@ 2009-02-05 13:46 UTC (permalink / raw)]

Re: [devel] [devel-announce] I: girar builder

[@ 2009-02-05 16:08 UTC (permalink / raw)]

Re: [devel] [devel-announce] I: girar builder

[@ 2009-02-05 16:27 UTC (permalink / raw)]

Re: [devel] [devel-announce] I: girar builder

[@ 2009-02-05 16:34 UTC (permalink / raw)]

Re: [devel] [devel-announce] I: girar builder

[@ 2009-02-05 16:37 UTC (permalink / raw)]

Re: [devel] [devel-announce] I: girar builder

[@ 2009-02-05 17:51 UTC (permalink / raw)]

Re: [devel] [devel-announce] I: girar builder

[@ 2009-02-06 11:06 UTC (permalink / raw)]

Re: [devel] dsohowto

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 283 bytes --]

On Fri, Feb 06, 2009 at 02:06:14PM +0300, Ivan Fedorov wrote:
[...]
> > А вот для этого уже symbol versioning придуман.
> Кстати у кого-нить есть хороше объяснение на русском, ну или хотябы на
> простом английском?

http://people.redhat.com/drepper/dsohowto.pdf


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] [devel-announce] I: girar builder

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 985 bytes --]

On Thu, Feb 05, 2009 at 06:27:15PM +0200, Led wrote:

>> Без этого точечные обновления идут лесом. Вот пример с libdb и постгресом
>> -- они не вызывают проблем с точечным обновлением. А вот многие другие
>> пакеты именно из-за несоблюдения этого правила таки вызывают.
L> Они в любом случае "идут лесом", потому как неизменность сонеймов не является 
L> гарантией того, что "точечно обновлённая" софтина будет работать со старой 
L> библиотекой с тем же сонеймом.

Однако если мне надо не "точечено обновить", а поставить софтину из репо,
которая требует новую версию библиотеки, а у меня десяток приложений
требуют старой версии (со старым soname) в случае если предложенное мною
правило выполняется -- я сделаю apt-get install и буду счастлив.

Если же не выполняется -- apt-get install либо пойдет лесом либо вынесет
мне пол системы.

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

http://freesource.info
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] [devel-announce] I: girar builder

[Ivan Fedorov]

[-- Attachment #1: Type: text/plain, Size: 1031 bytes --]

Денис Смирнов <mithraen-u2l5PoMzF/Uox3rIn2DAYQ@public.gmane.org> writes:

> On Thu, Feb 05, 2009 at 02:15:16PM +0300, Dmitry V. Levin wrote:
>
> DVL> Зачем удалять compat-библиотеку, если у неё ещё остались пользователи?
>
> Хочу policy на compat. В котором имена %name-compat будут явно запрещены,
> а вместо этого будет %name%ver.
>
> Потому что это все извращения над репозиториям которые ломают нормальное
> обновление системы.
+1

> И, IMHO, для lib%name должен быть запрет паковать следующую версию с тем
> же именем, но не содержающую тех же sonames что и предыдущая.
ммм... тут лучше давать настойчивую рекомендацию... а запрет - это уже
явный перебор!

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [devel] [devel-announce] I: girar builder

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 602 bytes --]

On Fri, Feb 06, 2009 at 02:01:00PM +0300, Ivan Fedorov wrote:

>> И, IMHO, для lib%name должен быть запрет паковать следующую версию с тем
>> же именем, но не содержающую тех же sonames что и предыдущая.
IF> ммм... тут лучше давать настойчивую рекомендацию... а запрет - это уже
IF> явный перебор!

Чтобы так делать у человека должны быть серьезные причины. А я очень часто
вижу что без серьезных причин кроме "неохота версионировать имена пакетов"
это делают.

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

http://freesource.info
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] [devel-announce] I: girar builder

[Michael Shigorin]

On Tue, Feb 03, 2009 at 10:31:16PM +0300, Dmitry V. Levin wrote:
> 2. Сборка пакетов из srpm-файлов:
> + она ещё работает

Это "ещё" не может не радовать, поскольку...

> + при наличии предыдущей сборки из gear пакета с данным именем
>   новая сборка этого пакета не пройдёт проверку наследования
>   от этой предыдущей сборки и будет отвергнута

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

Из примеров, которые сразу приходят на ум -- firefox (3.0.6 на
дворе, 3.0.4 в сизифе) и apache, за который я теперь просто не
возьмусь по здоровью, даже если найти время на сам пакет.

Иными словами, в этом нововведении мне видится lock-in похуже
sisyphus ACL, поскольку переубедить этого робота будет сложней
-- прибиванием gear repo с историей такого пакета, что вряд ли
будет выполняться охотно.  Уровень же вхождения сейчас слишком
высокий, тут вон матёрые разработчики git пытаются использовать
как cvs на колёсиках и с этим очень сложно что-то сделать.

src.rpm при всех своих недостатках простые задачи позволял решать
просто.

В остальном -- поздравляю!

PS: вернулся в Киев, попытаюсь догнать почту по мере наличия
свободного времени.

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

Re: [devel] [devel-announce] I: girar builder

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 2280 bytes --]

On Sun, Feb 08, 2009 at 08:09:20PM +0200, Michael Shigorin wrote:
> On Tue, Feb 03, 2009 at 10:31:16PM +0300, Dmitry V. Levin wrote:
> > 2. Сборка пакетов из srpm-файлов:
> > + она ещё работает
> 
> Это "ещё" не может не радовать, поскольку...

Но они обрабатываются с прежней скоростью, а вот нативные git-задания
обрабатываются заметно быстрее.

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

При заорфанивании (==удалении) пакета наследование не проверяется.

> а также возможность упростить чрезмерно запутанный
> предшественником репозиторий.
> 
> Из примеров, которые сразу приходят на ум -- firefox (3.0.6 на
> дворе, 3.0.4 в сизифе)

У firefox не столько git запутан, сколько srpm-пакеты.

> и apache, за который я теперь просто не
> возьмусь по здоровью, даже если найти время на сам пакет.

В случае необходимости можно собирать по своему разумению.

> Иными словами, в этом нововведении мне видится lock-in похуже
> sisyphus ACL,

Я бы не преувеличивал.  Кстати говоря, про sisyphus ACL, я жду предложений
по временным характеристикам nmu approval в соседнем треде.

Я заметил, что некоторые пассивные мантейнеры превратили свои пакеты в
нечто странное: сами не тянут, и другим не дают.
Я хочу, чтобы действия робота в отношении таких пакетов не выглядели
произволом со стороны робото-писателя.  Так что жду ваших предложений.

> поскольку переубедить этого робота будет сложней
> -- прибиванием gear repo с историей такого пакета, что вряд ли
> будет выполняться охотно.  Уровень же вхождения сейчас слишком
> высокий, тут вон матёрые разработчики git пытаются использовать
> как cvs на колёсиках и с этим очень сложно что-то сделать.
> 
> src.rpm при всех своих недостатках простые задачи позволял решать
> просто.

Я бы не стал преувеличивать процент сложно устроенных git-репозиториев.

> В остальном -- поздравляю!

Спасибо.

> PS: вернулся в Киев, попытаюсь догнать почту по мере наличия
> свободного времени.

С возвращением!


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] [devel-announce] I: girar builder

[Grigory Batalov]

On Sun, Feb 08, 2009 at 08:09:20PM +0200, Michael Shigorin wrote:

> > + при наличии предыдущей сборки из gear пакета с данным именем
> >   новая сборка этого пакета не пройдёт проверку наследования
> >   от этой предыдущей сборки и будет отвергнута
> 
> ...это убьёт переход от свалившего или потерявшего интерес
> майнтейнера-разработчика к обычному стиральному порошку,
> а также возможность упростить чрезмерно запутанный
> предшественником репозиторий.
> 
> Из примеров, которые сразу приходят на ум -- firefox (3.0.6 на
> дворе, 3.0.4 в сизифе) и apache, за который я теперь просто не
> возьмусь по здоровью, даже если найти время на сам пакет.
> 
> Иными словами, в этом нововведении мне видится lock-in похуже
> sisyphus ACL, поскольку переубедить этого робота будет сложней
> -- прибиванием gear repo с историей такого пакета, что вряд ли
> будет выполняться охотно.

Разве "git merge -s ours" в этом случае не будет работать?

> Уровень же вхождения сейчас слишком
> высокий, тут вон матёрые разработчики git пытаются использовать
> как cvs на колёсиках и с этим очень сложно что-то сделать.
> 
> src.rpm при всех своих недостатках простые задачи позволял решать
> просто.

Re: [devel] [devel-announce] I: girar builder

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1208 bytes --]

On Sun, Feb 08, 2009 at 10:22:00PM +0300, Grigory Batalov wrote:
> On Sun, Feb 08, 2009 at 08:09:20PM +0200, Michael Shigorin wrote:
> 
> > > + при наличии предыдущей сборки из gear пакета с данным именем
> > >   новая сборка этого пакета не пройдёт проверку наследования
> > >   от этой предыдущей сборки и будет отвергнута
> > 
> > ...это убьёт переход от свалившего или потерявшего интерес
> > майнтейнера-разработчика к обычному стиральному порошку,
> > а также возможность упростить чрезмерно запутанный
> > предшественником репозиторий.
> > 
> > Из примеров, которые сразу приходят на ум -- firefox (3.0.6 на
> > дворе, 3.0.4 в сизифе) и apache, за который я теперь просто не
> > возьмусь по здоровью, даже если найти время на сам пакет.
> > 
> > Иными словами, в этом нововведении мне видится lock-in похуже
> > sisyphus ACL, поскольку переубедить этого робота будет сложней
> > -- прибиванием gear repo с историей такого пакета, что вряд ли
> > будет выполняться охотно.
> 
> Разве "git merge -s ours" в этом случае не будет работать?

Речь идёт о разработчиках, которые не достигли уровня пользователя git,
достаточного для того, чтобы выполнить эту операцию.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] [devel-announce] I: girar builder

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 2662 bytes --]

On Sun, Feb 08, 2009 at 08:09:20PM +0200, Michael Shigorin wrote:

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

Давай определимся. Есть два типа мантейнеров:
- те кто вкурили в git хоть как-то;
- те кто _не_ вкурили в git;

Первым этот подход, ясное дело, однозначно удобнее. Вторым _не
обязательно_ вкуривать в git. gear-srpmimport делает достаточно для того
чтобы пакет просто собирался.

Если же предыдущий мантейнер сделал слишком крутой репозиторий, то всегда
есть выбор:

1. внутри репо удалить в master все файлы, и начать _с нуля_ новую
историю. Но старая останется к ней подшита. Просто будет коммит который
убил все старое.

2. разобраться чуть больше с git'ом.

Это все не страшно, особенно с учетом того что в devel всегда масса народу
который подскажет даже откровенному ламеру (то бишь не желающему прочитать
даже everyday git) как решить его проблему.

Вот для меня сейчас страшнее другое -- импорт из upstream SCM. Ибо если я
делаю этот импорт локально, а потом заливаю на сервер, а потом окажется
хоть один такой коммит который был назабэкаплен, и моя машинка отправится
лесом -- то историю придется наверняка переписывать с нуля. Это раз.

Кроме того это означает что другой мантейнер уже однозначно не сможет
нормально обновить этот пакет. Увы.

MS> Иными словами, в этом нововведении мне видится lock-in похуже
MS> sisyphus ACL, поскольку переубедить этого робота будет сложней
MS> -- прибиванием gear repo с историей такого пакета, что вряд ли
MS> будет выполняться охотно.  Уровень же вхождения сейчас слишком
MS> высокий, тут вон матёрые разработчики git пытаются использовать
MS> как cvs на колёсиках и с этим очень сложно что-то сделать.

Да, они используют его как cvs на колесиках, и я не вижу в этом ничего
плохого. git можно использовать сильно по-разному.

MS> src.rpm при всех своих недостатках простые задачи позволял решать
MS> просто.

А вот тут ты прав. Что-нибудь простое опакетить если ты больше ничего и не
пакетил -- теперь сложнее.

Ты это... если есть какие-то вопросы по git -- заезжай в гости, проведу
мастер-класс. Хоть я и сам ламер, но разобрался с git'ом уже вполне
неплохо :)

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

http://freesource.info
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] [devel-announce] I: girar builder

[Led]

On Tuesday, 10 February 2009 03:26:11 Денис Смирнов wrote:

> Вот для меня сейчас страшнее другое -- импорт из upstream SCM. Ибо если я
> делаю этот импорт локально, а потом заливаю на сервер, а потом окажется
> хоть один такой коммит который был назабэкаплен, и моя машинка отправится
> лесом -- то историю придется наверняка переписывать с нуля. Это раз.

По-моему, вы сильно преувеличиваете...

-- 
Led

Re: [devel] [devel-announce] I: girar builder

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 943 bytes --]

On Tue, Feb 10, 2009 at 04:26:11AM +0300, Денис Смирнов wrote:
[...]
> Вот для меня сейчас страшнее другое -- импорт из upstream SCM. Ибо если я
> делаю этот импорт локально, а потом заливаю на сервер, а потом окажется
> хоть один такой коммит который был назабэкаплен, и моя машинка отправится
> лесом -- то историю придется наверняка переписывать с нуля. Это раз.

Я не понял этот пассаж совсем.

> MS> src.rpm при всех своих недостатках простые задачи позволял решать
> MS> просто.
> 
> А вот тут ты прав. Что-нибудь простое опакетить если ты больше ничего и не
> пакетил -- теперь сложнее.

Я точно знаю, что git'ом можно пользоваться на уровне, не превосходящем по
своей примитивности rsync srpm-файлов.  И даже при этом пользователь
выигрывает в скорости/трафике и управляемости процесса сборки.

P.S.  Интересно, сколько лет у нас уйдёт на то, чтобы все мантейнеры
полностью перешли на gear-сборку...


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] [devel-announce] I: girar builder

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 3021 bytes --]

On Tue, Feb 10, 2009 at 04:46:47AM +0300, Dmitry V. Levin wrote:

>> Вот для меня сейчас страшнее другое -- импорт из upstream SCM. Ибо если я
>> делаю этот импорт локально, а потом заливаю на сервер, а потом окажется
>> хоть один такой коммит который был назабэкаплен, и моя машинка отправится
>> лесом -- то историю придется наверняка переписывать с нуля. Это раз.
DVL> Я не понял этот пассаж совсем.

Есть, ну скажем, zaptel.git. Он создан с использованием git-svn.

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

Скорее всего он будет вынужден самостоятельно воспользоваться git-svn,
после чего делать cherry-picks. Это единственный известный мне способ
выполнить такое обновление.

После этого, когда я попытаюсь сделать обновление, будет некрасивый merge
в истории. Но это мы стерпим, там сейчас и так история выглядит
страшненько.

А вот если у меня репозиторий где я выполняю git-svn случайно прекратит
свое существование, то дальнейшее обновление этого пакета без git merge -s
ours будет просто невозможным. А _с_ таковым -- будет во-первых кошмарик в
истории, а во-вторых уже не каждый из мантейнеров понимает как это
сделать. Лично я месяц назад с этой задачей не справился бы вообще.

>> А вот тут ты прав. Что-нибудь простое опакетить если ты больше ничего и не
>> пакетил -- теперь сложнее.
DVL> Я точно знаю, что git'ом можно пользоваться на уровне, не превосходящем по
DVL> своей примитивности rsync srpm-файлов.  И даже при этом пользователь
DVL> выигрывает в скорости/трафике и управляемости процесса сборки.

Этап 1 -- написать spec. Без этого собрать пакет невозможно :)
Этап 2 -- rpmbuild -bs/rpmbs (в случае с git -- git init-db, git add,
gear-commit).
Этап 3 -- подпись пакета, rsync (в случае с git -- установка тэга, push,
ssh git.alt build)

С точки зрения примитивности -- процедура та же. Для человека который уже
привык к git и написал себе упрощающие жизнь утилитки, через git _проще_.
Но стоимость входа -- выше.

У нас есть где-нибудь простой HOWTO "как собрать простой hello world в RPM
через gear"? Как только он будет эту проблему можно считать
незначительной.

DVL> P.S.  Интересно, сколько лет у нас уйдёт на то, чтобы все мантейнеры
DVL> полностью перешли на gear-сборку...

Не знаю. Разобраться бы еще с некоторыми вопросами...

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

Кроме того чудесный набор утилит etersoft-build-utils, который сейчас по
своему удобству незаменим, с gear почти не работает (если бы не работали
rpmbs и rpmbb мне было бы совсем грустно).

А мои seiros-build-utils -- слишком специфичны, и у меня есть большие
сомнения что кроме меня им кто-либо пользуется.

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

http://freesource.info
----------------------------------------------------------------------------


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] [devel-announce] I: girar builder

[Aleksey Avdeev]

[-- Attachment #1: Type: text/plain, Size: 1297 bytes --]

Денис Смирнов пишет:
> On Tue, Feb 10, 2009 at 04:46:47AM +0300, Dmitry V. Levin wrote:
> 
>>> Вот для меня сейчас страшнее другое -- импорт из upstream SCM. Ибо если я
>>> делаю этот импорт локально, а потом заливаю на сервер, а потом окажется
>>> хоть один такой коммит который был назабэкаплен, и моя машинка отправится
>>> лесом -- то историю придется наверняка переписывать с нуля. Это раз.
> DVL> Я не понял этот пассаж совсем.
> 
> Есть, ну скажем, zaptel.git. Он создан с использованием git-svn.
> 
> Вопрос -- каким образом другой мантейнер может выполнить обновление этого
> пакета, если он хочет обновить именно из апстрима?
> 
> Скорее всего он будет вынужден самостоятельно воспользоваться git-svn,
> после чего делать cherry-picks. Это единственный известный мне способ
> выполнить такое обновление.

   Как вариант: завести специально обученный бранч для svn2git. Ещё 
хорошо к комитам в него вытянутое привязывать (см. 
<http://git.altlinux.org/people/solo/public/?p=apache_all.git;a=shortlog;h=refs/heads/svnimport2git.alt> 
на предмет svnimport2git.alt).

> 
> После этого, когда я попытаюсь сделать обновление, будет некрасивый merge
> в истории. Но это мы стерпим, там сейчас и так история выглядит
> страшненько.

-- 

С уважением. Алексей.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 552 bytes --]

Re: [devel] [devel-announce] I: girar builder

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 658 bytes --]

On Tue, Feb 10, 2009 at 07:01:14AM +0300, Aleksey Avdeev wrote:

AA>    Как вариант: завести специально обученный бранч для svn2git. Ещё 
AA> хорошо к комитам в него вытянутое привязывать (см. 
AA> <http://git.altlinux.org/people/solo/public/?p=apache_all.git;a=shortlog;h=refs/heads/svnimport2git.alt> 
AA> на предмет svnimport2git.alt).

Я так и делаю. Но это не спасает, особенно если переписывать имена
коммиттеров, например. Это будет спасать только если git-svn будет
отрабатывать на стороне серверов altlinux.

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

http://freesource.info
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] [devel-announce] I: girar builder

[Slava Semushin]

10 февраля 2009 г. 9:41 пользователь Денис Смирнов <mithraen@altlinux> написал:
[...]
> У нас есть где-нибудь простой HOWTO "как собрать простой hello world в RPM
> через gear"? Как только он будет эту проблему можно считать
> незначительной.

Возможно, что стОит опираться на эту страничку: http://www.altlinux.org/Gear/kis


-- 
+ Slava Semushin | slava.semushin @ gmail.com
+ ALT Linux Team | php-coder @ altlinux.ru

Re: [devel] [devel-announce] I: girar builder

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 677 bytes --]

On Tue, Feb 10, 2009 at 12:46:20PM +0600, Slava Semushin wrote:
>> У нас есть где-нибудь простой HOWTO "как собрать простой hello world в RPM
>> через gear"? Как только он будет эту проблему можно считать
>> незначительной.
SS> Возможно, что стОит опираться на эту страничку: http://www.altlinux.org/Gear/kis

Возможно, но ее следует сильно доработать:

- про git://git.altlinux.ru/archive -- ни слова
- про /gears -- аналогично

кстати по поводу find-package, а то что он не ищет в archive и gears это
так и задумано или недоделка?

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

http://freesource.info
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] [devel-announce] I: girar builder

[Vitaly Lipatov]

On 10 февраля 2009, Денис Смирнов wrote:
...
> Кроме того чудесный набор утилит etersoft-build-utils, который
> сейчас по своему удобству незаменим, с gear почти не работает
> (если бы не работали rpmbs и rpmbb мне было бы совсем
> грустно).
А что именно не работает?
В 1.5.6 rpmbph обучен бэкпортировать прямо из git.
Остальное дописывается, но в той небольшой мере, в какой я 
использую git.


-- 
С уважением,
Виталий Липатов
Санкт-Петербург
GNU! ALT Linux Team! WINE! LaTeX! LyX! http://freesource.info

Re: [devel] [JT] I: girar builder

[Alexey Rusakov]

[-- Attachment #1: Type: text/plain, Size: 447 bytes --]

В Втр, 10/02/2009 в 04:46 +0300, Dmitry V. Levin пишет:
> P.S.  Интересно, сколько лет у нас уйдёт на то, чтобы все мантейнеры
> полностью перешли на gear-сборку...
Сколько тебе Костя Осипов ответил на позапрошлой конференции, когда ты
его спросил про сроки миграции MySQL? Три года? Если предположить, что
начало процесса было в позапрошлом году, осталось года полтора...

-- 
  Alexey "Ktirf" Rusakov
  GNOME Project
  ALT Linux Team

[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] [devel-announce] I: girar builder

[Kirill A. Shutemov]

[-- Attachment #1: Type: text/plain, Size: 393 bytes --]

On Tue, Feb 03, 2009 at 10:31:16PM +0300, Dmitry V. Levin wrote:
> Hi,
> 
> На git.alt активирована сборка пакетов.

А можно ли в
http://git.altlinux.org/tasks/$task_id/build/$subtask_id/$arch/log
складывать лог в реалтайме?

-- 
Regards,  Kirill A. Shutemov
 + Belarus, Minsk
 + ALT Linux Team, http://www.altlinux.org/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] [devel-announce] I: girar builder

[Alexey Morsov]

[-- Attachment #1: Type: text/plain, Size: 746 bytes --]

On Thu, Feb 19, 2009 at 04:23:52PM +0200, Kirill A. Shutemov wrote:
> 
> А можно ли в
> http://git.altlinux.org/tasks/$task_id/build/$subtask_id/$arch/log
> складывать лог в реалтайме?
И ссылку в отчете на него вставить сразу :)


-- 
WBR,
Alexey Morsov
программист ЗАО "ИК "Риком-Траст"
Jabber: samurai@www.fondmarket.ru
ALT Linux Team Member

> Забирайте [пакет из obsolete]
Спасибо. Больше ни у кого не будет возражений против проведения
эксгумации с последующей гальванизацией и реанимацией?
		-- mutabor in devel@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 489 bytes --]

Re: [devel] [devel-announce] I: girar builder

[Grigory Batalov]

On Tue, Feb 03, 2009 at 10:31:16PM +0300, Dmitry V. Levin wrote:

> 1. Сборка пакетов из gear-репозиториев:
> + она существует; она работает!
> + успешно собранные пакеты сразу публикуются на
>   http://git.altlinux.org/gears/ (он же git.altlinux.org::gears)
> + при наличии в git.altlinux.org/gears предыдущей сборки пакета
>   с данным именем новая сборка этого пакета должна быть основана
>   на этой предыдущей сборке

А как теперь следует пересобирать зависимые пакеты при обновлении
библиотек? Ранее можно было воспользоваться командой
$ hsh --rebuild-prog=rebuild-prog.sh ...
(см. /usr/share/doc/hasher-*/rebuild-prog.sh)

Теперь же обновлённый srpm не будет принят, поскольку не был собран
из git (если предыдущая версия была из git, что уже не редкость).
Придётся заводить себе кучу репозитариев и коммитить в них?
Не очень удобно.
... 
> 2. Сборка пакетов из srpm-файлов:
> + она ещё работает, но теперь уже поверх сборки из gear-репозиториев
> + успешно собранные пакеты сразу публикуются на
>   http://git.altlinux.org/archive/ (он же git.altlinux.org::archive)
> + при наличии предыдущей сборки из gear пакета с данным именем
>   новая сборка этого пакета не пройдёт проверку наследования
>   от этой предыдущей сборки и будет отвергнута
...