[CFT] packaging the base system with pkg(8)

[Glen Barber]

On Thu, Mar 03, 2016 at 07:58:06PM -0500, Garrett Wollman wrote:
> <<On Wed, 2 Mar 2016 23:54:29 +0000, Glen Barber <gjb at FreeBSD.org> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-pkgbase/attachments/20160304/b6f03bbb/attachment.sig>