2009/6/29 Marc Weber <[email protected]>: >> Hi Marc, >> How about moving upstream with it and being polite. :) > being polite ? What did you mean by saying this? > I hope my mail didn't appear impolite to anyone. > > The goal of this mail was not only this particular problem. > My intention was to gather a list of solutions we can reference to in > the future because this question will come up again and again. > It's fastest to point a newcomer to the mailinglist and say "read it up, > that's a collection of thoughts we already had". > > This is a nice topic which could be put on a wiki page which could be > called "known limitations of purity" or such ? > > Sincerly > Marc Weber > _______________________________________________ > nix-dev mailing list > [email protected] > https://mail.cs.uu.nl/mailman/listinfo/nix-dev >
Hi Marc, I wasn't saying anything in your mail was impolite, I was probably just being overly obvious by implying that being polite upstream is always the best way to make a request or report a problem, that's all. It gets results. But you know that. :) I've witnessed a few people that go upstream and say "It doesn't work. I want that, etc." Aggressively and it almost never works, for enhancements, etc and I'm not saying at all that you would do the same, it's just that I've seen so many aggressive bug reports, mentioning to be polite is something I am in the habit of doing. Just the other day, I went upstream about privoxy's configure.in not inspecting the $PATH for binaries it needs to find and within twenty four hours and I'd like to think that it was maybe because I was polite, one of the developers had released a patch. So when the next release is made, it will compile using nix without a problem. It's understanding the problem really, Isn't it? Like for instance with gmp; if the configure.guess script is setting aggressive flags, then maybe requesting a switch to set the flags manually or similar may solve the problem but there is still the issue about any other projects that adopt a similar method. As Eelco said, just a switch to turn off the aggressive or specific compiler optimizations would do it. :) Only you guys will know if the work load for creating a workaround in nix for the gmp problem is worthwhile and if it would be useful for other sources. My thoughts are that if they are using their own modifications to the regular configure scripts and their focus is on performance then they may change those scripts to do even more (Undesired in this case) Guesswork and optimizations as part of their development cycles, therefore rendering any workarounds or patches in nixpkgs in need of being maintained at every new upstream source code release. I'm unsure that a workaround for gmp would "Catch" Any other project's configure scripts that do something similar, I guess even if they did it, those sources that do would need to be checked every time they are compiled to see if the workaround missed something. Barring the obvious as in this case in which it just failed, so it was obvious. I hope that at least makes sense and maybe makes a small case for going upstream, especially when the problem is understood. If not, please disregard my message and I'm sorry if there was any confusion. No offense was intended. Kind regards, Tony _______________________________________________ nix-dev mailing list [email protected] https://mail.cs.uu.nl/mailman/listinfo/nix-dev
