On April 29, 2019 1:50:00 PM PDT, Garrett Wollman <[email protected]> wrote: ><<On Mon, 29 Apr 2019 12:31:07 -0700, Cy Schubert ><[email protected]> 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 <[email protected]> FreeBSD UNIX: <[email protected]> Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-pkgbase To unsubscribe, send any mail to "[email protected]"
