[Nix-dev] Re: libgmp impurity

[Tony White]

2009/6/29 Marc Weber <marco-oweber at gmx.de>:
>> 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
> nix-dev at cs.uu.nl
> 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