Re: HEADSUP: drm-current-kmod now installs sources

From: Theron <theron.tarigo_at_gmail.com>
Date: Wed, 14 Aug 2019 11:58:29 -0700
On 2019-08-14 11:04, Ian Lepore wrote:
> I can't understand what you guys are not-understanding.  New machinery
> has been added that says "if some module source code exists in this
> absolute fixed location on the build machine, then whenever you do any
> kernel build for any OS version or any arch, rebuild that module source
> code so that the the build machine's video drivers stay in sync with
> the build machine's kernel."
>
> Do you not see that for some of us, only a tiny fraction of the builds
> done (maybe none of them at all) involve the kernel for the build host
> machine or the video drivers for the build host machine?  And yet, for
> us, every build we do will now inapppropriately rebuild this video
> driver module which has nothing to do with the machine the build is
> targeting.
Most of the kernel builds I do _are_ for the host machine, yet I don't 
want the new behavior either.  Why?  The build logic of the source tree 
should be self-contained and easily understandable. Looking all over the 
system and trying to automate fixes is what ports are for.

Automated hacks for this sort of situation, that do the right thing 90% 
of the time but inevitably break down on other perfectly reasonable use 
cases, are one of the factors that pushed me away from the operating 
systems I used before FreeBSD.

Managing the host's kernel and needed modules from source from a single 
tool certainly is useful, but I think it should be just that: a tool, 
used when appropriate, not a default behavior.
This tool can be recommended to kmod port users/developers for local 
system work while everyone else may continue using source tree as expected.

On 2019-08-14 11:06, Kyle Evans wrote:
> LOCAL_MODULES="" does seem like a sensible default when we're not
> building a native kernel.
More generally there should be a switch for defeating any and all 
attempts to use anything "local" (non /usr/src).
Received on Wed Aug 14 2019 - 16:58:33 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:21 UTC