[Nix-dev] Patching uname in stdenv?

[Shea Levy]

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.