[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...

[Yury G. Kudryashov]

Shea Levy wrote:

> 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),
This would be easily catched by hydra.
> and we shouldn't help them by having /usr/bin in NixOS.
It seems that my goal is to reduce the divergence from upstream and/or 
mainstream distros, while you're counting on probability of buggy packaging.

I need a timeout... I'll answer tomorrow.
-- 
Yury G. Kudryashov,
mailto: urkud at mccme.ru