From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <rider@altlinux.ru>
Date: Wed, 31 Mar 2004 12:36:10 +0400
From: Anton Farygin <rider@altlinux.com>
To: ALT Linux kernel packages development <devel-kernel@altlinux.ru>
Subject: Re: [d-kernel] kernel-std-up-2.4.25-alt2 rebuild failed?
Message-ID: <20040331083610.GO29046@master.altlinux.ru>
References: <20040330110448.GB3757@master.mivlgu.local>
	<20040330111445.GD18144@master.altlinux.ru>
	<20040330113303.GA5598@master.mivlgu.local>
	<20040330114231.GO18144@master.altlinux.ru>
	<20040330115914.GB5598@master.mivlgu.local>
	<m365cmv817.fsf@pc213.belcaf.minsk.by>
	<20040330130507.GT18144@master.altlinux.ru>
	<m33c7qtpj2.fsf@pc213.belcaf.minsk.by>
	<20040330144029.GB6603@master.mivlgu.local>
	<m365cls9hu.fsf@pc213.belcaf.minsk.by>
Mime-Version: 1.0
Content-Type: text/plain; charset=koi8-r
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <m365cls9hu.fsf@pc213.belcaf.minsk.by>
X-BeenThere: devel-kernel@altlinux.ru
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: ALT Linux kernel packages development <devel-kernel@altlinux.ru>
List-Id: ALT Linux kernel packages development <devel-kernel.altlinux.ru>
List-Unsubscribe: <http://lists.altlinux.ru/mailman/listinfo/devel-kernel>,
	<mailto:devel-kernel-request@altlinux.ru?subject=unsubscribe>
List-Archive: <http://lists.altlinux.ru/pipermail/devel-kernel>
List-Post: <mailto:devel-kernel@altlinux.ru>
List-Help: <mailto:devel-kernel-request@altlinux.ru?subject=help>
List-Subscribe: <http://lists.altlinux.ru/mailman/listinfo/devel-kernel>,
	<mailto:devel-kernel-request@altlinux.ru?subject=subscribe>
X-List-Received-Date: Wed, 31 Mar 2004 08:36:10 -0000
Archived-At: <http://lore.altlinux.org/devel-kernel/20040331083610.GO29046@master.altlinux.ru/>
List-Archive: <http://lore.altlinux.org/devel-kernel/>
List-Post: <mailto:devel-kernel@altlinux.org>

On Wed, Mar 31, 2004 at 11:31:41AM +0300, Ed V. Bartosh wrote:
> Sergey Vlasov <vsu@altlinux.ru> writes:
> 
> > Я могу представить 2 варианта поддержки пакета:
> >
> > 1) Пакет лежит в kernel CVS - в этом случае все изменения в него
> > вносятся только через CVS.
> >
> > 2) Пакет просто лежит в Сизифе, при этом не содержится в kernel CVS;
> > новые версии приходят обычным образом через любой incoming.
> >
> > Попытки как-то совместить эти два варианта для одного пакета
> > приведут только к хаосу.  Хотя, если у вас есть какой-то метод,
> > решающий эту проблему - интересно было бы его узнать.
> Я предлагаю убрать способ N1 как класс. По той простой причине, что он
> не обеспечивает совместимости с существующей схемой сборки
> пакетов. Которую, повторюсь, никто еще не отменял.

Давайте отменим существующую схему сборки пакетов (для ядер). Что проще ?

Способ N1 мы убирать не станем - это единственный на данный момент способ
нормально мантейнить один пакет одновременно нескольким разработчикам.

Rgds,
Rider