On Sat, 17 Jan 2015 17:43:17 -0800 Zac Medico wrote: > On 01/17/2015 04:46 PM, Patrick Lauer wrote: > > On Saturday 17 January 2015 13:12:56 Zac Medico wrote: > >> On 01/17/2015 03:35 AM, Patrick Lauer wrote: > >>> * Portage is too slow > >>> > >>> On 'small' hardware emerge -upNDv @world can take enough time > >>> to make updates prohibitive - on an 800Mhz machine it took me > >>> about 3 days to figure out a solution to some silly blockers due to > >>> the > >>> very slow change test cycle > >>> Fix: Do some profiling and un-refactoring to remove useless code > >>> Fix: Set up a reference system (CI) to catch future regressions > >> > >> I'm certainly in favor of improving portage performance. However, for > >> "small" hardware (which includes many ARM and MIPS systems), we really > >> need to focus on binary package support. Note that dependency resolution > >> for installing binary packages tends to be much simpler than for > >> building ebuilds from source, and this translates into much shorter > >> dependency resolution time. > >> > > That's an orthogonal problem. And that's coming from someone who > > extensively > > uses binpkgs already ... > > Sure, but building from source on "small" hardware is not necessarily > the best practice. If our binary package support was better, then people > might be more likely to use "big" hardware to build packages for > distribution to "small" hardware.
Maybe I'm going offtopic, but emerge performance is not limiting factor here, at least from my experience; of course performance improvements in emerge are always welcomed. The largest problem with "small" hardware is cross-compilation from "large" hardware. Less powerful systems often have completely different architecture, e.g. I'd like to install Gentoo on Paspberry Pi B (why? just for fun and to compare its performance to Raspbian), but I don't have any other ARM hosts, so I have to build packages on ~amd64. Setting distcc is not enough here, because it can't handle configure, autotools, linking, non-C/C+ +/ObjC code and so no. And cross-compilation was always a black magick. I tried to setup ~amd64 host to build arbitrary arm packages, but I failed. The main problem is that too many packages bootstrap during compilation phase, e.g. compile some binary/library which is used later during compilation. Of course, code compiled for arm will not run on amd64, so package fails to build. Probably I should try to use QEMU as described in embedded handbook and offload compilation to distcc, even distcc on the same host in order to move most compilation process out of QEMU VM. Best regards, Andrew Savchenko
pgpR_I7ZF6aEr.pgp
Description: PGP signature
