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

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 <[email protected]> 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+ years
>>>>> 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 & 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 & 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