[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#32167: Kernel 'build' directory in the store is a broken symbolic li
Mark H Weaver
bug#32167: Kernel 'build' directory in the store is a broken symbolic link
Mon, 16 Jul 2018 18:03:58 -0400
Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
Danny Milosavljevic <address@hidden> writes:
> On Mon, 16 Jul 2018 18:55:11 +0100 (BST)
> <address@hidden> wrote:
>> It would be good to keep the build directory though, since it's
>> expected to exist, and it's easier to just download a module's
>> source and compile it and test it.
> I agree.
> /run/booted-system/kernel/lib/modules/4.17.3-gnu is in the store
> anyway so it will be seen by the GC.
> The fix would be in linux-libre.
If we were to preserve the kernel build directory as a store item, and
keep a link from the modules directory to the build directory, that
would greatly increase the size of the most minimal system that users
The unpacked linux-libre-4.17 source directory is 929 megabytes, and
that's before building it. So, keeping the build directory would surely
increase the closure size of the most minimal system by more than a
gigabyte. I don't think it's okay to force all Guix users to pay that
price. Some users will need to build minimal systems.
I'd like to hear more specifics about what the original poster is trying
to accomplish here. It's possible that they simply noticed the broken
links and wanted to let us know. In that case, it's probably best to
simply delete those broken symlinks.
If the intent here is to allow support for out-of-tree kernel modules,
then fixing these symlinks would not solve the problem, and it's not
clear to me that fixing them would be part of a proper solution on
GuixSD. GuixSD is not a system where you can simply compile a kernel
module manually and install it, because our module directory is
immutable. If the goal is to support building out-of-tree kernel
modules, that's a separate discussion that deserves its own "wishlist"
bug report, I think.