Re: pkgbase(8)

On 2/22/26 06:08, Graham Perrin wrote:
> On 20/02/2026 21:29, vermaden wrote:
>> … 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 …
>
> -1 to creating a pkgbase(8) tool that must be used separately from 
> existing tools such as pkg-upgrade(8).
The proposed pkgbase command is the same program as pkg(8) but acting on 
different configurations.  There is nothing separate about 
pkg-upgrade(8) which describes the upgrade sub-command of any instance 
of this program.

Performing base system upgrade without caring what has happened or will 
happen to ports packages is the feature that should be preserved.

Total separation at file level is not the only way to accomplish that.  
For example, using a single pkg(8):
- FreeBSD-base packages are always treated as though locked unless a 
specific flag, consistent across all relevant pkg subcommands, is 
provided - the proposal to use "vital" flags only partially addresses this.
- A second database /var/db/pkg/base.sqlite (or so) is a backup or 
subset of local.sqlite, that may only be modified when this "modify 
base" flag is in effect.

> The nature of separation should have been understood when official 
> packaging began in 2023, when Bapt described the separate FreeBSD-base 
> repo.
No change here.

> file /var/db/pkg/repos/FreeBSD-base/db
>
> It's an SQLite 3.x database.
This is the database of what is available in the repo.  The database of 
installed packages is /var/db/pkg/local.sqlite .