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

(Dropped freebsd-pkgbase ML from CC as I'm not subscribed.)

+1 for the idea. Looks saner.

And no need to maintain 2 individual pkg(8). Single binary working like
vi and ex (hardlink from one to another, and work in different mode
WRT what name it's started up).


On Fri, 20 Feb 2026 22:29:35 +0100
vermaden <[email protected]> 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;[email protected]>
> Adresat: [email protected]; 
> 
> > 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


-- 
Tomoaki AOKI    <[email protected]>