On 7/11/06, Ryan Hill <[EMAIL PROTECTED]> wrote:
Their phrase, not mine. ;)  I think the idea is you should be able to emerge -e
world and walk away and not have anything interrupt the process thus requiring
the user interact with the system.

Well yes, but an ebuild that dies, whatever the reason, hasn't much to
do with interactivity.

> If a package is known not to work with a certain flag, being able to
> emerge it won't change the fact that it doesn't run.

If a package is known to not work with a certain flag it should be filtered so
it does run.

What will follow isn't only for you. You guys are focusing on the
die/filter alternative. Maybe you haven't noticed but I have never
stated that I'd prefer ebuilds to die or filter. What I wanted to
discuss is can't we do something globally to avoid these bugs coming
in, so that we can focus on something else. I don't care yet if it's
filtering or dying. And never did I talk about educating the masses.

Do you mean for ebuilds that knowingly break with -ftracer, or for everything?
There are packages that expect to be built with certain flags;  not -ftracer,
but others.  Fex, libao needs -ffast-math ;).  Also, what about ebuilds that do
use -fprofile, like gcc itself?  I know toolchain.eclass strips all flags, I'm
just using it as an example.

I explained I was talking about a global system, with a possibility
for ebuilds/users that wanted/needed it to opt out. It's much easier
to "unblock" --fast-math for libao than going through idontknowhowmany
bugs about the same number of packages that break with --fast-math,
for example.

If you mean just for packages that break with certain flags then absolutely.
But such a mechanism would have to be maintained for every different GCC
version, since -fprofile might not invoke -ftracer in every version, and indeed
some versions might not even recognize -fno-tracer and bail with an error.

Let's count together the number of GCC versions we should really care
about. 3.4, 4.1, any others ?

Mad props to the bug-wranglers, but I don't think it'll be a cakewalk to
automate this in any sane way.

Automate what ?

Right, but how are people supposed to learn something is dangerous if all the
sharp edges have been filed off?  And how can you decide which flags are "bad"
and "good" on a global level when for the most part compiler parameters are akin
to black magic?

Since when is being a learning tool one of the goals of Gentoo ?

gentoo-dev@gentoo.org mailing list

Reply via email to