Denis Dupeyron wrote: > Correct me if I'm wrong, but this has nothing to do with being > interactive or not. To me, an ebuild that dies (intentionally or due > to a build error) isn't interactive at all.
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. I'm personally for dying as soon as possible, like before the actual compiling starts, but I don't think that's possible yet. > 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. > Plus, if the > solution is considered good for python, I don't understand why it > wouldn't be good for any other package. Are you saying that Paul's > proposition of having the python ebuild die on use of --fast-math > isn't good ? Yes. If yes, why ? And what is your better idea ? I prefer a filter-flags with a ewarn (or elog, haven't read that thread yet ;)) message. * The -ffast-math option is known to break this package and has been filtered from your CFLAGS. Link to Safe CFLAGS wiki page, blah blah blah. I like this better because it informs me of what I did wrong, what was done to correct it, and how I can correct it for myself in the future if I choose to. I don't like artificial barriers and things not working without immediate attention. Call me lazy but it's annoying when you know what you're doing yet you have to jump through hoops to get it done. > Which is exactly the reason why we could benefit of something that > enables us to manage this in a clean and safe way. I'm not saying I > have a candidate for that "something", but I wanted to discuss if > there was an interest in it. > > Let's take again the example of -ftracer which can be enabled by the > -fprofile-use meta-flag. Imagine we have a mechanism somewhere (again, > the reason I'm being vague is that my point isn't to discuss > implementation just yet) that adds -fno-tracer to CFLAGS. In this > case, you're covered wether -ftracer was added directly on indirectly > by fprofile-use, which actually simplifies the number of flags that > you need to blacklist. Thus ebuilds don't have to take care of it, > bugs don't pour into bugzie, and Jakub can avoid overheating. 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. 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. >> Users playing with CFLAGS get to keep the pieces. Trying to >> dummy-proof the >> system doesn't help anyone but the dummies. ;) > > I'm one of those devs who care for our users. I think it's dangerous > to try and categorize users in, for example, dummies and non-dummies, > as you say. Who are we to judge this or that user is a dummy ? Plus, > we all are the dummy of somebody else. Okay, bad joke aside, there are always going to be users who tweak GCC flags. This has to be expected, as they're mysterious, and technical, and kinda cool. I like the tweaker crowd and I am a dummy, so no offense was intended to either groups. I meant that if you safety-proof a complex system, people never learn that they're doing anything wrong in the first place. > Anyway, I was thinking more in terms of making the job of developers, > bug wranglers, and poor old bugzilla easier, cleaner, safer. How many > bugs do we have that are due to dangerous flags ? Mad props to the bug-wranglers, but I don't think it'll be a cakewalk to automate this in any sane way. > How much time and > effort could we save if we didn't have those ? Also, I was thinking > that if a good solution was found to deal with a dangerous flag in a > certain package, maybe it was a good idea to extend this solution to > other packages. And finally, if said solution becomes common, maybe > it's a good idea to make it system-wide with a possibility to override > the setting by the user or the ebuild. It seems we already have > per-package CFLAGS, so part of this, at least, is already implemented. 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? I guess in the end it comes down to personal philosophies on how to handle this, and I'm not going to try to change anyone's opinions. I hope that when this does get implemented there's a relatively easy way to opt-out ;). --de.
signature.asc
Description: OpenPGP digital signature
