pkg:

• Flag files to be upgraded first
• Multiple packages with the same name in the repo (not depend origin)
• pre-uninstall hooks into the solver to check before removing something critical (i.e. Kernel)

stageworld:

• Generates a large MANIFEST file.. go through any items that do not have a tag. Figure out why and add a tag.

In order to attend you need register for the developer summit and add yourself here.

Thanks to DagErlingSmørgrav for taking notes

• want to provide new mechanism for installing and updating the base system: set of packages
• project branch: base/projects/release-pkg
• two philosophies: “one big thing” vs “highly granular”
• packages, meta-packages etc
• three layers: kernel base(runtime) devel
• granularity not yet defined, probably a “core” package with !contrib and individual packages for contrib
• binary upgrades on regular basis, including for stable and current branches
• least intrusive way possible: cd /usr/src && make packages
• project branch, creates a world package and a kernel package
• mostly done with hooking into the build system
• some issues with flags and hard links (can't link to a schg)
• some files are not installed with INSTALL_FOO and fall between the cracks
• etc is complicated because it mixes files which belong to different components (e.g. ssh, unbound)
• pkg now has three-way merge for /etc
• UCL files define packages, license, architecture
• TODO: work on splitting up world into packages
• TODO: flags to force installation order, problem for libc, libthr and rtld-elf - this is not a problem from day to day but *can* trip you up
• TODO: having multiple kernel packages installed concurrently, modify the loader to provide a list of available kernels with the most recent one as the default
• TODO: having multiple versions of the same package in the same repository
• TODO: how to automatically bump package versions
• TODO: improve reproducibility
• complain about removing current kernel: can't rely on pre-uninstall script because so many scripts are broken that we currently ignore them. Perhaps a new “callback” script which reports that the package is “precious”?
• package naming / numbering
  • FreeBSD-runtime-10.2_4
  • FreeBSD-runtime-11.s20151001
  • FreeBSD-runtime-11.0
• for now, no attempt to have ports depend on base

Create a shell script that registers your current base system in the pkg local db, distribute this script to existing installations with freebsd-update. Users run this script to convert their system, and then upgrade to 11.