1 |
tis 2009-11-03 klockan 16:48 +0100 skrev Patrick Lauer: |
2 |
> Hi there, |
3 |
> |
4 |
> All of these bugs were for the use of the FEATURES variable in ebuilds, which |
5 |
> is a very convenient thing to work around issues. |
6 |
> For example known failures with FEATURE="distcc" or funky things like test |
7 |
> failures with FEATURES="userpriv" and so on. All other methods of expressing |
8 |
> that are much more verbose and inherently sucky. |
9 |
|
10 |
I ask myself if what we really want is many different and strange |
11 |
approaches to handle FEATURES? |
12 |
Would it not be better to actually expand some eclasses to be able to |
13 |
say something about your build environment? |
14 |
I mean where the checks for "userpriv" is needed also prefix will fail, |
15 |
because AFAIK it can be used to build and install programs in an |
16 |
non-root environment? Or if you just test an ebuild and runs it as your |
17 |
user? So would it not just be better to have a check for which privs the |
18 |
user has so it covers more fields? |
19 |
For "ccache" and for "distcc" would it not be better to expand |
20 |
toolchain-funcs so you can have a function like "tc-getCC" from which |
21 |
you can get that sort of information? |
22 |
|
23 |
Also if the ebuilds does not already have a comment about it, do not |
24 |
forget to comment on why these checks are there, and why they are a must |
25 |
(i.e. a broken buildsystem should be fixed, not worked around - while |
26 |
tests that are designed to run as root should not be run as a user even |
27 |
if in the best of worlds all testsuits should test and skip those tests |
28 |
themselves). |
29 |
I would not like to see a new kind of hell where when something is |
30 |
broken it is not fixed properly, but in a strange ways worked around in |
31 |
ways that does not always work. |
32 |
qemu and kvm is good examples on how NOT to do this these with regards |
33 |
to hardened. |
34 |
|
35 |
qemu (which kvm apparently has used as a template) has a broken build |
36 |
system (it does not link with CFLAGS, only LDFLAGS, which is something |
37 |
that also the gcc devs say you should not if you want a predictable |
38 |
result), and it also invokes filter-flags at the wrong place in the |
39 |
ebuild (hint: int should be invoked before the command that sets the |
40 |
CFLAGS, in this case ./configure and not after like in these ebuilds). |
41 |
Instead it has some strange logic to unset/change the GCC_SPECS which if |
42 |
it ever worked certainly does not anymore (bugs filed for both, qemu bug |
43 |
is really old, but very noisy, bug for kvm has been open for about an |
44 |
week which the qemu maintainer may want to check out, with a clean patch |
45 |
of one added sed a move of filter-flags and the removal of the whole |
46 |
src_compile block to make the ebuild install something which (in case of |
47 |
qemu) actually build, and does not segfault as soon as it uses a bit |
48 |
softmmu). |