1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA1 |
3 |
|
4 |
On 01/26/2014 06:42 PM, Alan McKinnon wrote: |
5 |
> On 26/01/2014 17:24, eroen wrote: |
6 |
>> On Sun, 26 Jan 2014 16:35:43 +0200, Nikos Chantziaras |
7 |
>> <realnc@×××××.com> wrote: |
8 |
>>> Anyone else noticed this yet? Some portage update seems to have |
9 |
>>> made "emerge -uDN @world" perform about 10 times slower than |
10 |
>>> before. It used to take seconds, now it takes about 4 minutes |
11 |
>>> only to tell me that there's nothing to update. And it does |
12 |
>>> that every time, even directly in succession and with the |
13 |
>>> caches warm. |
14 |
>>> |
15 |
>>> Is it just me? |
16 |
>> |
17 |
>> You don't say when your baseline was, but the complexity of |
18 |
>> resolving the package tree has increased quite a bit over the |
19 |
>> last year due to new features like automatic rebuilds of |
20 |
>> consumers after library updates. |
21 |
>> |
22 |
>> Another somewhat common cause of sudden slowdowns is how portage |
23 |
>> resolves conflicts (like packageA requiring an old version of |
24 |
>> libraryB), which is rather time-consuming. You can try adding |
25 |
>> --backtrack=0 to the emerge command to make it stop and print an |
26 |
>> error message when encountering a conflict rather than look for a |
27 |
>> solution. Then you can 'help' out by manually resolving any |
28 |
>> conflicts by adding package versions to /etc/portage/package.mask |
29 |
>> . Preferably try this *after* running an update, so your system |
30 |
>> is up-to-date against your local version of the gentoo tree, |
31 |
>> otherwise "normal" simple-to-resolve conflicts might cause |
32 |
>> confusion. ;-) |
33 |
>> |
34 |
> |
35 |
> I've been noticing these slowdowns for a few months now too. I'm |
36 |
> somewhat conflicted in my head about them, as unresolved blockers |
37 |
> is now something that happens very rarely. How often did we do this |
38 |
> in the past: |
39 |
> |
40 |
> emerge -avuND world stare at output trying to figure out wtf? |
41 |
> emerge -C <some problem package> emerge -avuND world emerge problem |
42 |
> package back if world update didn't already do it |
43 |
> |
44 |
> That used to happen A LOT, and it took much longer than 4 minutes. |
45 |
> Nowadays it happens seldom but the resolution does take 4 minutes. |
46 |
> |
47 |
> So I dunno, it's annoying to have to wait, but it also prevents a |
48 |
> lot of wasted time by doing what software can do so well - |
49 |
> detecting dependency issues. |
50 |
> |
51 |
> |
52 |
> |
53 |
|
54 |
Dependency resolution is broken and incomplete. Portage is unable to |
55 |
print useful autounmask and similar messages to solve conflicts |
56 |
manually, is unable to solve circular deps at all and bails out on |
57 |
simple things like only updating vim when gvim is installed as well. |
58 |
Then we have dirty workarounds like PDEPEND which shouldn't be there |
59 |
in the first place... |
60 |
|
61 |
It's a miracle that it works at all, especially when people keep |
62 |
breaking the cache and rely on undefined behavior. Also... we still |
63 |
have binary files in the tree. |
64 |
|
65 |
Each EAPI adds more complexity to the dependency calculation. We have |
66 |
no performance regression tests. We don't have many people who want to |
67 |
look into portage code (can't blame them and since ferringb is gone we |
68 |
don't have any1 who works on the QA-side of the code). Afais, it will |
69 |
get a lot worse. |
70 |
|
71 |
So, not sure where your optimism comes from. But... some devs are |
72 |
interested in starting from scratch or picking up pkgcore (which would |
73 |
be the most sane thing to do IMO). |
74 |
-----BEGIN PGP SIGNATURE----- |
75 |
Version: GnuPG v2.0.22 (GNU/Linux) |
76 |
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ |
77 |
|
78 |
iQEcBAEBAgAGBQJS5U40AAoJEFpvPKfnPDWziK0IAKwuPe4DOBvamSkhtYbipZOv |
79 |
CdCmt4qjlYn/NjLMkyb8I5AO1m3rziHKuFnfMAksFodTZx9HJ8rbXh1H75bGNt+i |
80 |
k1cJ4Z6eg9R6hHqsBXAdwBfl4eDouINYMs2Q2R85XFD2QdZKUE/8AcUU5s2YHkxR |
81 |
NraYC/1n2LxUaXwA8D66KNHKSR31Gb5ISd+Slt+kvAGpXjRDJCDRAWD/QChPkVUL |
82 |
06RA6qjIhmAooWo3x5lcBjpGUsVkiPk15sF3E0t1qyjp78eiOq8cZBMRYxnhUVN+ |
83 |
AtQlESyzVmYjaCI557fsPr6sZasD69U9luZM6UUToeDSoK7O81s99MilhqUGpKA= |
84 |
=vPSH |
85 |
-----END PGP SIGNATURE----- |