[gentoo-dev] Re: Packages up for grabs

[Duncan]

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@g.o> 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