Summary: | add a RESTRICT=distcc option | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Aniruddha Shankar <k> |
Component: | Current packages | Assignee: | PMS/EAPI <pms> |
Status: | RESOLVED WONTFIX | ||
Severity: | enhancement | CC: | bberberov+gentoo, gengor, lisa, pacho, Rob_Davies |
Priority: | High | ||
Version: | 1.4 | ||
Hardware: | x86 | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=669978 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Aniruddha Shankar
2003-09-09 14:47:58 UTC
TYPO: please amend last para of bug description to state Additionally, when a distcc compile of a package fails, portage should ask the user whether it should try compiling without distcc. If the non-distcc compile succeeds, portage should ask the user whether it should update DISTCC-FRAGILE with the name of the package. This is a very good idea. This is a portage thing, not a distcc thing, though. I think the idea can be refined to packages that fail with parallel makes (like xfree and mozilla). Maybe something in an .ebuild: RESTRICT="distcc" That can be built upon to change gcc compilers on the fly: RESTRICT="gcc-2.95 -distcc" your bugs are unrelated i believe ... Lisa: Why do you say it's not a distcc bug but a portage bug ? When distcc was used to compile the programs, it didn't succeed. When it wasn't, it did. *slightly bewildered* some packages cant compile in parallel, thats a simple fact distcc is a parallel compiler that needs to be restricted in the same way we restrict emake/make Its a request for an improvement in Portage, not distcc. Lisa: Correct. Just colour me slow today :) The idea to query the user could cause problems, I think it's better for the emerge to 'cleanly' fail or recover, and if an ebuild cannot support -jN, or distcc, it ought to do the RESTRICT, and have bug filed if it requires human intervention. One reason (apart from it being inconsistent with UNIX CLI philosophy), it'd be a bad idea for emerge to hang around waiting for user input, is that portage doesn't support simultaneous usage (least did not earlier this year). Portage could be corrupted if an emerge is stopped or restarted when that window is found hours later, and another emerge was already started. Also it's bit pointless questioning the user, if re-trying is an acceptable solution. I'm sure yesterday when I set up distcc feature, but had not config-ed distcc portage printed a warning and continued build without distcc. It makes sense for a host with puny CPU, used say as a firewall, to pass off all compilation to another machine, even if it cannot parellise. So better for RESTRICT to make distinct : parallel-make remote-compile It seems possible to me, than an alternative to distcc may arise someday. If a bug report comes in "ebuild failed with distcc", then RESTRICT=distcc likely to be a 'no brainer', when in fact the culprit is really -jN or possibly really is the use of remote compilation (lisa is their info on possible causes of failure I can look at?). Rob: An excellent point. What we have to consider is whether there would be any situations where a user would not want the compile to be run locally ... (embedded systems, gateways ? ). If this were the case, we could have a countdown-like display ..... Distributed compile failed, running compile locally in 5..4..3..2..1.. like the unmerge command displays. Aniruddha Shankar New Delhi, India wrt comment 9, if you export DISTCC_FALLBACK='0', then a failed compilation will not be attempted locally. With this in mind you could do: DISTCC_FALLBACK='0' emake OK, so local compilation can be prevented, then it must basically already be done, to re-try distcc's locally, in at least some circumstances. Those example failures in the bugs mentioned, look like linking steps failing, rather than compilation failures. Builds like Xfree, which don't work in parallel, ought they to work if distcc used with -j1 forced? Ummmm... MAKEOPTS="${MAKEOPTS} -j1" And compilation via distcc shouldn't cause builds to fail. If it's distcc's fault, report it to them. No need to add extra things into portage that aren't needed. Please add RESTRICT="distcc" support to portage. True most distcc problems are really parallel building problems. However, there is a perfectly valid scenario for wanting to RESTRICT="distcc" in the case of kernel modules. *** Bug 235742 has been marked as a duplicate of this bug. *** packages with parallel build problems get bugs and marked with -j1. distcc happens to exacerbate the issue, but it doesnt make it a distcc bug. |