Re: [gentoo-dev] Things one could be upset about

[Andrew Savchenko]

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