| 1 |
On Wed, 14 Apr 2010 08:46:15 +0200 Justin <jlec@g.o> wrote: |
| 2 |
|
| 3 |
> There is at least one other example which benefits from singlular |
| 4 |
> build, atlas libs. They run a benchmark suite to create platform |
| 5 |
> specific headers, which is heavily influenced by the system load. So |
| 6 |
> having RESTRICT=parallel would make the emerge more reliable. |
| 7 |
|
| 8 |
And that's another example of working around broken ideas. There is |
| 9 |
an uncountable number of possibilities of many different factors |
| 10 |
affecting the system load, and thus the results of the benchmark. |
| 11 |
Removing one of them would indeed help in many cases but in many other |
| 12 |
it wouldn't make any difference, additionally slowing down the whole |
| 13 |
system update process. |
| 14 |
|
| 15 |
Please notice that in order to implement that correctly, emerge would |
| 16 |
have to wait until all previously running emerges are done, and avoid |
| 17 |
running further ones while the build process is running. While |
| 18 |
in the case of xorg-server, the 'lock' is needed throughout the whole |
| 19 |
build process, in your case it is needed only for a short amount |
| 20 |
of time when the benchmark is being performed --- and the 'real' part |
| 21 |
of building would unnecessarily block emerge. |
| 22 |
|
| 23 |
If this is ever to be implemented, it totally needs to be |
| 24 |
user-overridable. Else, we'll end up someday like Windows, forcing user |
| 25 |
to reboot the system and perform the merge on a dedicated runlevel. |
| 26 |
|
| 27 |
-- |
| 28 |
Best regards, |
| 29 |
Michał Górny |
| 30 |
|
| 31 |
<http://mgorny.alt.pl> |
| 32 |
<xmpp:mgorny@××××××.ru> |
Archives