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" <[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 & 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
