[Nix-dev] Patching uname in stdenv?

[Shea Levy]

On 08/17/2011 10:59 AM, Michael Raskin wrote:
>> 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.
>
>
>
Fair enough. FF5.0 builds fine on 2.6.x but fails on 3.x, then.