Hi Grant, On 3/3/06, Grant Goodyear <[EMAIL PROTECTED]> wrote: > Yep. Having a USE flag enabled turns out not to be a guarantee. That > said, package builds do become deterministic, so (for example) if one > needs to know if msmtp was built with openssl or gnutls it is easy > enough to pull the logic from the msmtp ebuild.
If a build process has errors, it should stop. That's still deterministic. I'd respectfully argue that it's far more deterministic than having each single package implement separate policy for handling conflicting USE flags. Policy belongs with the user, not in Portage. It's exactly the same as the kernel pushing policy into userspace. I believe that it's bad engineering to force (using your example) packages that depend on msmtp to have to copy the logic from the msmtp ebuild to understand how to correctly depend on that package. It violates the principle of Don't Repeat Yourself. If we're going to do this, then at least we should be implementing a consistent standard across all ebuilds. F.ex, when SSL and TLS conflict, we should have a standard saying that all ebuilds will consistenly favour one over the other. That's much more deterministic than having some ebuilds prefer SSL, and others prefer TLS (for example). > I'm sure that there is > a more elegant solution, but I'm not convinced that having the user > randomly throw USE flags at a package until some combination works is > necessarily it. I could be wrong, however. *Shrug* Why would the user be randomly throwing USE flags at a package? With the PHP ebuilds and the confutils eclass, we've already proved that you can tell the user exactly why the ebuild has bailed, and what they can do to fix it. > With an apology for singling you out (when yours is certainly not the > only, or even the most appropriate, example), that sort of emotional > response is how these threads begin to degenerate. There appears to be > an implicit assumption there that your view is clearly correct, and any > other is embarrassingly silly. Instead, I suggest that perhaps people > on both (all?) sides of the issue are rational, intelligent people who > simply differ on what happens to be the greatest evil. I accept the point, but, well, I *am* embarrassed. I guess I'm just willing to admit it when others would rather not be open and honest about how this makes them feel. I think it's fair to raise that as part of the debate. I don't think we talk enough about how we feel about what's happening to Gentoo these days. I think it's reasonable that issues like this are delt with both on an emotional intelligence level as well as an intellectual one. > I would argue that the user tends to get unexpected results in either > case, it's just a matter of whether the build crashes, or the resulting > package is somewhat unexpected. Given that fact, I'm arguing that > having a potentially-lengthy emerge crash out is the bigger evil. I can understand how that matters to first-time installs, or users running old hardware. My environment and concern are servers, where dual-Xeon or dual-Opterons are the norm. The time it takes to install a package is trivial against the time it takes to diagnose why it isn't working the way you would expect. Best regards, Stu -- [email protected] mailing list
