From owner-freebsd-pkgbase@freebsd.org Sat May 7 13:50:15 2016 Return-Path: Delivered-To: freebsd-pkgbase@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 181BCB3149C; Sat, 7 May 2016 13:50:15 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BDADB1690; Sat, 7 May 2016 13:50:12 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.15.2/8.15.2) with ESMTP id u47Do5E8070657; Sat, 7 May 2016 13:50:05 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id u47Do5E6070656; Sat, 7 May 2016 06:50:05 -0700 (PDT) (envelope-from david) Date: Sat, 7 May 2016 06:50:05 -0700 From: David Wolfskill To: Ben Woods Cc: "freebsd-pkgbase@freebsd.org" , FreeBSD Current Subject: Re: NO_INSTALLEXTRAKERNELS and PkgBase Message-ID: <20160507135005.GN62286@albert.catwhisker.org> Reply-To: "freebsd-pkgbase@freebsd.org" , FreeBSD Current Mail-Followup-To: "freebsd-pkgbase@freebsd.org" , FreeBSD Current , Ben Woods References: <20160506221151.GN1362@FreeBSD.org> <7018EDCD-A567-446D-965C-9E886D543238@gmail.com> <20160507074159.GC47527@FreeBSD.org> <1CCC4F95-D01E-4A5E-A744-5FE2ECA3D8FB@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="3hAdtgBjtgL7p0NQ" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) X-BeenThere: freebsd-pkgbase@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Packaging the FreeBSD base system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2016 13:50:15 -0000 --3hAdtgBjtgL7p0NQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [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) > wrote: >=20 > > glebius changed the defaults to fix POLA, but the naming per the behavi= or > > 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 >=20 >=20 > Indeed, I am not sure I understand the POLA violation entirely (ignoring > the fact that this variable requires affirmation of a negative). >=20 > 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 becau= se > 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 ; 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 --=20 David H. Wolfskill david@catwhisker.org Those who would murder in the name of God or prophet are blasphemous coward= s. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --3hAdtgBjtgL7p0NQ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJXLfKMXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDQ0I3Q0VGOTE3QTgwMUY0MzA2NEQ3N0Ix NTM5Q0M0MEEwNDlFRTE3AAoJEBU5zECgSe4XeR8IAIto/E/Dzvb+rGIkCUcpivmR e33owH9Ur9ZVcSo/tgdzs0za5mXSXD0mB+w2Wll1Ah3kOUMQ00Zb01qnDksSxzTC 398LwxY45OzuDU+b5alhET3TG+Y32SUGf1kYfihx3qWzx+TSaM1R4pZgQ2YmTASK RhDcJAT+TcTjnRUpiWd6YWlf5adb3ArFdTs5eTCaLEx0s/7epv3OlvUJ4EKgFLh0 pPnIE64d5BxsGG7y8TGPKfzO7SQV1mQUwEdaKjr9s117s2VjtB2Mvl5ELSsDFqfE /fNW4KPqbpG6Zd9p99Wg1iNVd1TsQM+hGofkLbhMDpH1cVeQr2eyae8Wpx/6K50= =bDkX -----END PGP SIGNATURE----- --3hAdtgBjtgL7p0NQ--