[Nix-dev] Patching uname in stdenv?

[Michael Raskin]

>On 08/17/2011 06:20 AM, Lluís Batlle i Rossell wrote:
>> On Wed, Aug 17, 2011 at 12:59:22PM +0400, Michael Raskin wrote:
>>> <E1QtaFh-0003G2-00.7c6f434c-mail-ru at smtp4.mail.ru>)
>>> Mime-Version: 1.0
>>> Content-type: text/plain; charset="UTF-8"
>>>
>>>>>> What would people think of a patch that made stdenv's uname return the
>>>>>> same value on every linux? I've only just had the idea and haven't had
>>>>>> time to think through the possible downsides, but my initial thought is
>>>>>> that most packages shouldn't need to know the kernel version, and that
>>>>>> those that have a reason to (e.g. packages that provide kernel modules)
>>>>>> should be dependent on the kernel passed to the nix expression, rather
>>>>>> than whatever the kernel happens to be in memory at a given time. Or am I
>>>>>> wrong? Is there a reason a build should depend on which version of the
>>>>> I guess default uname should say version of kernel from kernelheaders
>>>>> used for glibc, and kernelPackages one should say the kernel version
>>>>> of the passed kernel?
>>>> I'd like a list of the problems this would solve.
>>> General idea is to forcibly remove one more impurity.
>>>
>>> FF6.0 release manages to trigger it.
>> Is this impurity affecting the behaviour of FF6.0? If it is, I think they are
>> doing something wrong. If they care about the API, they should check the kernel
>> headers version.h, and not uname.
>>
>> Or is it simply storing what kernel was it running at build time, and you care
>> on getting always the same 'hash' on the result directory?
>In the FF6.0 case, the build actually fails. While I'd like to get the 
>same hash on the result directory every time (I've been thinking of 
>starting a "stdenv-pure" branch to root out as many impurities as 
>possible), there are definitely noticeable changes in some packages 
>beyond just a hash.

Technically, it fails even without it. But in a significantly different
way.