1 |
Mick wrote: |
2 |
> On Friday, 25 October 2019 18:01:57 BST Dale wrote: |
3 |
>> Mick wrote: |
4 |
>>> PS. In an ideal AI world, portage would know how much memory is necessary |
5 |
>>> for a given package and would auto-adjust the number of jobs to minimise |
6 |
>>> swapping given any amount of RAM. In an even more ideal world, it would |
7 |
>>> be able to do this in real time. :-) |
8 |
>> I agree that it would be nice if emerge could do that automatically, |
9 |
>> although I have no clue how to do that or even if it can be done at |
10 |
>> all. Back when I had less memory, I could let FF, LOo or another |
11 |
>> package run at full speed but only if it was only one of those packages |
12 |
>> at a time. Thing is, on occasion two or more of those updates would hit |
13 |
>> and due to the long compile times, end up compiling at the same time. |
14 |
>> Do you think there is a way for the devs to set up a method to tell |
15 |
>> emerge not to emerge certain packages at the same time? In other words, |
16 |
>> if Firefox is emerging, LOo is held until it is done or vice versa. |
17 |
>> Maybe even have it so others can be listed. The list of large packages |
18 |
>> are likely small but they can have a huge impact on systems with less |
19 |
>> memory. |
20 |
>> |
21 |
>> You think that a feature worth asking the devs about? Maybe they can |
22 |
>> figure out a way to implement that?? |
23 |
>> |
24 |
>> Dale |
25 |
>> |
26 |
>> :-) :-) |
27 |
> Well, ebuilds with known large compiles have specific tests at present, e.g. |
28 |
> chromium, FF, et al., run checks on available disk space for /var/tmp/portage |
29 |
> and warn the user accordingly. In firefox-70.0.ebuild we see this: |
30 |
> |
31 |
> ... |
32 |
> pkg_pretend() { |
33 |
> # Ensure we have enough disk space to compile |
34 |
> if use pgo || use lto || use debug || use test ; then |
35 |
> CHECKREQS_DISK_BUILD="8G" |
36 |
> else |
37 |
> CHECKREQS_DISK_BUILD="4G" |
38 |
> fi |
39 |
> |
40 |
> check-reqs_pkg_setup |
41 |
> } |
42 |
> |
43 |
> I guess a lot can be included in such checks, but I have no idea how to do it, |
44 |
> or how complicated an ebuild would get as a result. The problem with RAM |
45 |
> usage is that it changes continuously. You open a browser, or some large PDF, |
46 |
> or LO and more RAM is being used, just at the moment an ebuild decides to run |
47 |
> a check on available RAM. It can't guess if you will shut down your |
48 |
> applications and log out of your desktop the next moment to free up more |
49 |
> memory, if you will shut down web servers, databases or whatever else you may |
50 |
> be running in the background and drop to a console. For this reason I assume |
51 |
> such a measure won't be implemented in rush and even if it did, it would annoy |
52 |
> people, especially if they are asked to add USE="I-really-know-what-I-am- |
53 |
> doing" to allow the compile to start. |
54 |
|
55 |
|
56 |
I was hoping for something more simple. Nothing in the ebuild just a |
57 |
list of packages that emerge won't run at the same time. Let's say the |
58 |
big ones are included in the list, Seamonkey, Firefox, LOo and maybe a |
59 |
couple others. When emerge is run, Firefox and LOo is to be updated. |
60 |
Emerge itself knows not to update both so if one is updating and the |
61 |
other is next in line, then it waits until the other is finished before |
62 |
starting the next big one. I would think the code should be in emerge |
63 |
itself not the ebuild. That way the user can determine what their |
64 |
particular machine can handle. |
65 |
|
66 |
Like you, I'm not sure how to code that. Of course, I've read about the |
67 |
devs doing some complicated things that I don't grasp. After all, it |
68 |
calculates dependencies a lot faster than I could do on paper. lol |
69 |
|
70 |
Dale |
71 |
|
72 |
:-) :-) |