CFT: FreeBSD Package Base

[Cy Schubert]

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.

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.


-- 
Pardon the typos and autocorrect, small keyboard in use.
Cheers,
Cy Schubert <Cy.Schubert at cschubert.com>
FreeBSD UNIX: <cy at FreeBSD.org> Web: http://www.FreeBSD.org

	The need of the many outweighs the greed of the few.