| 1 |
On Tue, Dec 3, 2019 at 3:46 PM Neil Bothwick <neil@××××××××××.uk> wrote: |
| 2 |
|
| 3 |
> On Tue, 3 Dec 2019 10:43:36 -0500, John Blinka wrote: |
| 4 |
> |
| 5 |
> > > > Couldn't you just have a script that "emerge --update"s each |
| 6 |
> > > > package in sequence? If the package isn't due for update nothing |
| 7 |
> > > > will happen. And then you could follow that with an "emerge world" |
| 8 |
> > > > knowing that your hogs are already done. |
| 9 |
> > > |
| 10 |
> > > Sometimes the packages are rebuilt without an update, especially if |
| 11 |
> > > you use --changed-use or --changed-deps, so it's not quite that |
| 12 |
> > > simple. |
| 13 |
> > |
| 14 |
> > |
| 15 |
> > But still pretty simple. I’ve just used the “build in sequence” idea |
| 16 |
> > for an update that forced a libreoffice rebuild. It first upgraded a |
| 17 |
> > few of libreoffice’s dependencies in parallel, and then rebuilt |
| 18 |
> > libreoffice by itself afterwards. A subsequent emerge @world upgraded a |
| 19 |
> > bunch of minor kde stuff. I like this idea - seems to isolate the |
| 20 |
> > “hogs” so they build one at a time, and it does so without any |
| 21 |
> > intervention on my part. Thanks! |
| 22 |
> |
| 23 |
> But if you emerge --update libreoffice before the package that is forcing |
| 24 |
> the rebuild, why would libreoffice rebuild? I would expect it to only |
| 25 |
> rebuild libreoffice after the dependency had been changed. |
| 26 |
|
| 27 |
|
| 28 |
That’s exactly what happened. I issued an emerge -DuNv —changed-deps |
| 29 |
libreoffice first. That had the effect of 1) first upgrading several |
| 30 |
libreoffice dependencies, and 2) subsequently rebuilding libreoffice once |
| 31 |
the dependencies changed. I’m guessing emerge is smart enough to trigger |
| 32 |
both activities and sequence them appropriately. Operative word is guess - |
| 33 |
I don’t pretend to understand the inner workings. |
| 34 |
|
| 35 |
> |
| 36 |
> I'm not saying out wouldn't work some of the time, but I can see |
| 37 |
> situations where it wouldn't. Whereas |
| 38 |
> |
| 39 |
> emerge --opts @world --exclude memory-hogs... |
| 40 |
> emerge --opts --jobs 1 @world |
| 41 |
> |
| 42 |
> should always isolate them. |
| 43 |
|
| 44 |
|
| 45 |
Agreed that this technique should always work. And it has the advantage of |
| 46 |
fewer invocations of emerge. But at the cost, I suspect, of serializing |
| 47 |
the building of any memory hog dependencies that were excluded from |
| 48 |
consideration by the first invocation of emerge. |
| 49 |
|
| 50 |
What situations do you see as not working? |
| 51 |
|
| 52 |
John Blinka |
Archives