Re: bsdconfig lost through a major upgrade

Graham Perrin wrote in <10991079-e8ca-4eb1-af05-b74535311dd1@gmail.com>:
> With a converted minimal installation of 14.3: following a major upgrade to
> 15.0-ALPHA2, bsdconfig is not found.
> 
> Lazily worked around by (wastefully) installing all base packages, after
> which pkg-which(8) discovered FreeBSD-bsdconfig:

there is a plan to add this functionality to pkg, so you could run
"pkg rwhich /usr/sbin/bsdconfig" to discover the FreeBSD-bsdconfig
package.

> I'm aware of the work on sets. Does that work negate the need to address
> what's above?

bsdconfig is in the base set, so in a hypothetical world where 14.x
supported sets, it would only be automatically installed on upgrade
if you had the base set installed.  for 15.x, the base set will be
offered as an option in the installer, but it remains to be seen if
users will prefer to install that or to only install the minimal
set and add packages themselves.

14 to 15 is a bit of a special case here because 14.x with pkgbase was
never a supported configuration, so a few rough edges when upgrading are
expected.  this is why i tried to get all of these package splits done
prior to the 15.0 release, where pkgbase *is* a supported configuration
(and i think we've been largely successful there).

how we approach new packages after 15.0 is released will depend on each
specific case, but to speculate a bit:

- i think we'll try to avoid moving existing files to new packages in
  the stable/15 release cycle, unless there's a very clear benefit to
  doing so, and even then probably only if it's included in the minimal
  set which (nearly) all users will have installed.  this means you can
  upgrade across 15.x releases and not have to worry about this.

  however, we might add new packages for new functionality, so for
  example if 15.1 imported KDE into the base system[0], we'd add a
  new FreeBSD-kde package for that.  in that case the new package(s)
  would be mentioned in the release notes for 15.1, and would be part
  of the appropriate set (probably base).  this is reasonable because
  people expect that adding new functionality requires installing new
  packages, and for people who don't want to deal with that, they can
  simply install the base set and get everything, just like before.

  [0] a hypothetical example, obviously we're not planning to do that.

- although i don't have any plans to do this, i think we can reasonably
  move existing files to new packages across a major release, e.g., 15.x
  to 16.0, even if the new packages aren't in minimal.  in that case
  we'd mention the new packages in the release notes in the expectation
  that users upgrading to a new major release read the release notes.

  i would like to see a mechanism in pkg to handle package splits like
  this, so it would automatically install the new package if you upgrade
  across the split point, but i'm not sure if that will happen or if
  it's even worth it considering how infrequently we're likely to do
  this.