Splitting these out to their own packages allows them to be used in other contexts without having to pull in the whole of runtime and/or utilities. For instance, I wanted a container image containing just /sbin/pfctl. This would be used with the Kubernetes kube-proxy utility to manage service routing for a FreeBSD Kubernetes cluster. Unfortunately, pfctl depends on libraries currently contained in runtime and utilities which adds ~150MB of binaries and other libraries to the image. Installing runtime and/or utilities will automatically add the required library packages and upgrading e.g. runtime from pre-split to post-split works as expected.
π
For similar reasons, I also plan to split out /etc from runtime so that I can cleanly install things like /etc/passwd and /etc/termcap.small without fighting the packaging tools.
(In reply to dfr from comment #2) Care to explain more ?
manu@skull:~ $ pkg which -p pfctl /sbin/pfctl was installed by package FreeBSD-pf-14.a2.20230821073851 manu@skull:~ $ ldd /sbin/pfctl /sbin/pfctl: libm.so.5 => /lib/libm.so.5 (0x2aa18f20000) libmd.so.6 => /lib/libmd.so.6 (0x2aa19115000) libnv.so.1 => /lib/libnv.so.1 (0x2aa19da4000) libc.so.7 => /lib/libc.so.7 (0x2aa1bb57000) [vdso] (0x2aa18168000) manu@skull:~ $ pkg which /lib/libm.so.5 /lib/libm.so.5 was installed by package FreeBSD-clibs-14.a2.20230821073851 manu@skull:~ $ pkg which /lib/libmd.so.6 /lib/libmd.so.6 was installed by package FreeBSD-runtime-14.a2.20230821073851 manu@skull:~ $ pkg which /lib/libnv.so.1 /lib/libnv.so.1 was installed by package FreeBSD-runtime-14.a2.20230821073851 manu@skull:~ $ pkg which /lib/libc.so.7 /lib/libc.so.7 was installed by package FreeBSD-clibs-14.a2.20230821073851 pfctl isn't your problem I think
It's likely /sbin/pfctld which depends on libiverbs and libmlx5.
Anyway, I don't think that we should split binaries and lib from runtime. The utility package clearly needs more split, it's the default go to package (it was runtime before) so there is a lot of crap. I don't want to go back when we started pkgbase and had one package per lib.
(In reply to Emmanuel Vadot from comment #5) Meh, meant to say pflogd
For this use case I think that creating a FreeBSD-tcpdump package that will contain tcpdump and pflogd (and maybe other stuff, haven't look that much) is the best way.
I build a sequence of container images with two important ones early in the sequence that explicitly avoid installing runtime. These are intended to support static and dynamically linked workloads which don't need (or want) shell access or any of the other binaries installed by runtime. This restricted base serves to keep the download size and storage cost of the images as small as possible as well as reducing the attack surface inside the container. These workloads still need access to things like /etc/passwd and sometimes /etc/termcap and I work around the packaging system to cherry pick the bits I want from runtime. This means that later layers which do install runtime leave things like /etc/master.passwd.pkgsave which I have to clean up. Probably 'fighting the packaging tools' is an exaggeration. If splitting out all the libraries is a step too far, would there be an objection to moving a few libs from runtime to clibs? Currently, I cherry pick libz and libcrypt from the runtime package - these could move to clibs without ballooning the package count.
FreeBSD-runtime is 8MB right now, it's not big. Also we will never be able to satisfy everyone with pkgbase, you have some really specific need it seems.
also going that tiny is useful for container, but may be confusing for full blown OS, at some point you can probably use the FILES_IGNORE_GLOB and FILES_IGNORE_REGEX to go further. (note that this is not documented, and should be) This will skip installation of some files at install time. To use it in pkg.conf one can simply set FILES_IGNORE_GLOB=["*/man/*", "*.a"] etc
I tend to think about the uncompressed size but I agree that runtime is already small and I appreciate the work that went into finding this sweet spot. I still think its useful to run some workloads in a shell-free environment and I think I can achieve that without adding too much confusion, e.g. by fine tuning the split between clibs and runtime.
shell-free env would be good to have I agree, I have some test here with only nsd and clibs that work great. Maybe there is a few libs that we could move from runtime to clibs.
I think I only really wanted to move libcrypt.so and libz.so out from runtime - these are both used by nginx and libcrypt.so is used by busybox which is fairly uninteresting for most people but I do use it for running podman system tests (which were written for the Linux alpine distro which is based on busybox).
Ok, I don't think that this change would cause problems and it's not a lot of libs so I'm good for this.