On 7/29/25 19:18, Shawn Webb wrote:
On Wed, Jul 30, 2025 at 02:28:35AM +0200, vermaden wrote:
Hi,
after short discussion here:
- https://github.com/freebsd/pkg/issues/2485
I got REALLY concerned.
One of THE features and selling points of a FreeBSD UNIX system is the
'untouchable' Base System.
Without PKGBASE all the features are preserved.
But when You convert to PKGBASE its ... GONE!
Consider this command:
# pkg delete -af
What it does?
It removes all third party packages on 'classic' FreeBSD system without
touching the FreeBSD Base System.
What the same "pkg delete -af" command does on a PKGBASE FreeBSD system?
It kills/destroys almost all of the FreeBSD Base System and leaves only two
PKGBASE packages called:
- FreeBSD-clibs
- FreeBSD-runtime
All the rest of Base System is GONE. Destroyed.
Hey vermaden,
As mentioned in the GitHub ticket, it appears there might be some room
for discussion on which base packages ought to be marked vital and if
the current list (of two) should be expanded.
I suspect there could also be room for discussion on technical
measures pkg could adopt to help mitigate issues like this.
I myself don't have much in the way of suggestions on either topic of
discussion. I'm simply hoping this email moves the needle forward in a
positive direction.
Fortunately pkgbase doesn't seem to be changing what is IMHO the real
differentiator of BSD - the fact that the tools, userland and kernel are
all part of one coherent development process. This feels like a natural
progression to me.
To the original point of ensuring you can't nuke the entire base system
by accident. one idea i didn't see on the github thread (apologies if i
missed it) is adding a config parameter to the repo config. So perhaps
a FreeBSD-base.conf could look like so:
FreeBSD-base: {
url: "pkg+https://pkg.FreeBSD.org/${ABI}/base_release_3";,
mirror_type: "srv",
signature_type: "fingerprints",
fingerprints: "/usr/share/keys/pkg",
enabled: yes
protected: yes
}
where "protected" would prevent packages from getting outright deleted?
I could even see this getting extended to private repo configs - for
example i may want to make sure people can't uninstall the software i
deploy to my site using our internal repo.
-pete
--
Pete Wright
[email protected]
