From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-dev+bounces-60895-garchives=archives.gentoo.org@lists.gentoo.org>
Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80])
by finch.gentoo.org (Postfix) with ESMTP id 52B801381F3
for <garchives@archives.gentoo.org>; Sun, 16 Jun 2013 19:34:34 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 6F19CE0919;
Sun, 16 Jun 2013 19:34:25 +0000 (UTC)
Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183])
(using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits))
(No client certificate requested)
by pigeon.gentoo.org (Postfix) with ESMTPS id 66C32E0815
for <gentoo-dev@lists.gentoo.org>; Sun, 16 Jun 2013 19:34:24 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp.gentoo.org (Postfix) with ESMTP id ABECD33BE52
for <gentoo-dev@lists.gentoo.org>; Sun, 16 Jun 2013 19:34:23 +0000 (UTC)
X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org
X-Spam-Flag: NO
X-Spam-Score: -1.44
X-Spam-Level:
X-Spam-Status: No, score=-1.44 tagged_above=-999 required=5.5
tests=[AWL=-1.116, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.322,
SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from smtp.gentoo.org ([IPv6:::ffff:127.0.0.1])
by localhost (smtp.gentoo.org [IPv6:::ffff:127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 7l633ApcNw8X for <gentoo-dev@lists.gentoo.org>;
Sun, 16 Jun 2013 19:34:17 +0000 (UTC)
Received: from plane.gmane.org (plane.gmane.org [80.91.229.3])
(using TLSv1 with cipher AES256-SHA (256/256 bits))
(No client certificate requested)
by smtp.gentoo.org (Postfix) with ESMTPS id 3534233E060
for <gentoo-dev@gentoo.org>; Sun, 16 Jun 2013 19:34:15 +0000 (UTC)
Received: from list by plane.gmane.org with local (Exim 4.69)
(envelope-from <lnx-gentoo-dev@m.gmane.org>)
id 1UoIiK-0004G1-44
for gentoo-dev@gentoo.org; Sun, 16 Jun 2013 21:34:12 +0200
Received: from ip68-231-22-224.ph.ph.cox.net ([68.231.22.224])
by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00
for <gentoo-dev@gentoo.org>; Sun, 16 Jun 2013 21:34:12 +0200
Received: from 1i5t5.duncan by ip68-231-22-224.ph.ph.cox.net with local (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00
for <gentoo-dev@gentoo.org>; Sun, 16 Jun 2013 21:34:12 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: gentoo-dev@lists.gentoo.org
From: Duncan <1i5t5.duncan@cox.net>
Subject: [gentoo-dev] Re: Packages up for grabs
Date: Sun, 16 Jun 2013 19:33:53 +0000 (UTC)
Message-ID: <pan$c5bfa$8f5960ce$86320c08$2d133f6f@cox.net>
References: <1371376191.10717.15.camel@localhost>
<CAKmKYaCQQuUWdXvy6-4atX7OP0mR=YqpUV_U1_TVQOq=1RRCAg@mail.gmail.com>
<1371390923.28535.67.camel@big_daddy.dol-sen.ca>
<20130616164445.0c8f8f55@TOMWIJ-GENTOO>
<1371402560.28535.79.camel@big_daddy.dol-sen.ca>
<1371403298.22480.8.camel@localhost>
<20130616202324.45cb3262@TOMWIJ-GENTOO>
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
X-BeenThere: gentoo-dev@lists.gentoo.org
Reply-to: gentoo-dev@lists.gentoo.org
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: ip68-231-22-224.ph.ph.cox.net
User-Agent: Pan/0.140 (Chocolate Salty Balls; GIT 27fdbf2
/usr/src/portage/src/egit-src/pan2)
X-Archives-Salt: 35cf54bd-7747-486d-8aac-145976c169dd
X-Archives-Hash: ee7ce9fe0eb5225eb76b001fe5b244c0
Tom Wijsman posted on Sun, 16 Jun 2013 20:23:24 +0200 as excerpted:
> On Sun, 16 Jun 2013 19:21:38 +0200 Pacho Ramos <pacho@gentoo.org> wrote:
>
>> El dom, 16-06-2013 a las 10:09 -0700, Brian Dolbec escribió:
>> [...]
>> > Thank you for considering helping. I have stayed away form the
>> > intricate details of package management in the past, but I also do
>> > not like how long portage is taking now for dep calculations.
>>
>> And, cannot that efforts be put in enhancing portage instead?
>
> To make you see the problems and decisions, I'm going to elaborate a
> little and would like you to ask yourself some questions.
>
> Is it possible to reasonable enhance the Portage code to improve dep
> calculations in a reasonable amount of time?
TL;DR: SSDs help. =:^)
Quite apart from the theory and question of making the existing code
faster vs. a new from-scratch implementation, there's the practical
question of what options one can actually use to deal with the problem
/now/.
FWIW, one solution (particularly for folks who don't claim to have
reasonable coding skills and thus have limited options in that regard) is
to throw hardware at the problem.
I recently upgraded my main system to SDD. As it happens, my primary
boot didn't speed up much[1], but having both the main system partition
(bindirs/libdirs/etc) and the portage tree and overlays on SSD
*DRAMATICALLY* improved portage's update-ask-deep-newuse-@world
dependency resolution time, both for the cold-tree-cache case, and,
surprisingly, even (apparently, I've not timed it but I was sometimes
annoyed by the time before especially for hot-cache case, and it hasn't
bothered me at all since the upgrade) for the hot-cache case.
Between that and the 6-core bulldozer[3] I upgraded to last year, I'm
quite happy with portage's current performance, even doing routine
rebuilds of the perhaps half of kde I have installed, plus some other
packages with @live-rebuild.[2]
The SSD doesn't have to be particularly big, either, but fast (if you're
running SATA3 to use it) is nice. I figured ~64 gig usage here, tho I
wanted some overprovisioning, so thought I'd do 128 gig or so. I ended
up with 256 gig, only ~60% partitioned (130-some gig) even with
duplicate backup partitions for everything. System, tree, /home, etc, on
SSD, but still doing spinning rust for my media partitions and third-copy
(second backup) partitions, on demonstrated reliable here reiserfs, while
the SSD is all still-development-so-keep-your-backups-updated btrfs.
---
[1] I'm running ntp and the initial ntp-client connection and time sync
takes ~12 seconds a lot of the time, just over the initial 10 seconds
down, 50 to go, trigger on openrc's 1-minute timeout.
[2] 131 packages in @live-rebuild, with kde-live-branch, currently
4.10.49.9999, being low 120-some, plus choice bits of of X/mesa/drivers
and a few other packages including openrc, btrfs-progs and pan. The
@live-rebuild typically takes ~20 minutes with ccache, a good portion of
which is kdelibs, so the whole update including the sync and change/git-
logs check for interesting stuff, @world update, @live-rebuild, etc-
update and revdep-rebuild/depclean, runs ~1 hour, often less, sometimes
more if there's a new mozilla-overlay firefox build or something in
addition to the kde-libs long-build update.
[3] Also relevant, 16 gigs RAM, PORTAGETMPDIR on tmpfs.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman