[Nix-dev] [Nix-commits] SVN commit: nix - r33428 - in nixpkgs/branches/kmod-MODULE_DIR/pkgs: applications/virtualization/virtualbox applications/virtualization/virtualbox/guest-additions build-support/kernel os-specific/l...

[Shea Levy]

On 03/26/2012 12:01 PM, Yury G. Kudryashov wrote:
> Shea Levy wrote:
>
>> On 03/26/2012 11:49 AM, Yury G. Kudryashov wrote:
>>> Shea Levy wrote:
>>>
>>>> On 03/26/2012 11:28 AM, Yury G. Kudryashov wrote:
>>>>> Shea Levy wrote:
>>>>>
>>>>>> On 03/26/2012 11:15 AM, Yury G. Kudryashov wrote:
>>>>>>> We'll maintain /lib/modules/modversion symlink instead. This way both
>>>>>>> module-init-tools and libkmod will work without patches.
>>>>>> I really don't like this approach. Given that the kmod tools accept a
>>>>>> --dirname=DIR option that allows you to point to the modules
>>>>>> directory, why add this additional impurity?
>>>>> This way we're closer to what upstream supports.
>>>> Upstream supports --dirname=DIR for modprobe. We don't even need a patch
>>>> for this.
>>>>
>>>>> Why do you consider this to be an impurity? You can't have two kernels
>>>>> running at the same time anyway. And if you want to load a module from
>>>>> another directory, use `-d` or `insmod`.
>>>> Because a package might search /lib/modules during install for some
>>>> reason. Many kernelPackages do so (and need to be patched to fix this),
>>>> and if there were a /lib/modules symlink then you'd have problems
>>>> building a kernelPackage for a kernel that's not the currently running
>>>> one.
>>> There is no /lib/modules symlink. There are /lib/modules/modDirVersion
>>> symlinks. And these symlinks are invisible in build chroot. If you build
>>> without chroot, you'll have problems on non-NixOS systems anyway.
>> Chroot builds are not the default,
> (offtopic: why not make them default?)
>> and you don't usually need to build
>> kernelPackages on non-NixOS. If I'm on linuxPackages_3_2 and I want to
>> nixos-rebuild to 3_3, I don't want to have to worry about my newly-built
>> kernelPackages accidentally referencing 3_2 still.
> I think that every bug should be solved by patching buggy software. In this
> case, buggy kernelPackages.* buildsystem. BTW, could you provide any
> example, please? The logic you've described should be considered a bug in
> any distro, not only NixOS.

Sure, I agree. Similarly, I think packages assuming dependencies in 
/usr/bin and /usr/lib should be considered a bug. Still, such buggy 
packages do exist (see makefile.patch for broadcom-sta for an example), 
and we shouldn't help them by having /usr/bin in NixOS.

>
>>>>> Eelco Dolstra wrote:
>>>>>> I dislike introducing a /lib/modules.  What was wrong with using an
>>>>>> environment variable to point at the modules tree?
>>>>> E.g., next udev version relies on libkmod (not `modprobe`) to load
>>>>> modules. This way we can switch a symlink on nixos-rebuild switch. Any
>>>>> ideas how to do it with env var?
>>>> Patch udev to call kmod_new with the appropriate directory, or patch
>>>> libkmod to respect the env var.
>>> How do you want to *change* udev's env var on the fly when you do nixos-
>>> rebuild switch?
>> Why would we want to change udev's env var on the fly? We're not
>> changing the kernel on the fly...
> An example: add kernelPackages.myModule to the module list without changing
> the kernel. OK, this should not happen often.

Well, how do we handle this currently? If we don't restart udev, its 
current calls to modprobe won't pick up the new path either.