| 1 |
On Saturday, November 1, 2008 15:11:16 Ciaran McCreesh wrote: |
| 2 |
> On Sat, 1 Nov 2008 14:58:39 -0700 |
| 3 |
> |
| 4 |
> Gordon Malm <gengor@g.o> wrote: |
| 5 |
> > I use madwifi-ng extensively and have experienced the same issue with |
| 6 |
> > madwifi-ng as stated in that bug. For bug #167844, please read |
| 7 |
> > comment #13 and http://code.google.com/p/distcc/issues/detail?id=25. |
| 8 |
> > There's nothing to fix, hardened is doing the right thing as is |
| 9 |
> > distcc. The proper approach is to not distribute compiles of kernel |
| 10 |
> > modules. |
| 11 |
> |
| 12 |
> It looks to me like hardened is doing entirely the wrong thing. Thus, |
| 13 |
> the proper fix is to make hardened behave itself. |
| 14 |
|
| 15 |
It looks to me like you've already made up your mind. How is hardened doing |
| 16 |
the entirely wrong thing? What do you propose can be done to "fix" the |
| 17 |
hardened compiler? What about madwifi-ng? You are getting increasingly |
| 18 |
narrow in your points of objection. |
| 19 |
|
| 20 |
> |
| 21 |
> > To not get too stuck on a single scenario, I think this would be a |
| 22 |
> > useful feature and desireable vs. the alternative of |
| 23 |
> > FEATURES=${FEATURES/distcc/}. |
| 24 |
> > |
| 25 |
> > This is not the first time its been requested, a simple search |
| 26 |
> > reveals bugs #28300, #80894. |
| 27 |
> |
| 28 |
> It looks a lot like people are blaming distcc for parallelisation bugs |
| 29 |
> that aren't distcc related but that happen to be easier to reproduce |
| 30 |
> when distcc is enabled. Do you have any examples of problems that are |
| 31 |
> definitely caused by distcc, rather than general parallelisation bugs |
| 32 |
> or user misconfigurations? RESTRICTing distcc doesn't seem to be an |
| 33 |
> actual fix for anything... |
| 34 |
|
| 35 |
As I said in my first post: |
| 36 |
|
| 37 |
'It is true that RESTRICT="distcc" is usually not the proper solution to |
| 38 |
problems.' |
| 39 |
|
| 40 |
Parallel building problems can often and should be addressed properly. I |
| 41 |
don't want the answer to every one that comes along to be to add |
| 42 |
RESTRICT="distcc". This is something to be addressed through developer |
| 43 |
documentation that using RESTRICT="distcc" should be a last resort. |
| 44 |
|
| 45 |
However, in practice making a package parallel-make safe isn't always trivial. |
| 46 |
So what happens in these cases is FEATURES=distcc && die check is put in |
| 47 |
place killing the emerge chain and requiring user intervention. Either that |
| 48 |
or the bug just lingers and the compile fails somewhere in the middle... |
| 49 |
|
| 50 |
I don't know about palaudis but this is like a one line patch to portage. But |
| 51 |
silly me, I thought the package manager was there to support the |
| 52 |
distribution. |
| 53 |
|
| 54 |
Gordon Malm (gengor) |
Archives