[Nix-dev] Re: Re: Re: udev 151

[Yury G. Kudryashov]

Tony White wrote:

> On 15 April 2010 18:59, Yury G. Kudryashov <urkud+nix at ya.ru> wrote:
>> Hi!
>>
>> First of all, I talked upstream, and they don't want to search in
>> getenv(something). OTOH, they will accept a patch that will add
>> configure- time option "--with-firmware-path".
>>
>> My proposal:
>> 1. write this patch (will do).
>> 2. set --with-firmware-path=/var/lib/udev/firmware
>> 3. nix system expression creates /nix/store/hash-firmware with all needed
>> firmware files.
>> 4. udev job creates symlinks /nix/store/hash-firmware into
>> /var/lib/udev/firmware.
>>
>>
> Hi all,
> Sigh.
>> Do you want to write a patch and maintain it forever?
> No. I would kindly like to request that you maintain the current
> functionality if at all possible.
This was possible only because it was simple to patch old firmware.sh to add 
this functionality. This was never supported upstream.
>> If you need some impure path, we can add ONE standard impure path
>> (/root/test-firmware or /lib/firmware) to --with-firmware-path argument.
>> Note that adding another argument will require full rebuild of all
>> packages that depend on udev (for example, xorgserver).
> There you go. You've answered the question and my concern.
> Also, so what if it issues a rebuild. It is a big change, it's
> upstream's "fault" If anything and you have volunteered to do the work
> that will smash the bug that they have created when they have chose to
> ignore the good programming practice of using pure paths.
They were never use "pure" paths. And now they're ready to use pure path. 
They just want to hardcode them at build time. We can use /roote/test-
firmware:/var/lib/udev/firmware and symlink /var/lib/udev/firmware to 
/nix/store/hash-firmware at job start.

> At least they are willing to take a patch, many wouldn't and the
> "maintain it forever" Nonsense could still have happened (Maybe.) They
> still have to accept your patch and you still have to write it but I
> do have every confidence that you can make it work.
It is already written. I will fix a few typos in the patch, and they'll 
accept it.

> The low level stuff that is replacing hal is going to be need to be
> added to NixOS by someone in the future if we would like to use
> xserver 1.8 (Something called upower and udisk or something) And that
> will definitely trigger a big rebuild.
I have some ideas wrt xserver 1.8. Will write them later. It is not ready 
yet.
> So why not two paths, if possible, it goes in stdenv updates and gets
> merged when everyone is fully aware that a big rebuild will take
> place, so then there isn't a problem with it causing a fuss.
When udev-152 will be out with my patches, I'll add it as udev152.
> Have I missed something or is stenv updates not being used for exactly
> that purpose?