CFT: FreeBSD Package Base

[Rodney W. Grimes]

> On April 29, 2019 1:50:00 PM PDT, Garrett Wollman <wollman at csail.mit.edu> wrote:
> ><<On Mon, 29 Apr 2019 12:31:07 -0700, Cy Schubert
> ><Cy.Schubert at cschubert.com> said:
> >
> >> The discussion about granularity begs the question, why pkgbase in
> >the 
> >> first place? My impression was that it allowed people to select which
> >
> >> components they wanted to either create a lean installation or mix
> >and 
> >> match base packages and ports (possibly with flavours to install in 
> >> /usr rather than $LOCALBASE) such that maybe person A wanted a stock 
> >> install while person B wanted to replace, picking a random example,
> >BSD 
> >> tar with GNU tar. Isn't that the real advantage of pkgbase?
> >
> >No.  The "real" advantage of pkgbase is that it allows the distributor
> >of a customized version of the operating system to support binary-only
> >updates, without all the (non-trivial) infrastructure of running a
> >custom FreeBSD-update builder and distribution server.
> >
> >Consider my position: I have about 30 servers (and another ~10 jails)
> >that all run the same local build of FreeBSD.  Right now, the only
> >reliable way to update them is to NFS-mount /usr/src and /usr/obj from
> >my build server, and run a (slow) "make installworld".  It would
> >literally save me hours out of every upgrade (or base-system security
> >fix) to be able to install compressed binary packages downloaded over
> >http, and I'd have better security because binary packages are
> >signed.
> >
> >For my use case, I don't much care what the granularity is, so long as
> >I can safely upgrade (or update) the kernel independently of the
> >userland and independently of third-party packages -- just two
> >packages (kernel and userland) would suffice, although I'd probably
> >prefer the runtime libraries to be in a separate package just for
> >safety.
> >
> >I'm not distributing packages to third parties, I just want to be able
> >to install and upgrade my packages on my fleet of servers and jails
> >quickly and safely.  This is not the entirety of the use cases the
> >project as a whole needs to support, but it's a major *end-user* use
> >case.  (And I've said as much in various surveys.)
> >
> >-GAWollman
> 
> An anaconda-like installer for freebsd could do that. Also a perfect job for cfengine or ansible. Deploy and use a playbook to enforce policy.

https://anaconda-installer.readthedocs.io/en/latest/

> You don't need to break up base into packages (not arguing against packaging) to gain the benefits of configuration management.
> 
> As for updating, freebsd-update is mostly there to accomplish your requirement without pkgbase. Which begs the question,  if we're simply replacing freebsd-update and it does most of what we want why the extra effort? Unless we want to solve more than just this problem? Which BTW I think we do.
> 
> I've seen pkgbase as a building block to build an anaconda-like installer complete with scripting language. The ability to pick and choose packages as many Linux distros do is one part of it.

What seems to be confusing here is that TrueOS/FreeNAS's
"package base" and the work that has been on going IN
the FreeBSD base system for 2+ (3?) years are 2 
different things with different goal sets and this
CFT has very much muddied that water as to what is
what.

Is there an advocation by iXsystems and TrueOS to replace
what is in the base system now with this new Go implementation
in ports?

Are they orthagonal?  If so can we please rename one?


-- 
Rod Grimes                                                 rgrimes at freebsd.org