[gentoo-dev] Re: [PMS] Add RESTRICT="distcc" capability

[Steve Long <slong@rathaus.eclipse.co.uk>]

Ciaran McCreesh wrote:

> On Sun, 2 Nov 2008 12:11:10 -0700
> Gordon Malm <gengor@gentoo.org> wrote:
>> > Have you conclusively established that they do build fine in
>> > parallel? If so, how?

>> Yes it builds in parallel.  By compiling it in parallel.

> If you think compiling it in parallel confirms that it builds in
> parallel, you're reaffirming my growing suspicion that you're entirely
> wrong about distcc being responsible for anything other than hardened
> brokenness...
>
Well my understanding of parallel make is that it would show some issues but
not all. I'd hope you were trying to say: "Build it via distcc with N
virtual hosts" or sth along those lines.
 
>> > RESTRICT=distcc on kernel modules is unnecessary for the large
>> > proportion of users who don't use hardened. RESTRICTs can't be set
>> > dependent upon whether or not something like hardenened is enabled;
>> > other mechanisms are available that can be. So why aren't you
>> > considering those other mechanisms?
>> 
>> I agree with the first sentence, never said otherwise.  Who says I am
>> not considering them?  In fact, I have stated that I am.
More why hasn't he proposed them already.

>> They are 
>> just more hackish than adding the ability to RESTRICT distcc, hence
>> my reason for soliciting such a feature.  I'm surprised that you'd
>> suggest this after debasing a RESTRICT option on the same grounds.
> 
> And that brings us to the other thing you don't understand: RESTRICT is
> a global, system independent, invariant metadata key. Things in
> RESTRICT are in RESTRICT because they have to be known in situations
> where those constraints are in effect.
"those constraint are in effect" isn't a good way of explaining that imo.

> Things that do not have to be 
> known at the metadata level shouldn't be in metadata.
>
Yeah, stuff that always applies, no matter what.
 
>> Sorry to everyone who e-mailed me who thought RESTRICT=distcc would
>> be somewhat useful.
Well a user could always turn off FEATURES externally, which isn't hard to
automate[2]; developers are notoriously bad at defining use-cases.

> 
> Those people are mistaken.
> 
>> > Uh, that's your answer to technical objections to a proposal? You
>> > aren't prepared to defend your proposal on its merits?

I think those two bits go nicely together.

It's not supposed to be a fight, btw.
>> 
>> Why are you assuming this point is *at all* related to my proposal?
>> It's not. It's about Gentoo.  But I stand corrected, a bunch of
>> people rushed to tell me you don't actually determine anything. ;)
> 
> So you don't care about whether your solution is right?
>
*sigh*
 
> You are proposing to add a metadata invariant option for a condition
> that isn't metadata invariant and that, by being made metadata
> invariant, means it's being disabled for everyone rather than by the
> small number of users who might need it. In addition, you can't
> demonstrate any cases where this option is genuinely useful, other than
> as a workaround for a hardened bug that you haven't contacted upstream
> about, and when used to work around said hardened bug the scope of the
> change isn't limited to hardened.
>
I agree this case isn't the best one, nor am I in favour of this RESTRICT.
I'm totally neutral on it as a solution. I can envisage wanting to restrict
compilation to the local machine, but I'm not bothered about how it gets
done. My instinct would be to err toward giving the control to the ebuild
maintainer, with a clear QA policy, perhaps around making it something that
had to be reviewed on every bump (QA script to watch ebuild as long it has
the RESTRICT, unless it's proprietary.)

Much as we might want perfect builds, they don't always happen, nor do we
always have time to fix upstream bugs, however minor they turn out to be.

> You still haven't explained why you don't do something like:
> 
>     broken_hardened_compiler && export DISTCC_HOSTS=localhost
> 
Still it would have been easier on the reader if you'd just mentioned this
first.

[1] http://hardened.gentooexperimental.org/trac/secure/
[2] http://forums.gentoo.org/viewtopic-t-546828.html