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