NO_INSTALLEXTRAKERNELS and PkgBase

[David Wolfskill]

[Recipient list trimmed a bit -- dhw]

I'm speaking up here because IIRC, I whined to Gleb at what I perceived
to be a POLA violation a while back....

On Sat, May 07, 2016 at 09:59:06AM +0200, Ben Woods wrote:
> On 7 May 2016 at 09:48, Ngie Cooper (yaneurabeya) <yaneurabeya at gmail.com>
> wrote:
> 
> > glebius changed the defaults to fix POLA, but the naming per the behavior
> > is confusing. Right now the behavior between ^/head and ^/stable/10
> > before/now match -- I just had to wrap my mind around the default being the
> > affirmative of a negative (i.e. only install one kernel, as opposed to
> > install all extra kernels by default).
> > -Ngie
> 
> 
> Indeed, I am not sure I understand the POLA violation entirely (ignoring
> the fact that this variable requires affirmation of a negative).
> 
> 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.

Keeping them separate allows folks who want to do both on a machine to
do so, and it doesn't break those of us who want to do something else.

Now, I don't do this using head -- presently, it's stable/10.  And
when 11 is branched, I expect to start telling the build machine
to build not only its own (GENERIC) stable/11 kernel, but also the
role-specific stable/11 kernels for the production machines.  When
that happens, I (still) won't want to be installing those kernels
on the build machine.  (And my first experiments with installing
those kernels will be on a separate "test" machine that is configured
to be nearly isomorphic to one of the production machines.)

> Regardless, perhaps it is ok to leave behaviour on stable 9/10 unchanged,
> but to make the behaviour on head to install multiple kernels by default?
> That is the option that makes sense for PkgBase (build multiple kernel
> packages if more than one are listed in KERNCONF).

I'm not too fussed about the implementation or the default, as long as I
can set things up to preserve the distinction between the "build" and
"production" roles -- where the production machines don't have their own
(locally-mounted) src or obj, and don't do builds, while the build
machine doesn't install kernels that only run on other machines.

Peace,
david
-- 
David H. Wolfskill				david at catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 603 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-current/attachments/20160507/486accee/attachment.sig>