1 |
On 01/17/2015 03:35 AM, Patrick Lauer wrote: |
2 |
> * Portage is too slow |
3 |
> On 'small' hardware emerge -upNDv @world can take enough time |
4 |
> to make updates prohibitive - on an 800Mhz machine it took me |
5 |
> about 3 days to figure out a solution to some silly blockers due to the |
6 |
> very slow change test cycle |
7 |
> Fix: Do some profiling and un-refactoring to remove useless code |
8 |
> Fix: Set up a reference system (CI) to catch future regressions |
9 |
|
10 |
I'm certainly in favor of improving portage performance. However, for |
11 |
"small" hardware (which includes many ARM and MIPS systems), we really |
12 |
need to focus on binary package support. Note that dependency resolution |
13 |
for installing binary packages tends to be much simpler than for |
14 |
building ebuilds from source, and this translates into much shorter |
15 |
dependency resolution time. |
16 |
|
17 |
As I have expressed in other emails [1], I am currently working on |
18 |
making Gentoo's binary package support more competitive with binary |
19 |
distros. I have created a sys-apps/portage-9999 ebuild [2] for people |
20 |
who would like to test features not released in mainline portage yet. |
21 |
|
22 |
[1] http://thread.gmane.org/gmane.linux.gentoo.project/4205/focus=4217 |
23 |
[2] https://github.com/zmedico/portage-binpkg-support-overlay |
24 |
-- |
25 |
Thanks, |
26 |
Zac |