From nobody Sat Feb 21 02:30:27 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 4fHrh30yJxz6TPQk for ; Sat, 21 Feb 2026 02:30:43 +0000 (UTC) (envelope-from tomek@cedro.info) Received: from mail-yx1-xb129.google.com (mail-yx1-xb129.google.com [IPv6:2607:f8b0:4864:20::b129]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4fHrh25yJMz4NKs for ; Sat, 21 Feb 2026 02:30:42 +0000 (UTC) (envelope-from tomek@cedro.info) Authentication-Results: mx1.freebsd.org; none Received: by mail-yx1-xb129.google.com with SMTP id 956f58d0204a3-64aedd812baso2505501d50.3 for ; Fri, 20 Feb 2026 18:30:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cedro.info; s=google; t=1771641041; x=1772245841; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=XPczwA+mt6yE9w/HcOlU8LUAhc7yX5PMXEnEb9DWcx4=; b=a/xsUonr85rM30D/n0pQdvENl45nyqpv6RHX8A/ggzRounTV8anQ32e2FgjPGhPnU1 joyG32d/C39a2DTkXwo6ZekMAMk7OZHekx4ixrEU/miAzIkvU92+sMnjVez4yEE95joZ mFuqCo9IncT0UM8AbMcpz4bTMxkoSOjYm0a26RIsKWHX3gxK8aDhKPwCpTvHyCDRIHOn diMZRLjc48lIh7CuImXUseFdxF4QT7ONY60bGH2FQ6Z3e/UmaPu4KO2sdTHvV/z/lC8K JlEyHcnfFqidJD10fq5hjaznusz0TGtvjj+sDG6i4B6h5aM23F6OTeYIMaCwC10HIDkJ f1mQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771641041; x=1772245841; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=XPczwA+mt6yE9w/HcOlU8LUAhc7yX5PMXEnEb9DWcx4=; b=e1Z6mv6Iwqv5POSaHY7iwTOfD7FE0gmMHFHqh2m8ivh3Qt3Cy+6ghZFAPqYqheoyyz THEnR8WR9uPS1AR1zwaSKeIPAfligVQrU+JPN0bHdSn4uZfhzhTU1p4XXhqI/+KEOnbh vo9NgMIahXdX2SZ+HHgxWrHqKkJGK7bMn2DZT9SgUkhCJh+V9PkhjpRyt1fleI6RREl4 jBuWrv7eW7SdOOhrH6SFXoiyTKPsec2F5HsZFjtzXLZtsVLTZumPsLYRJo6uEd4NPkys 36xhQRdgPbIS1YPmE0JaQBAuB0HnERgBhR2GUrVmsH4S2gAbEOvtc7AFWftS78xmF+tR XSWg== X-Forwarded-Encrypted: i=1; AJvYcCWsgUUDUe+v3nqWmWaowQmoqJJDYzEMOpAnoWdy6BMCKy3K00EW9ekOKTsMoPHlTyTbYcTH11zKWa/Db/OjiFE=@freebsd.org X-Gm-Message-State: AOJu0YyObyr8k55rCTj0It7zX8rSwdrDzkMM6Dki9fjPzd/UdW3bOL5A ppao9vYWVzEl+svP0Q6gCRGBefG/n8KjxATlMP515r6kfQNpQK7V+qxATE/1b0k6Gq4cdwDFQUv Ti/Y= X-Gm-Gg: AZuq6aKvR+pyLFPs1lGlQzicn8Q3RKjKvHO1rj2cz/xX270sebpe7y1HL30Q/y8WSwF KjeHnpFI2GBPOVqZDsb04u10muguyOgzBmhnXqhieQKe03rtY3pl/zqCyQpUor6QE4p7CSrUDTt llAhvFIWZQkGzXRsXO61CaBdTFv0VHDO3gE8t38mD+3LXv2GU+5QMG+b0My/cZOvDuRXcp2NCnj JWYGi4Cl2DgR/0RhAPEvdX6QVlNEVrCDWZ95Kqasz5BPmXcPzgyFviUhv/L8aefxqTjFQdlbXVX Sk7WPe7767Q0npfesSZKMcdxKDxlfe/9G8vTqC3rwaJ0jxVLZ0se1j17eMQQEo3fpBMA/nXEbME umSUTaQYe1JnZi5IOU6lMvHtvAc1Zdmp530lN17aBq5OZ/cqdA43iroFftg4c1MUxJ1HE4KzhWS jWLZZ8y+JybBB28G43OX4bWJOKdNDekeAdl8tYEAf8TDf51Pfwue4SR0Q= X-Received: by 2002:a05:690e:142:b0:649:97d9:cf1f with SMTP id 956f58d0204a3-64c78e3f750mr1343776d50.44.1771641040872; Fri, 20 Feb 2026 18:30:40 -0800 (PST) Received: from mail-yx1-f49.google.com (mail-yx1-f49.google.com. [74.125.224.49]) by smtp.gmail.com with ESMTPSA id 956f58d0204a3-64c7a3889e6sm450703d50.19.2026.02.20.18.30.38 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 20 Feb 2026 18:30:39 -0800 (PST) Received: by mail-yx1-f49.google.com with SMTP id 956f58d0204a3-649df393c04so2436589d50.1 for ; Fri, 20 Feb 2026 18:30:38 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCWYId1RI+jFGOzeYFycNBB3djkbJeg0r46DLabZVi9SqFoEB4IMg+IMzRD2xnNSk6y8n5cPfkia4Lht7ldv1MQ=@freebsd.org X-Received: by 2002:a53:5a05:0:b0:646:c661:8f95 with SMTP id 956f58d0204a3-64c78e3f7c8mr1239348d50.42.1771641038479; Fri, 20 Feb 2026 18:30:38 -0800 (PST) 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 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> In-Reply-To: From: Tomek CEDRO Date: Sat, 21 Feb 2026 03:30:27 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AaiRm51y1qAuxUQvLAKmwK2z1DQcL0xAcFo9fx5-26mUmZF20FCi2jiIajdzxFM Message-ID: Subject: Re: separation of pkgbase from pkg (was: Re: FreeBSD pkgbase vs distsets.) To: vermaden Cc: Theron , "freebsd-hackers@freebsd.org" , freebsd-pkgbase@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_RCPT(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4fHrh25yJMz4NKs X-Spamd-Bar: ---- +1 :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info On Fri, Feb 20, 2026 at 10:30=E2=80=AFPM vermaden wro= te: > > Hi, > > I tried to propose the same thing even before FreeBSD 15.0-RELEASE was re= leased here: > - https://lists.freebsd.org/archives/freebsd-pkgbase/2025-July/000596.htm= l > > To have pkgbase(8) command with separate configs/paths nad SQLite databas= e for Base System while leaving current pkg(8) with its own paths and datab= ase 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 distset= s.) > Data: 2026-02-20 22:09 > Nadawca: "Theron" <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=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 > >>>>> 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 > >>> =E2=80=9Cenabled: false=E2=80=9D in the config file to prevent it fro= m > >>> upgrading pkgbase when you do =E2=80=9Cpkg upgrade.=E2=80=9D > > > > 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 > >