Resuming emerge

[rzdndr]

Hello,

I have read some articles about resuming an emerge that was stopped with (Ctrl+C). But none worked.

I am installing a package, and Ctrl+C'd it to continue later. When I logged into the system and have done emerge --resume, it started with some other package. Since after a Ctrl+C, the object files (or whatever files are generated during a build) would not be deleted, wouldn't it be simple for emerge to restart where it left off? I thought that will be the case with emerge --resume.

What is the best way to resume an emerge when the emerge is stopped to continue later?

Regards

[szatox]

Emerge --resume picks up the last job plan and continues from where it left of.
It makes sure to start each task from a clean state though, so it will not continue an interrupted compilation.

If you want to continue working on a particular task (e.g. manually patch a bug which breaks your build), you can do that with a lower-level interface: ebuild
Ebuild knows the correct order of actions during build process and is smart enough to know which steps have been already completed, so you can just call ebuild merge <path to ebuild> and it will unpack sources, prepare them, patch, build and whatever else I missed, all in one go.
Once this is done, you might try running emerge --resume --skipfirst to remove that item from the list before continuing.
_________________
Make Computing Fun Again

[rzdndr]

[szatox]

Honestly I never tried that, but it should work.
A lot of the work compilers do can be (and is) cached on disk and big programs are made of many files that can be processed independently.

Which BTW reminds me about ccache some people use to speed up rebuilds. It could also be a good way for you to escape the need for manual intervention with ebuild.
_________________
Make Computing Fun Again

[logrusx]

[rzdndr]

[rzdndr]

[logrusx]

[szatox]

Huh... Looks l confused this one with keeptemp.
Well, keepwork might actually do the trick, though not deleting workdir after merge implies polluting your tmp with potentially big amount of data. There are a few common packages which check for 6-10GB of free space in tmp before even attempting to compile.

[logrusx]

[rzdndr]

[szatox]

No, you just don't keep this feature enabled. Cleaning up after a job is the default behavior
_________________
Make Computing Fun Again

[rzdndr]

[rzdndr]

[szatox]

[rzdndr]

[Hu]

The idea of interrupting and resuming emerge comes up every few months, and the answer is always the same. This may work in some cases, but cannot work in the general case. If you interrupt a build step that does not know how to resume itself correctly, then when you do resume, you may get incorrect results. Consider the following:

[rzdndr]

[rzdndr]

[logrusx]

[Hu]

True, you found a flaw in an example I wrote to make the point. Rerunning make will regenerate c, and as a side effect, d. This is because GNU make is generally good at dependency management, and I failed to create a sufficiently pathological example to counter it. I've seen build systems that are just shell scripts, sometimes without any error checking. Such a script might notice the existence of d and decline to rebuild c, without verifying the mtime or contents of any of the files.

Therefore, next, you need to prove that for all possible build systems, it is impossible to interrupt them at any point where a subsequent restart will produce an incorrect result, whether that result is a missing file, an incomplete file, or any other result that would not occur if you let it run to completion.

[rzdndr]

[eschwartz]

[eschwartz]

I would argue that in fact the *real* reason why portage cannot guarantee that a package with an existing workdir can be resumed in the middle of an ebuild phase, is because portage cannot guarantee that ebuild files are, fundamentally, resumable at all. Many ebuilds perform destructive actions such as moving a file in src_install instead of copying it, which is arguably good for speed and for avoiding running out of space on the disk containing the portage tmpdir, but pretty terrible for re-running the install phase.

This is not the fault of the build system, since the build system does in fact work fine -- it is simply a choice by ebuild authors. IIRC the kernel is one of those ebuilds (eclasses, rather)

[Hu]

I picked Make because I was in a hurry and thought I could quickly write a bad build system in it that would demonstrate my point about not being able to reliably resume. I was wrong. I wrote something that was insufficiently tricky, because I did not leave out enough dependency information to confuse it while still including enough to guarantee that a non-interrupted run would work.