early pkgbase feedback

[Nikolai Lifanov]

I understand that this is contentious topic and I ultimately want this
work to succeed, but there are a few gotchas that I'd like to report
that I don't think were previously mentioned in another (now derailed)
thread.

o no separation of base and packages (boot environments, jails)

  Before, I was able to have a clear separation of base and packages
  and upgrade them separately. I accomplished this by having /var/db/pkg
  and /usr/local outside of boot environment ROOT. I was able to upgrade
  just the base system and if the ABI is stable packages "just worked".
  Now these are bundled.

  With jails, I used to be able to mount base in read-only with
  read-write /var/, /etc/, /usr/local/, etc. Now I'm not able to do
  this anymore.

o no dependencies between base packages

  There is no recommendation for what I need to get a working system.
  For example, I'm able to remove things like libxo and have a massively
  broken system. Small example:

    # pkg remove FreeBSD-libvmmapi
    Checking integrity... done (0 conflicting)
    Deinstallation has been requested for the following 1 packages (of
 0 packages in the universe):

    Installed packages to be REMOVED:
         FreeBSD-libvmmapi-11.0.s20160417160247

    Proceed with deinstalling packages? [y/N]: y
    [1/1] Deinstalling FreeBSD-libvmmapi-11.0.s20160417160247...
    [1/1] Deleting files for FreeBSD-libvmmapi-11.0.s20160417160247: 100%
    # ldd `which bhyve`
    /usr/sbin/bhyve:
            libvmmapi.so.5 => not found (0)
            libmd.so.6 => /lib/libmd.so.6 (0x80085f000)
            libthr.so.3 => /lib/libthr.so.3 (0x800a72000)
            libc.so.7 => /lib/libc.so.7 (0x800c98000)

o unclear mechanism for picking up new components

  Maybe meta packages will fix this, but when software like Unbound or
  LLDB is imported, "pkg upgrade" won't pick it up. If granularity
  property of base packages is used to remove something like Sendmail,
  then meta package for base would have to be removed as well, and
  new components won't be picked up during upgrades. I can always
  perform a "pkg install -r base -g '*'" or some such, but it's not
  obvious. Removal of old components is even trickier. I'm unclear how
  this is supposed to work.

o no quick way to produce packages

  Packages are currently built serially. I use META_MODE to rebuild
  the source tree in ~30 seconds to pick up small changes and install
  by mounting src and obj read-only from the build box. It's all quick.
  It takes minutes to create packages, so I don't do this automatically.
  It might be intuitive that this time is paid off with a faster
  install, but in practice installing from packages is slower.

o odd default versioning scheme

  On download.freebsd.org, snapshots are named like this:
   FreeBSD-11.0-CURRENT-amd64-20160206-r295345-...
  Base packages are named like this:
   FreeBSD-ssh-11.0.s20160418185743
  Without overriding PKG_VERS in make environment, it's pretty tough to
  get a revision number from this. If there is a few hour delay from
  build to package, these need to be extracted to figure this out.
  Also, the abundance of precision in the name makes packaging runs
  from the same source non-reproducible because they depend on the
  time of the builder. They are also different to cache in a CI-like
  environment.

o unclear upgrade mechanism

  If a package ${ABI} is FreeBSD:11:amd64, how will it be possible to
  upgrade to FreeBSD:12:amd64? Shouldn't "pkg" tool refuse this?

o hard to detect breakage until it is too late

  Recently, a normal "pkg upgrade" run resulted in the removal of these:

   /etc/rc.sendmail
   /etc/auto_master
   /var/crash/minfree

  I didn't even notice this until a reboot of that system and things
  just stopped working. There was no etcupdate-like verbosity to
  removing these and they were not registered in my local pkg database.
  I can kind-of tell what's going to be on my system if I run install*
  and then delete-old* targets, but it's hard to be confident in the
  success of an upgrade due to lack of verbosity.

o hard to revert from pkgbase to installworld workflow

  I use boot environments, and I had to discard quite a few during
  switching to pkgbase. To reasonably revert, the best I could come
  up with is roughly "create a boot environment", "pkg -r <dir> remove
  -f -g 'FreeBSD-*'", installworld, and use patch to apply an
  "etcupdate diff" from the host after a bootstrap created from the
  same revision.

Please only interpret this as feedback. This work is important and will
unblock Cool Things.

Thanks for hard work,

- Nikolai Lifanov