From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 014ED1381F3 for ; Sat, 27 Apr 2013 19:23:59 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C0739E0977; Sat, 27 Apr 2013 19:23:54 +0000 (UTC) Received: from mail-bk0-f46.google.com (mail-bk0-f46.google.com [209.85.214.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 128D8E0977 for ; Sat, 27 Apr 2013 19:23:53 +0000 (UTC) Received: by mail-bk0-f46.google.com with SMTP id e19so1720765bku.5 for ; Sat, 27 Apr 2013 12:23:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type:x-gm-message-state; bh=O8jenkesLzDoouZXuL5HdK4g9HkqYdpJhN4uapWWp8g=; b=ix2CNcLtg8iEHgOeQoaUTRzj+tSnZAlqaNlBdnYbL0xE3a6KHvoR0OFQbRDZelo623 WeMIMiwCkzoIDJE31ZruHWDbgS37+gX1oSoclpIUBWJXm3YkOGPhBipBiKh5S6TYKRYl R9eOhcD6DpXRd1AZzioHF0tPOorAKT9oSFpU1q9nAK9+wo/R/kwXaBhy5qBOlb5hAShE s8aqdzXGOJ3q01nwEhpYDG0dBEnozn2q90UXxpG+NPLLNEcxxMo2TIfBZ0q4L/elT5I7 BEWotsiZhqvvw1zX9To9fCyUEeOC9n10RMfEpmRCCrQK/sXkh7dkQty9jHdAhlPdUePM A39w== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-soc@lists.gentoo.org Reply-to: gentoo-soc@lists.gentoo.org MIME-Version: 1.0 X-Received: by 10.204.232.8 with SMTP id js8mr16757715bkb.109.1367090632247; Sat, 27 Apr 2013 12:23:52 -0700 (PDT) Received: by 10.205.0.10 with HTTP; Sat, 27 Apr 2013 12:23:52 -0700 (PDT) In-Reply-To: References: Date: Sun, 28 Apr 2013 01:23:52 +0600 Message-ID: Subject: Re: [gentoo-soc] rfc: reducing the time of "Calculating dependencies" phase project. From: =?UTF-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCR0LXRgNGB0LXQvdC10LI=?= To: gentoo-soc@lists.gentoo.org Content-Type: multipart/alternative; boundary=485b3979d8a4830ee504db5c97f9 X-Gm-Message-State: ALoCoQk9UphdC4tWvgBUnA0MjZwckpRTps/nDLzoRny3krqQZ27spBkiToahh2UrqyzifpSMrD4S X-Archives-Salt: 60ad4a96-94d8-488f-b91d-220db5a95ab1 X-Archives-Hash: bf2f83bc872b7bbb168c474d86d3fb3e --485b3979d8a4830ee504db5c97f9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Posted a proposal on https://google-melange.appspot.com/gsoc/proposal/review/google/gsoc2013/bay= /28002 . Best, Alexander Bersenev 2013/4/27 =D0=90=D0=BB=D0=B5=D0=BA=D1=81=D0=B0=D0=BD=D0=B4=D1=80 =D0=91=D0= =B5=D1=80=D1=81=D0=B5=D0=BD=D0=B5=D0=B2 > The modification date of /usr/portage and overlays dir can be used as a > signal for emerge to drop some caches. In this case the drop cache comman= d > could just do "touch ", and utils, modifying tree(e.g. "ebuild > manifest") could do this operation as well. > > Best, > Alexander Bersenev > > > > 2013/4/27 James Cloos > >> As someone whe often does edit ebuilds in overlays (very occasionally in >> /usr/portage, too), having to run something to update the cache for said >> overlay is OK. >> >> But it *must* update just the cli-specified overlay(s), w/o having to go >> through and update everything every time it is run. >> >> For comparison, my primary workstation, with several overlays, takes >> several minutes to do a dep. Even with a hot cache. Improving that to >> something reasonable is the single most important change portage can get= . >> >> Also, if /var/db/pkg is to be cached, the existing /var/db/pkg layout >> should remain as a backup, so that the cache of what is installed can >> be restored easily should it ever get corrupted. Portage can update >> that cache after updating the /var/db/pkg/ tree. >> >> -JimC >> -- >> James Cloos OpenPGP: 1024D/ED7DAEA6 >> >> > --485b3979d8a4830ee504db5c97f9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Best,
Alexander Bersenev


2013/4/27 =D0= =90=D0=BB=D0=B5=D0=BA=D1=81=D0=B0=D0=BD=D0=B4=D1=80 =D0=91=D0=B5=D1=80=D1= =81=D0=B5=D0=BD=D0=B5=D0=B2 <bay@hackerdom.ru>
The modification date of /u= sr/portage and overlays dir can be used as a signal for emerge to drop some= caches. In this case the drop cache command could just do "touch <= dir>", and utils, modifying tree(e.g. "ebuild <ebuild> m= anifest") could do this operation as well.

Best,
Alexander Bersenev



2013/4/27 James Cloos <cloos@jhcloos.com>
As someone whe often does edit ebuilds in ov= erlays (very occasionally in
/usr/portage, too), having to run something to update the cache for said overlay is OK.

But it *must* update just the cli-specified overlay(s), w/o having to go through and update everything every time it is run.

For comparison, my primary workstation, with several overlays, takes
several minutes to do a dep. =C2=A0Even with a hot cache. =C2=A0Improving t= hat to
something reasonable is the single most important change portage can get.
Also, if /var/db/pkg is to be cached, the existing /var/db/pkg layout
should remain as a backup, so that the cache of what is installed can
be restored easily should it ever get corrupted. =C2=A0Portage can update that cache after updating the /var/db/pkg/ tree.

-JimC
--
James Cloos <cloo= s@jhcloos.com> =C2=A0 =C2=A0 =C2=A0 =C2=A0 OpenPGP: 1024D/ED7DAEA6


--485b3979d8a4830ee504db5c97f9--