Re: separation of pkgbase from pkg (was: Re: FreeBSD pkgbase vs distsets.)

+1 :-)

--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

On Fri, Feb 20, 2026 at 10:30 PM vermaden <vermaden@interia.pl> wrote:
>
> Hi,
>
> I tried to propose the same thing even before FreeBSD 15.0-RELEASE was released here:
> - https://lists.freebsd.org/archives/freebsd-pkgbase/2025-July/000596.html
>
> To have pkgbase(8) command with separate configs/paths nad SQLite database for Base System while leaving current pkg(8) with its own paths and database for third party packages ... but there was no interest.
>
> Maybe in 15.1-RELEASE then ...
>
> Some more details here:
> - https://vermaden.wordpress.com/2025/10/20/brave-new-pkgbase-world/
>
> Regards,
> vermaden
>
>
>
>
> Temat: separation of pkgbase from pkg (was: Re: FreBSD pkgbase vs distsets.)
> Data: 2026-02-20 22:09
> Nadawca: "Theron" &lt;theron.tarigo@gmail.com>
> Adresat: freebsd-hackers@freebsd.org;
>
> > On 2/6/26 16:04, Miroslav Lachman wrote:
> >> On 06/02/2026 21:07, Pat Maddox wrote:
> >>> On Fri, Feb 6, 2026, at 11:21 AM, Freddie Cash wrote:
> >>>> On Fri, Feb 6, 2026 at 10:26 AM Pat Maddox wrote:
> >>>>> On Fri, Feb 6, 2026, at 6:46 AM, Miroslav Lachman wrote:
> >>>>>> My point of view is slightly different. For me for the past
> >>>>>> 25+ the main strong feature of FreeBSD was separation
> >>>>>> of the base system from the 3rd party packages. I could
> >>>>>> do anything with
> >>>>>> cd /usr/ports/cat/port &amp; make install, portmaster,
> >>>>>> portupgrade, or pkg_add, or pkg install, or pkg upgrade
> >>>>>> and I was sure not to break anything in the base system.
> >>>>>> I can upgrade ports / packages independently on base
> >>>>>> system. I can install security patches to base without
> >>>>>> touching 3rd party packages or vice versa. But if I
> >>>>>> understand the concept of pkgbase right, there is one
> >>>>>> command to do both - pkg upgrade. I really don't like
> >>>>>> the concept of having one command (even if with
> >>>>>> different args) to maintain both. It's very easy to mistype
> >>>>>> some args and break something. But to mistype
> >>>>>> "cd /usr/src &amp; make installxxxx" or
> >>>>>> "freebsd-update upgrade -R xxx" instead of
> >>>>>> "pkg upgrade" is very rare I think.
> >>>>>> Therefore, if the base package is truly necessary,
> >>>>>> I would prefer to maintain it using a command other
> >>>>>> than "pkg."
> >>>>>>
> >>>>>> Best regards
> >>>>>> Miroslav Lachman
> >>>>>
> >>>>> I too had done a lot of scripting with dist tarballs and was
> >>>>> skeptical of pkgbase. One challenge with suggestions to
> >>>>> use separate commands is that afaik pkg doesn’t really
> >>>>> know or care what you’re installing or from where.
> >>>>> You have a list of repos, they have packages available,
> >>>>> you choose which packages to install from which repos.
> >>>>
> >>>> But, if using two separate commands, even if just a single
> >>>> hard-linked binary, is that you can hard-code the default
> >>>> options.
> >>>>
> >>>> For example, pkg would have hard-coded options to
> >>>> ignore all FreeBSD-* packages. And pkgbase would have
> >>>> hard-coded options to only work on FreeBSD-* packages.
> >>>> (Or whatever the naming convention is for base packages.)
> >>>>
> >>>> Or pkg would operate only on non-base package repos.
> >>>> And pkgbase would only operate on base package repos.
> >>>> ...
> >>>
> >>> How does it handle my custom-built repos like poudriere-local
> >>> or pkgbase-local? Do all repos have to follow a naming
> >>> convention? Is there a new config setting per repo that indicates
> >>> that it is pkgbase or ports? How to handle a scenario where a
> >>> custom repo has both pkgbase and ports?
> >>
> >> I don't think it should be controlled by the name of the
> >> repositories. Pkg / pkgbase command should destinquished
> >> between destination location. I mean what should go to / are
> >> packages for base maintained by "pkgbase" command and
> >> what should go to /usr/local are "ports" packages.
> >> ...
> >>> I submit that it is built into the program, it just requires
> >>> “enabled: false” in the config file to prevent it from
> >>> upgrading pkgbase when you do “pkg upgrade.”
> >
> > I agree with the concern over separation of base system
> > management from ported-package management. No amount
> > of abuse of the ports framework or related use of pkg command
> > should result in surprises at base system upgrade time.
> > And no matter how robust it may be in theory, I'm uncomfortable
> > with the idea of port management actions touching the same
> > /var/db/pkg/local.sqlite that must be intact for a base upgrade.
> >
> > Providing that separation can be much simpler than in the above
> > discussions:
> >
> > /usr/local/sbin/pkg continues to use /etc/pkg/ /usr/local/etc/pkg/
> > and /var/db/pkg/, with only ports repos configured, as it is in 14.
> > /usr/sbin/pkgbase shall use /etc/pkgbase/ and /var/db/pkgbase/,
> > with only base repos configured.
> >
> > Neither command shall touch the other's files. If pkg should read
> > pkgbase db (e.g. to query which base system components are
> > installed) it will be a read-only operation./usr/sbin/pkg may remain
> > as a bootstrapper/wrapper for /usr/local/sbin/pkg as it is in 14.
> >
> > As it is simple enough to implement this by oneself on top of 15 and
> > whatever 16 ends up doing, I'm not too concerned that anyone will be
> > "stuck with" a total lack of separability.
> >
> > Theron
>
>