From nobody Fri Feb 20 21:29:35 2026 X-Original-To: freebsd-pkgbase@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4fHk0p10vzz6T1W9; Fri, 20 Feb 2026 21:29:46 +0000 (UTC) (envelope-from vermaden@interia.pl) Received: from smtpo49.interia.pl (smtpo49.interia.pl [217.74.67.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4fHk0m5Jvrz3jh2; Fri, 20 Feb 2026 21:29:44 +0000 (UTC) (envelope-from vermaden@interia.pl) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=interia.pl header.s=dk header.b=qGoKTwwm; dmarc=pass (policy=quarantine) header.from=interia.pl; spf=pass (mx1.freebsd.org: domain of vermaden@interia.pl designates 217.74.67.49 as permitted sender) smtp.mailfrom=vermaden@interia.pl Date: Fri, 20 Feb 2026 22:29:35 +0100 From: vermaden Subject: Re: separation of pkgbase from pkg (was: Re: FreeBSD pkgbase vs distsets.) To: Theron , "freebsd-hackers@freebsd.org" , freebsd-pkgbase@FreeBSD.org X-Mailer: interia.pl/pf09 In-Reply-To: <1588b965-b77e-43d0-8e7d-f522994af658@gmail.com> References: <0iqhe92aheNJohSnhh8-hXkXhQsaRG4D64nLTlTSIPgd6Iit07IwlMwmn-mIS-Qtp9KuZElphybTlYDIVTUDcVGpHWaUbQVGPKt53NSL5Jg=@proton.me> <1678741437.20260206163514@yahoo.com> <07af999d-3c7b-4fe2-8ed2-a37cf89b663b@quip.cz> <3089fd20-9978-4d0f-b6d8-0ed51742e471@quip.cz> <1588b965-b77e-43d0-8e7d-f522994af658@gmail.com> X-Originating-IP: 45.148.42.20 Message-Id: List-Id: Packaging the FreeBSD base system List-Archive: https://lists.freebsd.org/archives/freebsd-pkgbase List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-pkgbase@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=interia.pl; s=dk; t=1771622977; bh=5UNywb2/P6Ti50HTOUzXfedF7iOqKWrl5WbN9BDkPLw=; h=Date:From:Subject:To:Message-Id:MIME-Version:Content-Type; b=qGoKTwwmYLex8qwlaXmU2gIgycemjPbbUUHlfOzWft3YBGInYxg7MZRHlmOA10bf2 98o65L0zfuK7Kn8IEvIWgEIttKQY0jWAYN1HIXAPxIpkwL4ZI4ntbu6ujD9hvxh9yb 8wdKjGHFCT+qB8x9Qd/54k/hJacaglOhucqgFZkI= X-Spamd-Result: default: False [-3.49 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.990]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[interia.pl,quarantine]; R_DKIM_ALLOW(-0.20)[interia.pl:s=dk]; R_SPF_ALLOW(-0.20)[+ip4:217.74.64.0/22]; MIME_GOOD(-0.10)[text/plain]; RWL_MAILSPIKE_GOOD(-0.10)[217.74.67.49:from]; ONCE_RECEIVED(0.10)[]; FREEMAIL_TO(0.00)[gmail.com,freebsd.org,FreeBSD.org]; SUSPICIOUS_AUTH_ORIGIN(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; FREEMAIL_FROM(0.00)[interia.pl]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_ENVFROM(0.00)[interia.pl]; HAS_XOIP(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[interia.pl:+]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org,freebsd-pkgbase@freebsd.org]; TAGGED_RCPT(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; ASN(0.00)[asn:16138, ipnet:217.74.64.0/22, country:PL]; DWL_DNSWL_NONE(0.00)[interia.pl:dkim] X-Rspamd-Queue-Id: 4fHk0m5Jvrz3jh2 X-Spamd-Bar: --- Hi, I tried to propose the same thing even before FreeBSD 15.0-RELEASE was rele= ased 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 databas= e 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" <theron.tarigo@gmail.com> Adresat: freebsd-hackers@freebsd.org;=20 > 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=E2=80=AFAM 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=20 >>>>> skeptical of pkgbase. One challenge with suggestions to >>>>> use separate commands is that afaik pkg doesn=E2=80=99t really >>>>> know or care what you=E2=80=99re 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=20 >>> =E2=80=9Cenabled: false=E2=80=9D in the config file to prevent it from >>> upgrading pkgbase when you do =E2=80=9Cpkg upgrade.=E2=80=9D >=20 > 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=20 > /var/db/pkg/local.sqlite that must be intact for a base upgrade. >=20 > Providing that separation can be much simpler than in the above > discussions: >=20 > /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. >=20 > 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. >=20 > As it is simple enough to implement this by oneself on top of 15 and=20 > whatever 16 ends up doing, I'm not too concerned that anyone will be=20 > "stuck with" a total lack of separability. >=20 > Theron