CFT: FreeBSD Package Base

[Cy Schubert]

On April 29, 2019 1:09:59 PM PDT, kris at ixsystems.com wrote:
>
>
>> -----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.

I don't think we want to disable parts of base. We should build base packages that can be optionally replaced by ports with flavour @base.

Ports could be built with flavours @base, with $PREFIX /usr, or @ports (or some better name), with $PREFIX /usr/local.

Pkgbase could build the base packages negating the need for WITHOUT_* or the base packages could be excluded from base using WITHOUT_* and new ports be used to build those same packages. In this case, IMO, the implementation doesn't matter at the moment but getting straight what we want is the important point here.

If this is indeed the goal, IMO should be, we can bikeshed the implementation details in another thread on another day. I'd like to focus on what is pkgbase to look like to the end-user when we're finally done.


-- 
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.