Instead of using installworld to build the release media, use the base package repository we already created. This is much faster than running installworld again, and in future will allow us to build install media from an external package repository. The sets used for each medium are: * disc1: kernels, optional. This provides a basic live system. * bootonly: kernels, minimal. This saves about 100MB compared to installing optional. * dvd: kernels, optional, devel. We might want to drop devel in the future to include more packages, but for now, this matches the current contents of the medium. Since the new install-system target always installs pkg, we can also simplify the target-specific logic a bit to only handle the extra packages. Keep the existing non-package method for the NOPKGBASE case so that downstream users can continue building distset install media without having to depend on pkg. This should be removed once we vendor pkg. Add a warning about distset support being deprecated. This is only printed if NOPKGBASE is set and can be disabled entirely by setting RELEASE_SKIP_DISTSET_WARNING.
Details
Details
Diff Detail
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Skipped - Unit
Tests Skipped - Build Status
Buildable 69637 Build 66520: arc lint + arc unit
Event Timeline
Comment Actions
fix the metalog mode for /var/db/services.db
(although this doesn't really matter as /var is tmpfs in the installer environment.)
| release/Makefile | ||
|---|---|---|
| 48 | Is this because we can use the dvd as a somewhat usable live system as well? | |
| 50 | IMO we should uncomment this - the bootonly is intended to be as small as possible including only what is necessary for remote installation. | |
| 306 | When we switch to building release images from pkgbase this code path will start to bitrot. We should probably emit a warning indicating that this is no longer regularly tested. | |
| release/Makefile | ||
|---|---|---|
| 48 | i did wonder about that - does anyone actually use the compiler on the DVD? would it be useful to remove it (all the devel libraries are quite big) and put more packages on there? i'm happy to remove devel, but i thought it was best to start by replicating what we already have. | |
| release/Makefile | ||
|---|---|---|
| 48 | I agree with replicating what we already have as a starting point; but yes, we should have a conversation about release images, possibly in the direction of separating "install media" from "live system". | |
Comment Actions
Yes, agreed on starting with an approximation that is as close as possible w/ pkgbase to what we have today.
Comment Actions
use minimal for bootonly by default
print a warning about distsets if NOPKGBASE is set
instead of hardcoding bsdinstall and bsdconfig in install-system, add
a new variable, RELEASE_BASE_PACKAGES
Comment Actions
use a "." form for the release sets, so RELEASE_MEDIA_SETS_BOOTONLY
becomes RELEASE_MEDIA_SETS.bootonly. this makes it more clear that
it can be set for any media type.
Comment Actions
are there any objections to landing this? i'd like to get started on multiple kernel support for bsdinstall, and it would be easier to get the other release changes in first.
Comment Actions
I haven't reviewed the code but in principle I'm ok with the change. Please check with the CHERI people in case this will cause problems for them though -- I think they were holding off on pkgbase for a bit, and they're an important downstream for the project.
Not sure if you were planning on MFCing this, but if you are we should discuss further before that happens. There has been some release build breakage in HEAD lately so I want to make sure all the issues are fixed there before anything gets MFCed.
Comment Actions
I want to make sure all the issues are fixed there before anything gets MFCed.
My preference is for all of the release building changes to be merged to stable/15, but after a significant amount of time & testing in main. Perhaps after the 14.4 process is complete?
Comment Actions
Probably not necessary to wait that long. I just want to have a couple weeks of 16.x snapshots building successfully first.
Comment Actions
i wasn't planning to MFC this because it changes the release process in a surprising way. is that the sort of change we want to make in a release branch?
Comment Actions
i tried to be careful not to break the distset release build and i did test it while developing this. i also previously confirmed on IRC that this approach is acceptable to them in principle. still, it's possible i missed something since i don't use / care about dist sets myself.
@jrtc27 any objections here?