Re: [d-kernel] kernel-std-up-2.4.25-alt2 rebuild failed?

[Sergey Vlasov <vsu@altlinux.ru>]

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

On Wed, Mar 31, 2004 at 01:04:16PM +0300, Ed V. Bartosh wrote:
> Anton Farygin <rider@altlinux.com> writes:
> 
> >> > Давайте отменим существующую схему сборки пакетов (для ядер). Что проще ?
> >> Вы ее уже фактически отменили. С чем Вас и поздравляю.
> >> Про полиси правда забыли, но это же мелочь, не правда ли ?
> >
> > Я уже просил показать мне то место, где мы нарушаем policy ;-) Ответа так
> > и не последовало.
> >
> Я имел в виду не нарушение полиси, а то, что такого рода изменения
> нужно проводить через полиси. Если бы это было сделано, то всех этих
> недоразумений не было бы.

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

> Насчет нарушения полиси я могу задать аналогичный вопрос: какой из
> пунктов полиси нарушу я, если завтра залью в incoming какой-либо из
> kernel- пакетов ?

Никакой.  Вероятно, пакет даже попадёт в Сизиф, и даже будет
использован при очередной пересборке ядер, если его версия окажется
самой свежей на этот момент.  Но если это окажется один из пакетов,
лежащих в kernel CVS, и не будет предупреждения о такой заливке в
incoming, скорее всего, те, кто пользуются CVS, просто не заметят
этот пакет, и при очередном обновлении соответствующего пакета в CVS
он будет просто заменён на версию из CVS.

На самом деле эта ситуация ничем не отличается от заливки одного и
того же пакета несколькими людьми при отсутствии соответствующей
договорённости между ними.  CVS в данном случае является средством
синхронизации, обеспечивающим невозможность случайно потерять
изменения, внесённые другими.  Кроме того, это ещё и средство для
обхода тормозного incoming (иначе пакет, залитый в incoming, может
быть использован для сборки ядер в лучшем случае на следующий день,
а то и с ещё большей задержкой).

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