If package X is compiling and another emerge depends on X then the compile breaks. Examples: emerge xfree & (wait for until compile starts) emerge openoffice
Is this really a bug?
I come from Sorcery-linux. In Sorcery-linux you can install any packages simultaniously. If any of the packages depend on eachother they wait for the others to complete. If you have multiple CPU's you can decrease compile time if it is possible to install packages in parallel. You *can* install some packages in parallel today, but you cannot install any packages in parallel. You do not get any sensible error messages saying: You can/should not install packages in parallel. My definition of a bug: If a program does not do what I expect it to do, then it is a bug - especially if the program does not tell me what went wrong and what I can do to fix it. This is clearly a bug in my definition.
*** Bug 13359 has been marked as a duplicate of this bug. ***
It's not really a bug, but it's something portage should deal with. It's more like a feature request. I would disagree with Ole that it is a bug in that it's obvious to the half-sensible linux user that compiling 2 version of the same package concurrently will create problems. Just because you can do it doesn't mean it's a bug. For example, I can delete all of /etc with rm, but that's not a bug in rm, even though it will break my system. You do need to be able to run concurrent emerges, for example, where you are emerging a large package and you want to emerge a small package without interrupting the compilation of the larger package.
> I would disagree with Ole that it is a bug in that it's obvious to the > half-sensible linux user that compiling 2 version of the same package > concurrently will create problems. If you look at my initial report I was not compiling 2 versions of the same package. I was compiling xfree and openoffice (which happened to depend on xfree). If we can agree that it is not fair to assume that the half-sensible linux user knows the whole dependency graph for everything then then we should also agree that this behaviour is not good. In my example it may be obvious that both depend on xfree, but is it obvious to you that Python depends on xfree? As mentioned a solution (that is used in Sorcery) is to wait untill the first first compile is done. It is fairly simple and works great in Sorcery.
The comments about rm is quite unecessary. Because thats what rm is intended to do. emerge is intended to install packages. When it doesn't do that correctly, it's a bug. If it's an implementation bug or an documentation bug is another question.
*** Bug 14969 has been marked as a duplicate of this bug. ***
*** Bug 16115 has been marked as a duplicate of this bug. ***
would anybody object to the fix I suggested in bug #16115 ? One question tho, what should be the correct behaviour for depancies? I think that while an emerge depends on something that is still being merged, it should just delay those items.
I agree.
Seems like a good solution, robbat2.
In my view this is a feature request, but I do think that it is a necessary requirement for happy emerging. E.g. emerge -uf xfree at the same time as emerge -uf kde These will both start downloading xfree. If two appliactions download the same file to the same destination at once, the file becomes corrupt. The MD5 check fails, and the download starts again...thus deadlock, and both application continually re-download the same file forever. For this alone, we definitly need a locking machanism on a per portage package basis. With emerge doing all downloads before it compiles anything, and letting the download function skip a package if it is locked, and then come back to it after downloading other packages. If it is the last package, just print a message "Waiting for lock free" and then MD5 check it and download again if needed. It is a well know fact that downloading 2 files in parralel is much quicker than downloading the 2 files sequencially. So, in my view, this is a much needed feature. "package locking." and "download all before build"
*** Bug 49063 has been marked as a duplicate of this bug. ***
I am the poster of bug 49063, which was marked a duplicate of this bug. While my issue is with multiple emerges across a cluster of machines with a common portage dir, the locking issue remains the same here. I'm unclear why there is resistance to using file locks, whether over NFS or not. Two years is a long time for any bug to be unresolved. With respect to SpanKY's comment that file locking over nfs is a bad idea, a quick read of 'man open' will indicate: "The solution for performing atomic file locking using a lockfile is to create a unique file on the same fs (e.g., incorporating host-name and pid), use link(2) to make a link to the lockfile." -Jacob
This should be handled as of a stable release a few months ago.
