From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <mike@fly.osdn.org.ua>
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on sa.int.altlinux.org
X-Spam-Level: 
X-Spam-Status: No, score=0.4 required=5.0 tests=BAYES_20,DNS_FROM_OPENWHOIS
	autolearn=no version=3.2.5
Date: Sat, 4 Dec 2010 21:15:42 +0200
From: Michael Shigorin <mike@osdn.org.ua>
To: ALT Linux Team development discussions <devel@lists.altlinux.org>
Message-ID: <20101204191542.GH24222@osdn.org.ua>
Mail-Followup-To: ALT Linux Team development discussions
	<devel@lists.altlinux.org>
References: <20101027065747.GA18226@altlinux.org>
	<20101103061456.GA22511@altlinux.org>
	<20101122071209.GC22001@altlinux.org>
	<20101122164334.GA1787@altlinux.org> <4CEABE12.3030406@rambler.ru>
	<20101122205740.GA7875@altlinux.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=koi8-r
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20101122205740.GA7875@altlinux.org>
User-Agent: Mutt/1.4.2.1i
Subject: Re: [devel] I: git.alt update
X-BeenThere: devel@lists.altlinux.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ALT Linux Team development discussions <devel@lists.altlinux.org>
List-Id: ALT Linux Team development discussions <devel.lists.altlinux.org>
List-Unsubscribe: <https://lists.altlinux.org/mailman/options/devel>,
	<mailto:devel-request@lists.altlinux.org?subject=unsubscribe>
List-Archive: <http://lists.altlinux.org/pipermail/devel>
List-Post: <mailto:devel@lists.altlinux.org>
List-Help: <mailto:devel-request@lists.altlinux.org?subject=help>
List-Subscribe: <https://lists.altlinux.org/mailman/listinfo/devel>,
	<mailto:devel-request@lists.altlinux.org?subject=subscribe>
X-List-Received-Date: Sat, 04 Dec 2010 19:09:58 -0000
Archived-At: <http://lore.altlinux.org/devel/20101204191542.GH24222@osdn.org.ua/>
List-Archive: <http://lore.altlinux.org/devel/>
List-Post: <mailto:devel@altlinux.org>

On Mon, Nov 22, 2010 at 11:57:40PM +0300, Dmitry V. Levin wrote:
> Нет, к сожалению, такая оптимизация была бы неправильной,
> поскольку любое изменение в репозитории теоретически может
> повлиять на результат обработки задания.

Я когда-то предлагал оставлять "на будущее" ресурсоёмкость сборки
(user/system time) и то, какие пакеты были установлены в чрут.
С тем, чтобы по возможности пользоваться закэшированной
информацией и применять более дорогие тесты только при
необходимости -- бишь если список пакетов по факту изменился,
то содержимое кэша признаётся невалидным вместе со сделанным
предварительным выводом.

К сожалению, тот контекст уже давно выветрился из головы и более
предметно выразить мыслю не могу, но это была комбинация
изобретательского принципа "сделай заранее" и закона 80/20.

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