CFT: FreeBSD Package Base

[kris at ixsystems.com]

> -----Original Message-----
> From: Cy Schubert <Cy.Schubert at cschubert.com>
> Sent: Monday, April 29, 2019 3:31 PM
> To: Rodney W. Grimes <freebsd-rwg at gndrsh.dnsmgr.net>
> Cc: Kris Moore <kris at ixsystems.com>; FreeBSD Stable <freebsd-
> stable at freebsd.org>; freebsd-ports at freebsd.org; Goran Mekić
> <meka at tilda.center>; freebsd-hackers at freebsd.org; FreeBSD Current
> <freebsd-current at freebsd.org>; freebsd-pkgbase at freebsd.org; freebsd-
> pkg at freebsd.org; Emmanuel Vadot <manu at bidouilliste.com>
> Subject: Re: CFT: FreeBSD Package Base
> 
> In message <201904291441.x3TEfMid072751 at gndrsh.dnsmgr.net>, "Rodney
> W.
> Grimes"
> writes:
> > > On Mon, Apr 29, 2019 at 10:09 AM Rodney W. Grimes <
> > > freebsd-rwg at gndrsh.dnsmgr.net> wrote:
> > >
> > > > >
> > > > > Correct, this is ZFS only. And it's something we're using
> > > > > specific to
> > > > FreeNAS / TrueOS, which is why I didn't originally mention it as
> > > > apart of our CFT.
> > > >
> > > > Then please it is "CFT: FreeNAS/TrueOS pkg base, ZFS only",
> > > > calling this FreeBSD pkg base when it is not was wrong, and miss
> > > > leading.
> > > >
> > >
> > > Sorry, I disagree.
> > Which is fine.
> >
> > > This pkg base is independent of the ZFS tool we're using to wrangle
> > > boot-environments. Hence why it wasn't mentioned in the CFT.
> > > These base packages work the same as existing in-tree pkg base on
> > > UFS, no difference. If anything are probably safer due to being able
> > > to update all of userland in single extract operation, so you don't
> > > have out of order extraction of libc or some such.
> >
> > You missed the major string change and focused on the edge, No comment
> > on calling iXsystems :stuff: FreeBSD instead of FreeNAS/TrueOS?
> >
> > That was the major point of my statement, your miss leading the user
> > community, you yourself said this would never be imported into FreeBSD
> > base, so I see no reason that it should be called "FreeBSD package
> > Base", as it is not, that is a different project.
> 
> Taking the last comment on this thread to ask a question and maybe refocus
> a little.
> 
> 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?
> 
> If OTOH it's binary updates V 2.0, what's the point? I'm a little
rhetorical here
> but you get my point. If I want ipfw instead pf or ipfilter instead of the
others
> I should have the freedom. Similarly if I want vim instead of vi I should
have
> the choice to install vim as /usr/bin/vi. Otherwise all the effort to
replace
> binary updates makes no sense.
> 
> 

That is a fantastic point. The way we've been doing it is with the
os/userland meta-pkg. Using ZoL as an example, we build userland with the
ZFS options disabled, then added a ZOL option to userland, which makes
sysutils/zol a depend of userland meta-pkg.

Over time I can see this becoming a trend, were we replace bits of base (by
setting WITHOUT_*) and injecting the ports version of those bits via regular
pkg depends. Good candidates would be tools like svn / git, mailers,
compilers, shells, editors, etc.

Ironically this was an issue in the current pkg base implementation that led
us to flattening out the userland package. We found that run-time removal of
specific packages just flat out didn't work. I.E. pkg delete FreeBSD-zfs
didn't work without re-compiling all the things in advance using the proper
WITHOUT_* flags. Same for trying to remove RADIUS support, or others. Too
many things tended to change in seemingly un-related packages, you'd almost
need a full set of flavors for a lot of WITH/WITHOUT combinations for that
to be viable. 

Additionally, this was why we combined base/ports into a single pkg repo. By
building both through poudriere, it makes it possible to properly interject
depends and upgrade in lock-step. Really changes the paradigm of what is
base/ports in a positive way IMHO.