From: Peter Hjalmarsson <xake@rymdraket.net>
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev] Re: FEATURES use or misuse?
Date: Wed, 04 Nov 2009 23:12:05 +0100 [thread overview]
Message-ID: <1257372724.5846.26.camel@lillen.dodi> (raw)
In-Reply-To: <200911031648.04090.patrick@gentoo.org>
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).
next prev parent reply other threads:[~2009-11-04 22:12 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-03 15:48 [gentoo-dev] FEATURES use or misuse? Patrick Lauer
2009-11-03 17:27 ` Sebastian Pipping
2009-11-03 20:36 ` Patrick Lauer
2009-11-03 20:58 ` Ciaran McCreesh
2009-11-03 22:28 ` Patrick Lauer
2009-11-04 0:11 ` [gentoo-dev] " Ryan Hill
2009-11-04 8:26 ` Patrick Lauer
2009-11-05 1:36 ` Ryan Hill
2009-11-05 4:56 ` [gentoo-dev] a pragmatic approach to FEATURES [was FEATURES use or misuse?] Brian Harring
2009-11-05 8:49 ` Thilo Bangert
2009-11-05 9:36 ` Brian Harring
2009-11-08 9:21 ` Thilo Bangert
2009-11-03 21:26 ` [gentoo-dev] FEATURES use or misuse? Alexis Ballier
2009-11-03 22:04 ` Patrick Lauer
2009-11-03 22:26 ` Ciaran McCreesh
2009-11-04 0:33 ` Sebastian Pipping
2009-11-04 8:26 ` Patrick Lauer
2009-11-03 23:04 ` David Leverton
2009-11-04 1:31 ` [gentoo-dev] " Duncan
2009-11-04 22:12 ` Peter Hjalmarsson [this message]
2009-11-05 5:04 ` Brian Harring
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1257372724.5846.26.camel@lillen.dodi \
--to=xake@rymdraket.net \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox