Re: NO_INSTALLEXTRAKERNELS and PkgBase

From: Ben Woods <woodsb02_at_gmail.com>
Date: Sat, 7 May 2016 16:06:08 +0200
On Saturday, 7 May 2016, David Wolfskill <david_at_catwhisker.org> wrote:
>
> > If you list 2 kernels in the KERNCONF variable, why is it astonishing
> that
> > 2 kernels get installed? Even if the old behaviour was to only install 1
> > kernel, if you are listing 2 kernels in KERNCONF presumably that is
> because
> > you want to install 2 kernels?
>
> Errr... no: I don't.  At least, not on the machine where I built them.
>
> The process I've been using (with "variations on the theme" over the
> years) since around 1999 or so for updating my "production" machines at
> home is described in some detail at
> <http://www.catwhisker.org/~david/FreeBSD/upgrade.html>; in summary, the
> production machines (only) mount /usr/src & /usr/obj from a dedicated
> "build machine" via NFS during the "upgrade window," during which time
> the production machine's kernel & userland are installed (from the build
> machine, which had built them).
>
> The build machine does all of the compilation; each production machine
> merely does installation.
>
> There is no value in "installing" the production machine kernels on the
> build machine -- and I never configured the build machine with the
> expectation that the root filesystem would ever need to be big enough to
> store kernels that would never be loaded on that machine.
>
> Fundamentally, just as we separate "build{world,kernel}" targets from
> "install{world,kernel}" targets, it is appopriate to separate -- and not
> conflate -- building of a kernel on a machine from installing that kernel
> on that machine.
>

Thanks for the explanation - the use case and POLA are clear to me now.

Perhaps we need the "make packages" to somehow ignore this variable, as it
makes that would not want to install multiple kernels on a machine, but
that you may want to build multiple kernel packages anyway, for use on
other machines?

Regards,
Ben

-- 

--
From: Benjamin Woods
woodsb02_at_gmail.com
Received on Sat May 07 2016 - 12:06:10 UTC

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