tis 2009-11-03 klockan 16:48 +0100 skrev Patrick Lauer:
> Hi there,
> 
> All of these bugs were for the use of the FEATURES variable in ebuilds, which 
> is a very convenient thing to work around issues. 
> For example known failures with FEATURE="distcc" or funky things like test 
> failures with FEATURES="userpriv" and so on. All other methods of expressing 
> that are much more verbose and inherently sucky.

I ask myself if what we really want is many different and strange
approaches to handle FEATURES?
Would it not be better to actually expand some eclasses to be able to
say something about your build environment?
I mean where the checks for "userpriv" is needed also prefix will fail,
because AFAIK it can be used to build and install programs in an
non-root environment? Or if you just test an ebuild and runs it as your
user? So would it not just be better to have a check for which privs the
user has so it covers more fields?
For "ccache" and for "distcc" would it not be better to expand
toolchain-funcs so you can have a function like "tc-getCC" from which
you can get that sort of information?

Also if the ebuilds does not already have a comment about it, do not
forget to comment on why these checks are there, and why they are a must
(i.e. a broken buildsystem should be fixed, not worked around - while
tests that are designed to run as root should not be run as a user even
if in the best of worlds all testsuits should test and skip those tests
themselves).
I would not like to see a new kind of hell where when something is
broken it is not fixed properly, but in a strange ways worked around in
ways that does not always work.
qemu and kvm is good examples on how NOT to do this these with regards
to hardened.

qemu (which kvm apparently has used as a template) has a broken build
system (it does not link with CFLAGS, only LDFLAGS, which is something
that also the gcc devs say you should not if you want a predictable
result), and it also invokes filter-flags at the wrong place in the
ebuild (hint: int should be invoked before the command that sets the
CFLAGS, in this case ./configure and not after like in these ebuilds).
Instead it has some strange logic to unset/change the GCC_SPECS which if
it ever worked certainly does not anymore (bugs filed for both, qemu bug
is really old, but very noisy, bug for kvm has been open for about an
week which the qemu maintainer may want to check out, with a clean patch
of one added sed a move of filter-flags and the removal of the whole
src_compile block to make the ebuild install something which (in case of
qemu) actually build, and does not segfault as soon as it uses a bit
softmmu).