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