Re: NO_INSTALLEXTRAKERNELS and PkgBase

[David Wolfskill]

On Mon, May 09, 2016 at 12:43:42PM -0700, John Baldwin wrote:
> ...
> > I suppose there's probably some way to arrange things so the KERNCONF
> > specification in /etc/src.conf has one value during "buildkernel" and a
> > different value during "inistallkernel" -- but ... seriously...??!?
> 
> One could do some ugly things with .make() to change the default based on
> the target being invoked (kind of like folks storing port options in
> /etc/make.conf conditional on the current directory), but that would be
> hackish.

Right; "hackish" is probably a bit ... kinder than what came to mind.  :-}

> > Wouldn't it be cleaner to have different variables (e.g., that could
> > each default to the KERNCONF specification, but could be overridden in
> > a simple text file that doesn't require delving into make(1) arcana to
> > craft or understand)?
> 
> I think having separate variables is fine, and I think your suggestion of
> KERNCONF_BUILD and KERNCONF_INSTALL that default to KERNCONF would be
> fine.  From the thread, I think it would mean you would need to use the
> two settings in your /etc/src.conf but that other folks wanting to install
> both would just stick with KERNCONF, correct?

That is my understanding, yes.

I don't mind tweaking things a bit for an uncommon case; I'd rather
avoid twisting my mind into a pretzel to do something that's been quite
easy historically. :-)

> ...
> > Would that work?  It seems as if that would work for my case.
> 
> Yes.  I think that is also simpler than having a new WITH/WITHOUT variable
> to control how installkernel treats KERNCONF.
> 

Yay...!  :-)

Peace,
david
-- 
David H. Wolfskill  da...@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.


signature.asc
Description: PGP signature

Re: NO_INSTALLEXTRAKERNELS and PkgBase

[John Baldwin]

On Monday, May 09, 2016 11:45:44 AM David Wolfskill wrote:
> On Mon, May 09, 2016 at 11:05:55AM -0700, John Baldwin wrote:
> > On Saturday, May 07, 2016 06:50:05 AM David Wolfskill wrote:
> > > [Recipient list trimmed a bit -- dhw]
> > ... 
> > > > 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.
> > 
> > Then don't pass them to 'installkernel'?  That is, I think this makes sense
> > if you want to build N kernels but only install 1:
> > 
> > make buildkernel KERNCONF="FOO BAR BAZ"
> > 
> > # only install the FOO kernel
> > 
> > make installkernel KERNCONF="FOO"
> > 
> > And then if you want to install multiple:
> > 
> > # install both FOO and BAR kernels
> > 
> > make installkernel KERNCONF="FOO BAR"
> 
> I suppose there's probably some way to arrange things so the KERNCONF
> specification in /etc/src.conf has one value during "buildkernel" and a
> different value during "inistallkernel" -- but ... seriously...??!?

One could do some ugly things with .make() to change the default based on
the target being invoked (kind of like folks storing port options in
/etc/make.conf conditional on the current directory), but that would be
hackish.

> Wouldn't it be cleaner to have different variables (e.g., that could
> each default to the KERNCONF specification, but could be overridden in
> a simple text file that doesn't require delving into make(1) arcana to
> craft or understand)?

I think having separate variables is fine, and I think your suggestion of
KERNCONF_BUILD and KERNCONF_INSTALL that default to KERNCONF would be
fine.  From the thread, I think it would mean you would need to use the
two settings in your /etc/src.conf but that other folks wanting to install
both would just stick with KERNCONF, correct?

> Multiple installkernel invocations is certainly not something I would
> advocate -- I do silly things sometimes, but I hope nothing I wrote was
> interpreted thus. :-}

FWIW, my wrapper script I use arould buildworld, etc. actually invokes
installkernel multiple times (but it also uses buildkernel multiple times
as well.  I think my script predates multiple kernel support in KERNCONF).
 
> Suppose that src/Makefile.inc1 were modified so that:
> * KERNCONF_BUILD is set to the value (explicit or otherwise) of KERNCONF
>   unless it already has a value (in which case, the explicit value is
>   used).
> * KERNCONF_INSTALL is set to the value (explicit or otherwise) of KERNCONF
>   unless it already has a value (in which case, the explicit value is
>   used).
> 
> buildkernel then builds the kernel configs listed in KERNCONF_BUILD;
> installkernel then installs the kernels listed in KERNCONF_INSTALL.
> 
> Folks who want to build & install the same set of kernels see no change.
> 
> Folks who want a difference between "buildkernel" and "installkernel" have
> a simple way to specify it.
> 
> Only 1 invocation of installkernel is needed in any case.
> 
> Would that work?  It seems as if that would work for my case.

Yes.  I think that is also simpler than having a new WITH/WITHOUT variable
to control how installkernel treats KERNCONF.

-- 
John Baldwin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: NO_INSTALLEXTRAKERNELS and PkgBase

[Glen Barber]

On Mon, May 09, 2016 at 11:46:02AM -0700, Freddie Cash wrote:
> On Mon, May 9, 2016 at 11:40 AM, Ultima  wrote:
> 
> > If multiple kernels are being installed like this, eg KERNCONF="FOO BAR",
> > which of the two would be default during boot? FOO because it came first?
> 
> 
> Correct.  At least, that's the way it's worked in the past, and something
> I've used quite a bit on FreeBSD 7-9.  I always have GENERIC and a custom
> kernel listed in KERNCONF, with my custom kernel listed first.
> KERNCONF="FIREWALL GENERIC" for exmaple.  That way, my custom kernel is
> installed as /boot/kernel, and GENERIC is installed as
> /boot/kernel.GENERIC, which provides me with a fall-back in case I screw
> something up with my custom kernel (happens frequently).  :)
> 
> I used to do it manually using two separate installkernel steps using an
> env var to specify the installation directory (/boot/GENERIC) (forget the
> name of that var right now), but switched to using the automatic
> installation behaviour when it became available.  Simplified things a bit.
> 
> I haven't compiled a kernel on 10+ yet; hopefully the behaviour hasn't
> changed.  ;)

It has not changed, and the same behavior will be present for 11.0 in
that "whatever installkernel does, packaged base will follow the
behavior."

Glen



signature.asc
Description: PGP signature

Re: NO_INSTALLEXTRAKERNELS and PkgBase

[Freddie Cash]

On Mon, May 9, 2016 at 11:40 AM, Ultima  wrote:

> If multiple kernels are being installed like this, eg KERNCONF="FOO BAR",
> which of the two would be default during boot? FOO because it came first?


​Correct.  At least, that's the way it's worked in the past, and something
I've used quite a bit on FreeBSD 7-9.  I always have GENERIC and a custom
kernel listed in KERNCONF, with my custom kernel listed first.
KERNCONF="FIREWALL GENERIC" for exmaple.  That way, my custom kernel is
installed as /boot/kernel, and GENERIC is installed as
/boot/kernel.GENERIC, which provides me with a fall-back in case I screw
something up with my custom kernel (happens frequently).  :)

I used to do it manually using two separate installkernel steps using an
env var to specify the installation directory (/boot/GENERIC) (forget the
name of that var right now), but switched to using the automatic
installation behaviour when it became available.  Simplified things a bit.

I haven't compiled a kernel on 10+ yet; hopefully the behaviour hasn't
changed.  ;)
​​
-- 
Freddie Cash
fjwc...@gmail.com
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: NO_INSTALLEXTRAKERNELS and PkgBase

[David Wolfskill]

On Mon, May 09, 2016 at 11:05:55AM -0700, John Baldwin wrote:
> On Saturday, May 07, 2016 06:50:05 AM David Wolfskill wrote:
> > [Recipient list trimmed a bit -- dhw]
> ... 
> > > 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.
> 
> Then don't pass them to 'installkernel'?  That is, I think this makes sense
> if you want to build N kernels but only install 1:
> 
> make buildkernel KERNCONF="FOO BAR BAZ"
> 
> # only install the FOO kernel
> 
> make installkernel KERNCONF="FOO"
> 
> And then if you want to install multiple:
> 
> # install both FOO and BAR kernels
> 
> make installkernel KERNCONF="FOO BAR"

I suppose there's probably some way to arrange things so the KERNCONF
specification in /etc/src.conf has one value during "buildkernel" and a
different value during "inistallkernel" -- but ... seriously...??!?

Wouldn't it be cleaner to have different variables (e.g., that could
each default to the KERNCONF specification, but could be overridden in
a simple text file that doesn't require delving into make(1) arcana to
craft or understand)?

Why make things harder for folks who are trying to use the system?

> The runaround seems to be whether this last case now should require multiple
> explicit installkernel invocations which I find inconsistent since the build
> stage doesn't.  I would fully expect 'installkernel' to install all of the
> kernels listed in KERNCONF and would assume that it is up to the invoker to
> choose KERNCONF appropriately.
> 

Multiple installkernel invocations is certainly not something I would
advocate -- I do silly things sometimes, but I hope nothing I wrote was
interpreted thus. :-}

Suppose that src/Makefile.inc1 were modified so that:
* KERNCONF_BUILD is set to the value (explicit or otherwise) of KERNCONF
  unless it already has a value (in which case, the explicit value is
  used).
* KERNCONF_INSTALL is set to the value (explicit or otherwise) of KERNCONF
  unless it already has a value (in which case, the explicit value is
  used).

buildkernel then builds the kernel configs listed in KERNCONF_BUILD;
installkernel then installs the kernels listed in KERNCONF_INSTALL.

Folks who want to build & install the same set of kernels see no change.

Folks who want a difference between "buildkernel" and "installkernel" have
a simple way to specify it.

Only 1 invocation of installkernel is needed in any case.

Would that work?  It seems as if that would work for my case.

Peace,
david
-- 
David H. Wolfskill  da...@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.


signature.asc
Description: PGP signature

Re: NO_INSTALLEXTRAKERNELS and PkgBase

[Ultima]

If multiple kernels are being installed like this, eg KERNCONF="FOO BAR",
which of the two would be default during boot? FOO because it came first?

On Mon, May 9, 2016 at 2:05 PM, John Baldwin  wrote:

> On Saturday, May 07, 2016 06:50:05 AM David Wolfskill wrote:
> > [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) <
> yaneurab...@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.
>
> Then don't pass them to 'installkernel'?  That is, I think this makes sense
> if you want to build N kernels but only install 1:
>
> make buildkernel KERNCONF="FOO BAR BAZ"
>
> # only install the FOO kernel
>
> make installkernel KERNCONF="FOO"
>
> And then if you want to install multiple:
>
> # install both FOO and BAR kernels
>
> make installkernel KERNCONF="FOO BAR"
>
> The runaround seems to be whether this last case now should require
> multiple
> explicit installkernel invocations which I find inconsistent since the
> build
> stage doesn't.  I would fully expect 'installkernel' to install all of the
> kernels listed in KERNCONF and would assume that it is up to the invoker to
> choose KERNCONF appropriately.
>
> --
> John Baldwin
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: NO_INSTALLEXTRAKERNELS and PkgBase

[John Baldwin]

On Saturday, May 07, 2016 06:50:05 AM David Wolfskill wrote:
> [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:
> > 
> > > 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.

Then don't pass them to 'installkernel'?  That is, I think this makes sense
if you want to build N kernels but only install 1:

make buildkernel KERNCONF="FOO BAR BAZ"

# only install the FOO kernel

make installkernel KERNCONF="FOO"

And then if you want to install multiple:

# install both FOO and BAR kernels

make installkernel KERNCONF="FOO BAR"

The runaround seems to be whether this last case now should require multiple
explicit installkernel invocations which I find inconsistent since the build
stage doesn't.  I would fully expect 'installkernel' to install all of the
kernels listed in KERNCONF and would assume that it is up to the invoker to
choose KERNCONF appropriately.

-- 
John Baldwin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: NO_INSTALLEXTRAKERNELS and PkgBase

[Thomas Mueller]

I don't really know what to quote here, but the documentation is not clear.  
There ought to be something in UPDATING.

Issue is building and installing more than one kernel.  I tried once, and it 
didn't work right.  I had to go back to one kernel at a time and NO_MODULES=yes 
on second and subsequent to avoid building the same modules redundantly.

What now happens on HEAD if I

make kernel KERNCONF=SANDY11NC GENERIB
?

I don't want to build all modules more than once.

GENERIB is modified from GENERIC to remove really drivers for really outdated 
hardware, such as old SCSI cards, and add some wireless drivers such as rsu.

Tom

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: NO_INSTALLEXTRAKERNELS and PkgBase

[Ben Woods]

On Saturday, 7 May 2016, David Wolfskill  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
> ; 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
woods...@gmail.com
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: 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) 
> 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
; 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  da...@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.


signature.asc
Description: PGP signature

Re: NO_INSTALLEXTRAKERNELS and PkgBase

[Ngie Cooper (yaneurabeya)]

> On May 7, 2016, at 00:59, Ben Woods  wrote:
> 
> On 7 May 2016 at 09:48, Ngie Cooper (yaneurabeya)  
> 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).

It’s tricky… KERNCONF with multiple kernel configurations wasn’t properly 
supported at install time until 2016 AFAIK (r291611, r293391), so again (AFAIK) 
it’s a new [functional] feature, even though make.conf(5) says one can specify 
multiple kernel configurations in KERNCONF at build time.

> 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?

From a literal perspective, it makes perfect sense. From a usability 
perspective though, or in terms of actual behavior, it makes less sense.

If FreeBSD required more explicit pathing for kernels like Linux in the boot 
loader (e.g. grub) on many distros (e.g. CentOS), this would likely be a 
non-issue.

> 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).

Yes, but the knob should be renamed for clarity. imp@ had a very good point — 
NO_* options aren’t as flexible/intuitive as MK_* options and lead to confusing 
behavior.

Thanks!
-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: NO_INSTALLEXTRAKERNELS and PkgBase

[Ngie Cooper (yaneurabeya)]

> On May 7, 2016, at 00:46, Ben Woods  wrote:
> 
> 
> On 7 May 2016 at 09:41, Glen Barber  wrote:
> I think this raises a larger question - did "something" change that
> otherwise violates POLA?  The commit recently was intended to revert
> a POLA violation, so maybe I am not entirely clear on what branch this
> affects.
> 
> Are we talking about head or stable/10 here?
> 
> Glen
> 
> I am talking about head, which no longer installs/packages multiple kernels 
> by default.
> https://svnweb.freebsd.org/base/head/Makefile.inc1?revision=299088=markup
> 
> Whilst the r299088 commit is referring to a stable POLA violation, the commit 
> itself is a change to head with a proposed MFC after 3 days. Its interesting, 
> because this has surprised me when testing PkgBase on head, as the behaviour 
> has changed from the initial announcement.

The behavior in and of itself (to me) is unintuitive. I use a different wrapper 
script [*] to install kernels with a different name because I want them to be 
versioned based on $KERNCONF + revision data. I only fixed building multiple 
kernels because the change that glebius tested didn’t work with more than one 
KERNCONF (hence the double commit).

I think the default behavior should be “yes” (not “no”) as many folks use a 
single KERNCONF, not multiple (on head), but I’m biased in this thinking...

Thanks!
-Ngie

* 
https://github.com/yaneurabeya/scratch/blob/master/bayonetta/root/bin/installkernel.sh
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: NO_INSTALLEXTRAKERNELS and PkgBase

[Ben Woods]

On 7 May 2016 at 09:48, Ngie Cooper (yaneurabeya) 
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?

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).

Regards,
Ben
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: NO_INSTALLEXTRAKERNELS and PkgBase

[Glen Barber]

On Sat, May 07, 2016 at 09:46:03AM +0200, Ben Woods wrote:
> On 7 May 2016 at 09:41, Glen Barber  wrote:
> 
> > I think this raises a larger question - did "something" change that
> > otherwise violates POLA?  The commit recently was intended to revert
> > a POLA violation, so maybe I am not entirely clear on what branch this
> > affects.
> >
> > Are we talking about head or stable/10 here?
> >
> > Glen
> >
> 
> I am talking about head, which no longer installs/packages multiple kernels
> by default.
> https://svnweb.freebsd.org/base/head/Makefile.inc1?revision=299088=markup
> 
> Whilst the r299088 commit is referring to a stable POLA violation, the
> commit itself is a change to head with a proposed MFC after 3 days. Its
> interesting, because this has surprised me when testing PkgBase on head, as
> the behaviour has changed from the initial announcement.
> 

I think there is a communication breakdown somewhere, then.

But, I also realize we are talking about two different commits.  (Which
is why I CC'd glebius@ in the previous reply.)

Since ngie@ already chimed in, I'll defer unless required to chime in.

Glen



signature.asc
Description: PGP signature

Re: NO_INSTALLEXTRAKERNELS and PkgBase

[Ngie Cooper (yaneurabeya)]

> On May 7, 2016, at 00:41, Glen Barber  wrote:
> 
> On Sat, May 07, 2016 at 12:35:10AM -0700, Ngie Cooper (yaneurabeya) wrote:
>> (Replying because I kicked the hornet’s nest when my build failed)
>> Hi Ben,
>> 
>>> On May 7, 2016, at 00:27, Ben Woods  wrote:
>>> 
>>> On Saturday, 7 May 2016, Glen Barber  wrote:
>>> 
 With 'installkernel', the first kernel listed in KERNCONF is installed
 as the default (/boot/kernel), and subsequent kernels are installed with
 the kernel name included in the path (/boot/kernel.${INSTKERNNAME}).  In
 both cases (source-based upgrades and with pkgbase), the behavior will
 remain the same.
 
 Glen
 
>>> 
>>> Hi Glen,
>>> 
>>> With the recent commit mentioned previously, only the first kernel listed
>>> in KERNCONF is installed unless make.conf contains the following line:
>>> NO_INSTALLEXTRAKERNELS=no
>>> 
>>> This affects both source-based upgrades (make installkernel) and package
>>> building (make packages).
>>> 
>>> Is this the desired behaviour?
>> 
>> The naming is very confusing. It should be:
>> 
>> - MK_INSTALLEXTRAKERNELS=no -> only install one
>> - MK_INSTALLEXTRAKERNELS=yes -> install multiple, as gjb@ described above.
>> 
>> Since I kicked the hornet’s nest (and imp@ complained about the
>> NO_*), I’ll introduce a new WITH/WITHOUT option for this and
>> release/release.sh can use it.
>> 
> 
> I think this raises a larger question - did "something" change that
> otherwise violates POLA?  The commit recently was intended to revert
> a POLA violation, so maybe I am not entirely clear on what branch this
> affects.
> 
> Are we talking about head or stable/10 here?

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
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: NO_INSTALLEXTRAKERNELS and PkgBase

[Ben Woods]

On 7 May 2016 at 09:41, Glen Barber  wrote:

> I think this raises a larger question - did "something" change that
> otherwise violates POLA?  The commit recently was intended to revert
> a POLA violation, so maybe I am not entirely clear on what branch this
> affects.
>
> Are we talking about head or stable/10 here?
>
> Glen
>

I am talking about head, which no longer installs/packages multiple kernels
by default.
https://svnweb.freebsd.org/base/head/Makefile.inc1?revision=299088=markup

Whilst the r299088 commit is referring to a stable POLA violation, the
commit itself is a change to head with a proposed MFC after 3 days. Its
interesting, because this has surprised me when testing PkgBase on head, as
the behaviour has changed from the initial announcement.

Regards,
Ben
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: NO_INSTALLEXTRAKERNELS and PkgBase

[Glen Barber]

On Sat, May 07, 2016 at 12:35:10AM -0700, Ngie Cooper (yaneurabeya) wrote:
> (Replying because I kicked the hornet’s nest when my build failed)
> Hi Ben,
> 
> > On May 7, 2016, at 00:27, Ben Woods  wrote:
> > 
> > On Saturday, 7 May 2016, Glen Barber  wrote:
> > 
> >> With 'installkernel', the first kernel listed in KERNCONF is installed
> >> as the default (/boot/kernel), and subsequent kernels are installed with
> >> the kernel name included in the path (/boot/kernel.${INSTKERNNAME}).  In
> >> both cases (source-based upgrades and with pkgbase), the behavior will
> >> remain the same.
> >> 
> >> Glen
> >> 
> > 
> > Hi Glen,
> > 
> > With the recent commit mentioned previously, only the first kernel listed
> > in KERNCONF is installed unless make.conf contains the following line:
> > NO_INSTALLEXTRAKERNELS=no
> > 
> > This affects both source-based upgrades (make installkernel) and package
> > building (make packages).
> > 
> > Is this the desired behaviour?
> 
> The naming is very confusing. It should be:
> 
> - MK_INSTALLEXTRAKERNELS=no -> only install one
> - MK_INSTALLEXTRAKERNELS=yes -> install multiple, as gjb@ described above.
> 
> Since I kicked the hornet’s nest (and imp@ complained about the
> NO_*), I’ll introduce a new WITH/WITHOUT option for this and
> release/release.sh can use it.
> 

I think this raises a larger question - did "something" change that
otherwise violates POLA?  The commit recently was intended to revert
a POLA violation, so maybe I am not entirely clear on what branch this
affects.

Are we talking about head or stable/10 here?

Glen




signature.asc
Description: PGP signature

Re: NO_INSTALLEXTRAKERNELS and PkgBase

[Ngie Cooper (yaneurabeya)]

(Replying because I kicked the hornet’s nest when my build failed)
Hi Ben,

> On May 7, 2016, at 00:27, Ben Woods  wrote:
> 
> On Saturday, 7 May 2016, Glen Barber  wrote:
> 
>> With 'installkernel', the first kernel listed in KERNCONF is installed
>> as the default (/boot/kernel), and subsequent kernels are installed with
>> the kernel name included in the path (/boot/kernel.${INSTKERNNAME}).  In
>> both cases (source-based upgrades and with pkgbase), the behavior will
>> remain the same.
>> 
>> Glen
>> 
> 
> Hi Glen,
> 
> With the recent commit mentioned previously, only the first kernel listed
> in KERNCONF is installed unless make.conf contains the following line:
> NO_INSTALLEXTRAKERNELS=no
> 
> This affects both source-based upgrades (make installkernel) and package
> building (make packages).
> 
> Is this the desired behaviour?

The naming is very confusing. It should be:

- MK_INSTALLEXTRAKERNELS=no -> only install one
- MK_INSTALLEXTRAKERNELS=yes -> install multiple, as gjb@ described above.

Since I kicked the hornet’s nest (and imp@ complained about the NO_*), I’ll 
introduce a new WITH/WITHOUT option for this and release/release.sh can use it.

Thanks!
-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: NO_INSTALLEXTRAKERNELS and PkgBase

[Glen Barber]

On Sat, May 07, 2016 at 09:27:54AM +0200, Ben Woods wrote:
> On Saturday, 7 May 2016, Glen Barber  wrote:
> 
> > With 'installkernel', the first kernel listed in KERNCONF is installed
> > as the default (/boot/kernel), and subsequent kernels are installed with
> > the kernel name included in the path (/boot/kernel.${INSTKERNNAME}).  In
> > both cases (source-based upgrades and with pkgbase), the behavior will
> > remain the same.
> >
> 
> With the recent commit mentioned previously, only the first kernel listed
> in KERNCONF is installed unless make.conf contains the following line:
> NO_INSTALLEXTRAKERNELS=no
> 
> This affects both source-based upgrades (make installkernel) and package
> building (make packages).
> 
> Is this the desired behaviour?
> 

As far as I am aware, yes.  I've CC'd glebius@ to confirm.  In both
cases, the "behavior" should be the same, regardless.  I think I'm
looking at the question from a different way than you are asking though.

Glen



signature.asc
Description: PGP signature

Re: NO_INSTALLEXTRAKERNELS and PkgBase

[Ben Woods]

On Saturday, 7 May 2016, Glen Barber  wrote:

> With 'installkernel', the first kernel listed in KERNCONF is installed
> as the default (/boot/kernel), and subsequent kernels are installed with
> the kernel name included in the path (/boot/kernel.${INSTKERNNAME}).  In
> both cases (source-based upgrades and with pkgbase), the behavior will
> remain the same.
>
> Glen
>

Hi Glen,

With the recent commit mentioned previously, only the first kernel listed
in KERNCONF is installed unless make.conf contains the following line:
NO_INSTALLEXTRAKERNELS=no

This affects both source-based upgrades (make installkernel) and package
building (make packages).

Is this the desired behaviour?

Regards,
Ben


-- 

--
From: Benjamin Woods
woods...@gmail.com
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: NO_INSTALLEXTRAKERNELS and PkgBase

[Glen Barber]

On Sat, May 07, 2016 at 12:08:28AM +0200, Ben Woods wrote:
> Hi everyone,
> 
> The commit in r299088 changes the behaviour for building multiple kernels
> when the KERNCONF value contains multiple (space-separated) kernel conf
> names.
> https://svnweb.freebsd.org/base?view=revision=299088
> 
> When PkgBase was announced by Glen Barber in March, note 4 of his email
> stated that multiple kernels would be built and packaged if multiple are
> listed in KERNCONF.
> https://lists.freebsd.org/pipermail/freebsd-pkgbase/2016-March/32.html
> 
> Can I please clarify the desired behaviour so that I can update the PkgBase
> wiki article accordingly? I personally think it is quite a neat feature to
> build multiple kernels if they are listed in KERNCONF.
> 

With 'installkernel', the first kernel listed in KERNCONF is installed
as the default (/boot/kernel), and subsequent kernels are installed with
the kernel name included in the path (/boot/kernel.${INSTKERNNAME}).  In
both cases (source-based upgrades and with pkgbase), the behavior will
remain the same.

Glen



signature.asc
Description: PGP signature

NO_INSTALLEXTRAKERNELS and PkgBase

[Ben Woods]

Hi everyone,

The commit in r299088 changes the behaviour for building multiple kernels
when the KERNCONF value contains multiple (space-separated) kernel conf
names.
https://svnweb.freebsd.org/base?view=revision=299088

When PkgBase was announced by Glen Barber in March, note 4 of his email
stated that multiple kernels would be built and packaged if multiple are
listed in KERNCONF.
https://lists.freebsd.org/pipermail/freebsd-pkgbase/2016-March/32.html

Can I please clarify the desired behaviour so that I can update the PkgBase
wiki article accordingly? I personally think it is quite a neat feature to
build multiple kernels if they are listed in KERNCONF.

Regards,
Ben

--
From: Benjamin Woods
woods...@gmail.com
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"