Date: Mon, 29 Apr 2019 17:25:54 -0700 From: Cy Schubert <Cy.Schubert@cschubert.com> To: Garrett Wollman <wollman@csail.mit.edu> Cc: freebsd-pkgbase@freebsd.org Subject: Re: CFT: FreeBSD Package Base Message-ID: <8B10CAFD-88A1-4DAD-92C2-93F5DE4B3402@cschubert.com> In-Reply-To: <23751.25464.908633.101215@khavrinen.csail.mit.edu> References: <freebsd-rwg@gndrsh.dnsmgr.net> <201904291441.x3TEfMid072751@gndrsh.dnsmgr.net> <201904291931.x3TJV73d079802@slippy.cwsent.com> <23751.25464.908633.101215@khavrinen.csail.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On April 29, 2019 1:50:00 PM PDT, Garrett Wollman <wollman@csail=2Emit=2Eed= u> wrote: ><<On Mon, 29 Apr 2019 12:31:07 -0700, Cy Schubert ><Cy=2ESchubert@cschubert=2Ecom> said: > >> The discussion about granularity begs the question, why pkgbase in >the=20 >> first place? My impression was that it allowed people to select which > >> components they wanted to either create a lean installation or mix >and=20 >> match base packages and ports (possibly with flavours to install in=20 >> /usr rather than $LOCALBASE) such that maybe person A wanted a stock=20 >> install while person B wanted to replace, picking a random example, >BSD=20 >> tar with GNU tar=2E Isn't that the real advantage of pkgbase? > >No=2E 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=2E > >Consider my position: I have about 30 servers (and another ~10 jails) >that all run the same local build of FreeBSD=2E 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"=2E 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=2E > >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=2E > >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=2E 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=2E (And I've said as much in various surveys=2E) > >-GAWollman An anaconda-like installer for freebsd could do that=2E Also a perfect job= for cfengine or ansible=2E Deploy and use a playbook to enforce policy=2E You don't need to break up base into packages (not arguing against packagi= ng) to gain the benefits of configuration management=2E As for updating, freebsd-update is mostly there to accomplish your require= ment without pkgbase=2E Which begs the question, if we're simply replacing= freebsd-update and it does most of what we want why the extra effort? Unle= ss we want to solve more than just this problem? Which BTW I think we do=2E I've seen pkgbase as a building block to build an anaconda-like installer = complete with scripting language=2E The ability to pick and choose packages= as many Linux distros do is one part of it=2E --=20 Pardon the typos and autocorrect, small keyboard in use=2E Cheers, Cy Schubert <Cy=2ESchubert@cschubert=2Ecom> FreeBSD UNIX: <cy@FreeBSD=2Eorg> Web: http://www=2EFreeBSD=2Eorg The need of the many outweighs the greed of the few=2E
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8B10CAFD-88A1-4DAD-92C2-93F5DE4B3402>