Re: PKGBASE Removes FreeBSD Base System Feature

On Thu, 7 Aug 2025 19:17:23 -0700
Colin Percival <cperciva@freebsd.org> wrote:

> On 8/7/25 18:20, vermaden wrote:
> > OK, Colin Percival just announced 15.0-PRERELEASE - yet the PKGBASE concept - besides 'kinda working' - does not holds to the POLA principle at all - and if anyone will chose to use PKGBASE instead of 'classic' install the 'pkg delete -af' will not only delete all the third party packages but will also WIPE almost ENTIRE BASE SYSTEM of FreeBSD ... this is not unacceptable to say the least.
> 
> POLA is inherently subjective; what astonishes one person might be exactly
> what another person expects.  In this particular case, while someone might
> indeed be astonished that "forcibly delete everything" deletes everything,
> someone else could well be astonished if "pkg delete -f clang" doesn't in
> fact delete clang.
> 
> > My 'vote' here does not changed.
> > 
> > Lets keep pkg(8) for third party packages with:
> > - /etc/pkg
> > - /usr/local/etc/pkg
> > - /var/db/pkg
> > 
> > Lets have pkgbase(8) for FreeBSD Base System PKGBASE with:
> > - /etc/pkgbase
> > - /usr/local/etc/pkgbase
> > - /var/db/pkgbase
> 
> I would like this idea, except for one wrinkle: I don't think it would work.
> In particular, packages installed from ports might depend on packages from
> the base system, so having a single tool which knows about both is necessary.

What about switching the default behavior WRT in what name it is
involed, like ex and vi?

Possibly I'm mis-understanding / mis-remenbering, but IIRC, ther is
vital flag that prevent the pkg from easily removed. Treating non-pkg
base to be vital could help. Isn't it?

Also, for PkgBase, defaulting base packages "locked" and unlock them
when really need and requested to upgrade, then, lock again once
finished would be wanted. Maybe it would be better done via bsdinstall
and/or freebsd-update, using pkg as its backend. Keeping UI and
config files as-is (just "distributions" like base.txz are broken down
into finer grain and its extentions changes to *.pkg) would minimize
pains in the wild. (As, for example, lib32.txz didn't exist in i386,
IMHO, changes in "distributin names" are acceptable on major version
ups.)


And "layering" base and ports would be also wanted.

Anything in "ports" layer can depends on anything in "base" layer,
but components in "base" layer should be restricted NOT to depends on
enything in "ports" layer. Maybe the exception would be external
tool chains to build base. Possibly Rust required for future LinuxKPI?

> -- 
> Colin Percival
> FreeBSD Release Engineering Lead & EC2 platform maintainer
> Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid


-- 
Tomoaki AOKI    <junchoon@dec.sakura.ne.jp>