On Thu, Mar 03, 2016 at 07:58:06PM -0500, Garrett Wollman wrote: > <<On Wed, 2 Mar 2016 23:54:29 +0000, Glen Barber <[email protected]> said: > > > After checking out the project branch, build the userland and kernel as > > normal with the 'buildworld' and 'buildkernel' targets. Afterward, > > packages can be created with the 'packages' target. > > > # cd /usr/src > > # make [make flags] buildworld > > # make [make flags] buildkernel > > # make packages > > Since I don't have any 11-current machines yet, I tried cross-building > this on my 10.2 build server, and it seems to work just fine, although > pkg(8) whines copiously about "Major OS version upgrade detected. > Running "pkg-static install -f pkg" recommended".
This is expected. > I note also that > "make packages" doesn't work with -jN, but "make release" never worked > in parallel either, and I suspect they break in the same place for the > same underlying reason. Until the 'install' targets are '-j' safe, 'make packages' will not be. > I did this build as myself with -DNO_ROOT and > everything went fine; a spot check of the packages shows the correct > file ownership. > > > At present, the base system consists of 755 packages with the default > > build (empty src.conf(5) and make.conf(5)) for amd64. The number of > > packages depends on several factors, but for most cases a runtime binary > > is split into several components. In particular, most shared libraries > > are individually packaged, in addition to debugging symbols, profiling > > libraries, and 32-bit packaged separately. > > I was prepared to freak out at this, but with half the packages > consisting of debugging symbols for binaries that ship stripped in > 10.x anyway (so most users would never need nor install those > packages), the number isn't so unreasonable. I get 531 non-"-debug-" > packages here, which is still more than I'd like but tolerable given > how many of them will never be installed. (Could some of those > library packages be consolidated? This was intentional. If, for example, there is a libxo bug that requires an EN or SA, we do not want the binary upgrade to exceed more than required. > I'm not convinced that it makes > much sense to have all the different -lib32-* variants given the > normal use case is runtime-only. For those who have no need for lib32 stuff, we do not want to enforce its existence. > And I don't see the profit in having > separate libusb, libusbhid, libutil, libvmmapi, libwrap, libxo, liby, > libypclnt, libz, etc. packages, either.) > The underlying reason for this is noted above. > Also, for the "FreeBSD-kernel" package, why is the kernel > configuration name downcased, and why is the opposite of "-debug-" > "-release-" as opposed to "" like all the other packages. > It's how the awk script generates the resulting plist and ucl file, which I forgot to fix. > Maybe all of the CDDL-licensed stuff should be in a (meta)package of > its own? > Yes. Good catch. Glen
signature.asc
Description: PGP signature
