| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 23 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 46:57:38 |
| Calls: | 583 |
| Files: | 1,138 |
| Messages: | 111,071 |
On 7/29/25 18:15, George Michaelson wrote:.
Isn't this precisely what locked packages are designed to prevent?
I thought locking packages was intended to stop any modification to
them so both upgrades and removal would not happen.
Another topic is its debatable 'if' -f should bypass a lock or not. Considering -f is supposed to be able to let pkg delete itself and
perform deletes that mess up dependencies, I'd say it shouldn't be
expected that it keeps things safe from other damaging removals; an interactive warning seems justifiable when a request to 'break things' occurs.
Outside of an upgrade tool, I would think locking "base" packages was .=
sensible?
-G
Hi,ntouchable' Base System.
=20
after short discussion here:
- https://github.com/freebsd/pkg/issues/2485
=20
I got REALLY concerned.
=20
One of THE features and selling points of a FreeBSD UNIX system is the 'u=
=20ouching the FreeBSD Base System.
Without PKGBASE all the features are preserved.
=20
But when You convert to PKGBASE its ... GONE!
=20
Consider this command:
=20
# pkg delete -af
=20
What it does?
=20
It removes all third party packages on 'classic' FreeBSD system without t=
=20wo PKGBASE packages called:
What the same "pkg delete -af" command does on a PKGBASE FreeBSD system?
=20
It kills/destroys almost all of the FreeBSD Base System and leaves only t=
=20
- FreeBSD-clibs
- FreeBSD-runtime
=20
All the rest of Base System is GONE. Destroyed.
I just took a look ate
https://pkg.freebsd.org/FreeBSD:15:amd64/base_latest/ and I am instantly disappointed. I was a fan of the idea, but seeing how they decided to mak=
one package for each item is a massive bummer. Why would you split it upt
this way? When when you install the Mozilla Firefox via package, you don'=
install every file individually as a separate package.
It's the same concept for FreeBSD. All these files make up a single entit=y
"FreeBSD" the operating system. Why on earth would you install each item that's required to run FreeBSD as a separate package? All this will do is create increased overhead when installing the system (as each package mus=t
go through it's verification and transaction process), and all sorts of trouble down the line when dependency hell sets in.
design choice.ntouchable' Base System.
On 7/30/2025 3:30 AM, Baptiste Daroussin wrote:
On Wed 30 Jul 02:28, 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 'u=
untouchable is really subjective and has always been, there are so many b=uild
options and one of the selling point for many is the customizability, in particular for the wildly deploy use case of appliances.ouching the FreeBSD Base System.
But even on desktops people keeps tweaking the build options...
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 t=
No it remove all the packages. semantic matters.wo PKGBASE packages called:
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 t=
- FreeBSD-clibseeBSD-rescue package and its also removed.
- FreeBSD-runtime
This is why the vital flag are designed for.
All the rest of Base System is GONE. Destroyed.
You do not even have vi(1) editor ad /rescue is separate not protected Fr=
WTF?!the POLA now?
POLA is the principle that made FreeBSD such predictable system. Where is=
Why the same *pkg delete -af* command on 'classic' FreeBSD system without=PKGBASE only removes all third party packages and the same *pkg delete -af=
Its crazy ...iscuss
Before jumping straight into making a drama, maybe ask for the plan? or d=
with people involved, or even better propose some help?ll be
The plan is the following for years: either create meta packages which wi=
flagged as vital for various combinaison of pkgbase: base, base-minimal, base-oci etc., etc. and use groups (marked as vital as well) if they are =ready
by then. This part has been delayed because: groups are now ready yet in =pkg but
might be there by the time 15.0-RELEASE is there.
Bapt
On Sun, Aug 3, 2025, 4:19=E2=80=AFPM Daniel Morante <daniel@morante.net> =wrote:
keI just took a look at
https://pkg.freebsd.org/FreeBSD:15:amd64/base_latest/ and I am instantly
disappointed. I was a fan of the idea, but seeing how they decided to ma=
'tone package for each item is a massive bummer. Why would you split it up
this way? When when you install the Mozilla Firefox via package, you don=
chinstall every file individually as a separate package.
But you do install a boatload of related packages...
It's the same concept for FreeBSD. All these files make up a single
entity "FreeBSD" the operating system. Why on earth would you install ea=
doitem that's required to run FreeBSD as a separate package? All this will=
sis create increased overhead when installing the system (as each package
must go through it's verification and transaction process), and all sort=
of trouble down the line when dependency hell sets in.If it hasn't set in when a new dependency was free and it's cost hidden, chances are we are safe. One big problem wi freebsd in embedded space is getting a good subset. Fine grain gives that a fighting chance.
Warner
s the POLA now?This is not the FreeBSD way. Very sad, concerned, and disappointed at
this design choice.
On 7/30/2025 3:30 AM, Baptiste Daroussin wrote:
On Wed 30 Jul 02:28, 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.
untouchable is really subjective and has always been, there are so many = build
options and one of the selling point for many is the customizability, in
particular for the wildly deploy use case of appliances.
But even on desktops people keeps tweaking the build options...
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.
No it remove all the packages. semantic matters.
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
This is why the vital flag are designed for.
All the rest of Base System is GONE. Destroyed.
You do not even have vi(1) editor ad /rescue is separate not protected F= reeBSD-rescue package and its also removed.
WTF?!
POLA is the principle that made FreeBSD such predictable system. Where i=
t PKGBASE only removes all third party packages and the same *pkg delete -a=
Why the same *pkg delete -af* command on 'classic' FreeBSD system withou=
ready
Its crazy ...
Before jumping straight into making a drama, maybe ask for the plan? or = discuss
with people involved, or even better propose some help?
The plan is the following for years: either create meta packages which w= ill be
flagged as vital for various combinaison of pkgbase: base, base-minimal,
base-oci etc., etc. and use groups (marked as vital as well) if they are=
pkg butby then. This part has been delayed because: groups are now ready yet in=
might be there by the time 15.0-RELEASE is there.
Bapt
I think the .tgz blobs used by NetBSD are a good example of the biggest blobbyness you want. rescue and base are the minimal safe set. games X11, debug and documentation are long standing extras.
For now, I like the direction the intent is going: yes, a lot of parts.is
But, separating their "head" so pkg delete -f is "safe" for ordinary use =
a good plan (if that IS the plan)
I just took a look atWhat benefit is there to installing setuid program lpr on an
https://pkg.freebsd.org/FreeBSD:15:amd64/base_latest/ <https://pkg.freebsd.org/FreeBSD:15:amd64/base_latest/> and I am
instantly disappointed. I was a fan of the idea, but seeing how they
decided to make one package for each item is a massive bummer. Why would
you split it up this way? When when you install the Mozilla Firefox via package, you don't install every file individually as a separate package.
It's the same concept for FreeBSD. All these files make up a single
entity "FreeBSD" the operating system. Why on earth would you install
each item that's required to run FreeBSD as a separate package? All this will do is create increased overhead when installing the system (as each package must go through it's verification and transaction process), and
all sorts of trouble down the line when dependency hell sets in.
This is not the FreeBSD way.a Very sad, concerned, and disappointed at
this design choice.
(1)and /var/db/pkg dirs for configuration.
Keep pkg(8) for third party packages with /etc/pkg and /usr/local/etc/pkg
Use separate pkgbase(8) with /etc/pkgbase and /usr/local/etc/pkgbase and/var/db/pkgbase dirs for managing PKGBASE packages. By pkgbase(8) I have
On 3 Aug, Daniel Morante wrote:
I just took a look at
https://pkg.freebsd.org/FreeBSD:15:amd64/base_latest/ <https://pkg.freebsd.org/FreeBSD:15:amd64/base_latest/> and I am
instantly disappointed. I was a fan of the idea, but seeing how they decided to make one package for each item is a massive bummer. Why would you split it up this way? When when you install the Mozilla Firefox via package, you don't install every file individually as a separate package.
It's the same concept for FreeBSD. All these files make up a single
entity "FreeBSD" the operating system. Why on earth would you install
each item that's required to run FreeBSD as a separate package? All this will do is create increased overhead when installing the system (as each package must go through it's verification and transaction process), and
all sorts of trouble down the line when dependency hell sets in.
This is not the FreeBSD way. Very sad, concerned, and disappointed at
this design choice.
What benefit is there to installing setuid program lpr on an
appliance-like system without a printer other than enlarging the attack surface? If I remove it, do I have to build my own freebsd-update
system to keep things up to date?
I frequently want to build small systems without a compiler if I know
that I will never build software on them.
Also - nothing stands in the way that pkg(8) will check pkgbase(8) whatPKGBASE packages are installed and then install needed Base System packages with pkgbase(8) to satisfy its pkg(8) dependencies.
Hi.t
That is a good point - but if I have too choose between a feature You jus=
mentioned and really separated and safe Base System from the third party pkg(8) packages operations - then I choose Base System safety.es
Also - nothing stands in the way that pkg(8) will check pkgbase(8) what PKGBASE packages are installed and then install needed Base System packag=
with pkgbase(8) to satisfy its pkg(8) dependencies.
Regards,
vermaden
Temat: Re: PKGBASE Removes FreeBSD Base System Feature
Data: 2025-08-04 8:58
Nadawca: "Mariusz Zaborski" <oshogbo@freebsd.org>
Adresat: "Don Lewis" <truckman@freebsd.org>;
DW: "Daniel Morante" <daniel@morante.net>; stable@freebsd.org;
h/usr/local/etc/pkg and /var/db/pkg dirs for configuration.(1)
Keep pkg(8) for third party packages with /etc/pkg and
and /var/db/pkgbase dirs for managing PKGBASE packages. By pkgbase(8) I
Use separate pkgbase(8) with /etc/pkgbase and /usr/local/etc/pkgbase
have the same pkg(8) project in mind - just renamed as pkgbase(8) and wit=
*/pkgbase dirs instead of */pkg.k
I can imagine a situation where a third-party package depends on apackage from the base system.
When you bootstrap a jail or your machine, you might start with aminimal installation, but I would expect pkg to automatically figure
out what needs to be installed when it's required.
On Mon, 4 Aug 2025 at 08:37, Don Lewis <truckman@freebsd.org> wrote:
wouldOn 3 Aug, Daniel Morante wrote:
I just took a look at
https://pkg.freebsd.org/FreeBSD:15:amd64/base_latest/
<https://pkg.freebsd.org/FreeBSD:15:amd64/base_latest/> and I am
instantly disappointed. I was a fan of the idea, but seeing how they
decided to make one package for each item is a massive bummer. Why
viayou split it up this way? When when you install the Mozilla Firefox
package.package, you don't install every file individually as a separate
this
It's the same concept for FreeBSD. All these files make up a single
entity "FreeBSD" the operating system. Why on earth would you install
each item that's required to run FreeBSD as a separate package? All
eachwill do is create increased overhead when installing the system (as
andpackage must go through it's verification and transaction process),
disappointed atall sorts of trouble down the line when dependency hell sets in.
This is not the FreeBSD way. Very sad, concerned, and
this design choice.
What benefit is there to installing setuid program lpr on an
appliance-like system without a printer other than enlarging the attac=
esurface? If I remove it, do I have to build my own freebsd-updat=
system to keep things up to date?
I frequently want to build small systems without a compiler if I know
that I will never build software on them.
On 31 Jul 2025, at 02:57, Miroslav Lachman <000.fbsd@quip.cz> wrote:PkgBase does not remove the issue that updating the kernel
I would also like to separate it. Use one command to update (upgrade) 3rd party packages and another to update (upgrade) base packages. It is our workflow for the last 25+ years thus running one command to update both is really unexpected and unwanted.
I disagree here. If you *want* to separate them, then you can: you can specify the repository that you want to upgrade explicitly. But if you do then you risk things like:
- IrCOve upgraded my base system, but not my ports-kmods things, so now my GUI doesnrCOt start.
- IrCOve upgraded ports, but the ports tree is built on a newer point release and I need to upgrade to make some symbols exist.
- IrCOve upgraded the base system and now some kmods from ports donrCOt work.
All of these are things that users have complained about publicly in the last year or so.
I have avoided them by always doing `freebsd-update install && pkg upgrade` and keeping that in my shell history[1] so I donrCOt accidentally forget to upgrade both together.
Given a choice between a thing that works for users, or something that *can* work for users but comes with a bunch of footguns that they need to avoid, IrCOd pick the former.
David
[1] IrCOve noticed on fresh installs, the default shell no longer has working persistent history, which is a *big* POLA violation, if people want to complain about something.
PkgBase does not remove the issue that updatingNot related to PKGBASE - but as you will be doing a reboot after the update/upgrade anyway - its safer and easier to do the upgrade inside separate ZFS Boot Environment - as running kernel does not 'conflict' with the one installed/upgraded inside the ZFS BE. So you do all the possible steps needed - upgrading base - upgrading packages ...
the kernel first, rebooting, and then updating the
world can be a requirement.
(World should get a later reboot as well.)
(upgrade) 3rd party packages and another to update (upgrade) base packages.
On Aug 1, 2025, at 07:22, David Chisnall wrote:
On 31 Jul 2025, at 02:57, Miroslav Lachman <000.fbsd@quip.cz> wrote:
I would also like to separate it. Use one command to update
can specify the repository that you want to upgrade explicitly. But if you
I disagree here. If you *want* to separate them, then you can: you
now my GUI doesnrCOt start.
- IrCOve upgraded my base system, but not my ports-kmods things, so
PkgBase does not remove the issue that updating the kernelpoint release and I need to upgrade to make some symbols exist.
first, rebooting, and then updating the world can be a
requirement. (World should get a later reboot as well.)
Last I knew PkgBase did not manage this sequence of itself,
even for when kmods are not involved. I selectively update
the kernels first and reboot before updating teh other
PkgBase packages. (The plural 'kernels' is because I'm
using main and have all the PkgBase kernels installed.
One can not do that for non-main for contexts with .dtb
files involved: conflicts.)
Is it always safe to update all the ports-kmods before the
world is updated so they are in place for the after-kernel
reboot with the old world?
If not, then PkgBase is not of itself a way of making the
handling automatic as far as I can tell.
- IrCOve upgraded ports, but the ports tree is built on a newer
donrCOt work.- IrCOve upgraded the base system and now some kmods from ports
the last year or so.
All of these are things that users have complained about publicly in
that *can* work for users but comes with a bunch of footguns that they need
I have avoided them by always doing `freebsd-update install && pkg upgrade` and keeping that in my shell history[1] so I donrCOt accidentally forget to upgrade both together.
Given a choice between a thing that works for users, or something
has working persistent history, which is a *big* POLA violation, if people
David
[1] IrCOve noticed on fresh installs, the default shell no longer
===
Mark Millard
marklmi at yahoo.com
lowercase, please.I always used PKGBASE when I refer to this technology and I will continue to do so.
Off-topic from the four lists: it's knownInstructions work as desired - I upgraded dozens of systems this way over a decade and not a single one break.
that following instructions, whilst taking
the linked approach, can break the OS.
Breakage is not particularly safe.
With regard to rule-breaking,Citing The Matrix movie: "Some of them can be bent. Others can be broken."
rCaOn 04/08/2025 19:47, vermaden wrote:
rCa Not related to PKGBASE
lowercase, please.
pkgbase
rCa safer rCa https://vermaden.wordpress.com/2021/02/23/upgrade-freebsd-with-zfs-boot-environments/
Off-topic from the four lists: it's known that following instructions,
whilst taking the linked approach, can break the OS. Breakage is not particularly safe.
The four lists are not the places for a debate.
With regard to rule-breaking,
could have been taken as a reminder that no posting should be made to
more than 2 mailing lists, and only to 2 when a clear and obvious need
to post to both lists exists.
Because thatrCOs what you asked for.The problem is that the same 'pkg delete -af' command - will behave DIFFERENTLY with PKGBASE and without PKGBASE on the same FreeBSD version system - that is the center of the problem.
Why would the command do anything other than that?
If it did not, what command should and would you oppose it existing?
the 'untouchable' Base System.On 30 Jul 2025, at 01:28, vermaden wrote:
N++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
without touching the FreeBSD 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
system?
What the same "pkg delete -af" command does on a PKGBASE FreeBSD
only two PKGBASE packages called:
It kills/destroys almost all of the FreeBSD Base System and leaves
protected FreeBSD-rescue package and its also removed.
- FreeBSD-clibs
- FreeBSD-runtime
All the rest of Base System is GONE. Destroyed.
You do not even have vi(1) editor ad /rescue is separate not
Where is the POLA now?
WTF?!
POLA is the principle that made FreeBSD such predictable system.
without PKGBASE only removes all third party packages and the same *pkgWhy the same *pkg delete -af* command on 'classic' FreeBSD system
Because thatrCOs what you asked for. Why would the command doanything other than that? If it did not, what command should and would you oppose it existing?
Ceri
No, it has the same behaviour.English is not my primary language so I will try to explain in more simple words as you probably did not understood.
existing?On 6 Aug 2025, at 18:40, vermaden wrote:
N++
Because thatrCOs what you asked for.
Why would the command do anything other than that?
If it did not, what command should and would you oppose it
system - that is the center of the problem.
The problem is that the same 'pkg delete -af' command - will behave DIFFERENTLY with PKGBASE and without PKGBASE on the same FreeBSD version
many commands that make assumptions about the existing configuration of a system.
No, it has the same behaviour.
The result on the system may be different, but that is true of many,
Ceri
Why should we use the `pkg` tooling for this?That is what I proposed here with pkgbase(8) command: https://lists.freebsd.org/archives/freebsd-pkgbase/2025-July/000596.html
Why not instead have a dedicated set of tooling
for managing the base operating system?
inI gave this more thought. Maybe the problem here is the approach? Whyshould we use the `pkg` tooling for this?
Why not instead have a dedicated set of tooling for managing the base operating system? We kind of already have that and it works well with
the FreeBSD philosophy. They are called `bsdinstall`, and `freebsd-update`. Can we simply convert/repurpose (and maybe even merge) and rename those tools to handle managing the operating system
a package like style. We just call it "freebsd-setup" or whatever. The
point being that `pkg` is for ports/packages for third party softwarenever
and `freebsd-setup` is for the operating system. The two should
cross paths.wrote:
On 8/7/2025 7:09 AM, DutchDaemon - FreeBSD Forums Administrator wrote:
On 8/7/2025 1:43 AM, Tomek CEDRO wrote:
On Thu, Aug 7, 2025 at 12:21rC>AM vermaden
mostSo You still do not understand ...
The pkg(8) command works fine - its just NOT SUPPOSE to DESTROY
noof the FreeBSD Base System - because FreeBSD is not Linux to allow+1 =)
shit like that ...
Base and Userland should be clearly separated, as it was, as it is,
fallbackmatter how it will be organized internally (i.e. modular base) :-)
Maybe its worth thinking about some sort of standard minimal
environment (rescue?) when base gets broken for any reason (i.e.
broken pkgbase, broken modules, fs corruption, broken hardware,
accident) to either restore last working configuration or recreate
defaults with/from what can be saved? :-)
Maybe this would be a good time to reserve the -b / --base flags in
pkg(8) .. ?
On 8/7/2025 1:43 AM, Tomek CEDRO wrote:
On Thu, Aug 7, 2025 at 12:21=E2=80=AFAM vermaden <vermaden@interia.pl> w= rote:
So You still do not understand ...+1 =3D)
The pkg(8) command works fine - its just NOT SUPPOSE to DESTROY most=20
of the FreeBSD Base System - because FreeBSD is not Linux to allow=20
shit like that ...
Base and Userland should be clearly separated, as it was, as it is, no
matter how it will be organized internally (i.e. modular base) :-)
Maybe its worth thinking about some sort of standard minimal fallback
environment (rescue?) when base gets broken for any reason (i.e.
broken pkgbase, broken modules, fs corruption, broken hardware,
accident) to either restore last working configuration or recreate
defaults with/from what can be saved? :-)
Maybe this would be a good time to reserve the -b / --base flags in=20
pkg(8) .. ?
On 8/7/2025 1:43 AM, Tomek CEDRO wrote:
On Thu, Aug 7, 2025 at 12:21=E2=80=AFAM vermaden <vermaden@interia.pl> w= rote:
So You still do not understand ...+1 =3D)
The pkg(8) command works fine - its just NOT SUPPOSE to DESTROY most=20
of the FreeBSD Base System - because FreeBSD is not Linux to allow=20
shit like that ...
Base and Userland should be clearly separated, as it was, as it is, no
matter how it will be organized internally (i.e. modular base) :-)
Maybe its worth thinking about some sort of standard minimal fallback
environment (rescue?) when base gets broken for any reason (i.e.
broken pkgbase, broken modules, fs corruption, broken hardware,
accident) to either restore last working configuration or recreate
defaults with/from what can be saved? :-)
Maybe this would be a good time to reserve the -b / --base flags in=20
pkg(8) .. ?
deleting the basic things like kernel and minimal userland utils? if youwhat linux distros do here? extra options to avoid
On August 7, 2025 1:21:32 AM GMT+03:00, vermadenwrote:
of the FreeBSD Base System - because FreeBSD is not Linux to allow shitSo You still do not understand ...
The pkg(8) command works fine - its just NOT SUPPOSE to DESTROY most
more
Temat: Re: PKGBASE Removes FreeBSD Base System Feature
Data: 2025-08-07 0:13
Nadawca: "Ceri Davies" <ceri@submonkey.net>
Adresat: "vermaden" <vermaden@interia.pl>;
DW: FreeBSD-pkgbase@freebsd.org; freebsd-pkg@freebsd.org; freebsd-current@freebsd.org; freebsd-stable@freebsd.org;
On 6 Aug 2025, at 22:54, vermaden wrote:
N++
No, it has the same behaviour.
English is not my primary language so I will try to explain in
resultsimple words as you probably did not understood.
like you asked.
NOPE.
It DOES NOT has the same behavior.
In each case it forcibly deletes all the packages from your system,
I understood you fine, I just disagree that this is a shocking
it iswhen you have specified the rCLallrCY and rCLforcerCY flags. In fact
farexactly what that command is documented to do and therefore is very
from a violation of the principle of least astonishment.
Ceri
the PKGBASE concept - besides 'kinda working' - does not holds to the POLA principle at all - and if anyone will chose to use PKGBASE instead ofOK, Colin Percival just announced 15.0-PRERELEASE - yet
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
Its literally the same 'separation' as the Base System for binaries:
- /bin
- /usr/bin
- /sbin
- /usr/sbin
And /usr/local PREFIX for third party packages as:
- /usr/local/bin
- /usr/local/sbin
Regards,
vermaden
Temat: Re: PKGBASE Removes FreeBSD Base System Feature<freebsd-current-freebsd-org111@ketas.si.pri.ee>
Data: 2025-08-07 2:10
Nadawca: "Sulev-Madis Silber"
Adresat: freebsd-current@freebsd.org;you
deleting the basic things like kernel and minimal userland utils? if
what linux distros do here? extra options to avoid
happen to make way too broad package deletion. i don't think linuxwith
sysadmins want it either. even if you consider linux moving faster and
less seatbelts ("allow shit like that" (c) vermaden). it's not pkgfault it
does wipe system clean if you asked it. also, des@ reminded me thatpkg
replaced older tracking system 12 years ago. yet, i see pkg production versions being released just recently with a bug that user immediately notices. it was fixed because oops humans make mistakes. but it wouldbe a
horror if pkg does those things when it manages the entire system.granted,
you can always boot at least external media when any "nuclear" pkgupdate
comes out. this one wasn't but... and one could say that pkgbase is extensively discussed everywhere. but we still have discussions likethis
here. even fights. what if you miss all those? i never knew 32bit ison the
way out until i happened to randomly read that warning from kernelboot
log. there are number of those things in fbsd. happened earlier,happened
lately. maybe it's inevitable. were you scared to install new majorversion
like 5 or 13 right away because who knows what will happen? luckilythere
are 2, sometimes 3 majors to choose from should some of them includerushed
in late changes that turned out to be buggy. it feels like it gotworse
lately. i mean more changes, more breaks. i don't know why this isn't confined to current or stable. those are annoying type of changes.for
hopefully pkgbase will not be switched on before it's done. but pkg
ports still has issues and it's now default package manager here.feels
like too much hassle. there are many changes, i mean. good, but extrafuzz.
drm for gpus, wifi driver changes, wifi adapter firmware loadingchanges.
all with somebody complaining that (s)he didn't know there wasbreaking
change. i don't have had reason to run -af and not checking either butif
you had habit of doing that, it would be similar to rm ~ catching the/
along too. unsure what the fix is. (userland) utils and kernelprinting it
out to console? over longer period of time? i mean i could understandthat
change was discussed "everywhere", meetings, mailing lists. it wouldstill
be missed. if i make something, which i only tried once, and publishit, i
would never expect them to be aware of changes i make. because releasestuff.
notes, changelogs, those don't get attention. and you can still miss
i once told that correct procedure is to check everything throughlyand
then upgrade, but i have passed this myself often. and have gottensquint
"fallouts" too. in fbsd the only thing i would need to stand back,
and duck is when booting new current. when pkgbase gets out ininstaller,
i expect it to still have issues and i would rather stand back andwatch
this "nuke" going off. because it does make radical changes. one ofmost
wtf is that now one needs to deal /etc in new ways. and if thosediffer
from mergemaster or etcupdate, it would make somebody mad. perhapseven
worse than i could. in my mind, changes are good. if they arereasonable.
and known. probably knowing is biggest issue. what if one misses allthose
10 different places? i never checked, does freebsd-update tell thatpkgbase
is coming? does buildworld, maybe installworld tell that? that iactually
used and i don't see it. because those are like places where you seeit. i
can't recall if ports warned of pkgng coming soon? i also prefer ifthose
messages would include plans and not final decisions to make a change.i
haven't tries pkgbase myself, maybe i will, maybe i don't. unsure whatfix
is. maybe start putting things right into where everyone sees it.unsure.
and if i were you, whoever leads pkgbase initiative in "high castle"(it
does feel like this!), i would not let users delete base with -af.it's
rather unusual anyway and i don't think not deleting would get peopleas
mad as deleting stuff. i can't recall what was it, was it repo manageron
linux distro or something else but something wanted you to write whole sentence, observing caps and so on. then it executed that irreversible operation. in my systems, i've been configured things to ask date& times
when i really wanted to not do anything stupid. that would getsomebody's
brain working and maybe they interrupt their autopilot mode if theydidn't
actually want it. trust me, deleting freebsd-kernel, removingfreebsd-bin,
pkg-bootstrap... isn't what you want to see, then it's too late. andyes,
add echos to installworld end and freebsd-update if it's not therealready
because that's what people seeshit
wrote:
On August 7, 2025 1:21:32 AM GMT+03:00, vermaden
of the FreeBSD Base System - because FreeBSD is not Linux to allowSo You still do not understand ...
The pkg(8) command works fine - its just NOT SUPPOSE to DESTROY most
like that ...system,
freebsd-current@freebsd.org; freebsd-stable@freebsd.org;
Temat: Re: PKGBASE Removes FreeBSD Base System Feature
Data: 2025-08-07 0:13
Nadawca: "Ceri Davies" <ceri@submonkey.net>
Adresat: "vermaden" <vermaden@interia.pl>;
DW: FreeBSD-pkgbase@freebsd.org; freebsd-pkg@freebsd.org;
more
On 6 Aug 2025, at 22:54, vermaden wrote:
N++
No, it has the same behaviour.
English is not my primary language so I will try to explain in
simple words as you probably did not understood.
NOPE.
It DOES NOT has the same behavior.
In each case it forcibly deletes all the packages from your
factresultlike you asked.
I understood you fine, I just disagree that this is a shocking
when you have specified the rCLallrCY and rCLforcerCY flags. In
it is
farexactly what that command is documented to do and therefore is very
from a violation of the principle of least astonishment.
Ceri
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.
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
On Aug 7, 2025, at 10:17rC>PM, Colin Percival <cperciva@freebsd.org> wrote:As someone who does *just enough* work with FreeBSD and has used it since 2.1.6 or so, I would argue that in the past few years I've found myself "astonished" with a number of things, and I think a command that would normally wipe out all non-base components all of a sudden nuking your whole system is "astonishing".
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
--
Colin Percival
FreeBSD Release Engineering Lead & EC2 platform maintainer
Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid
Yea, I'll admit I've been installing it for literally decades and it has always been quick and easy (at least if you don't want windows/desktop and Ipackages installed from ports might depend on packages fromOne of the (if not THE) thing I found appealing about FreeBSD was not
the base system
having to think about or be concerned with that. You install FreeBSD,
you get what you need to run (ports/packages) on FreeBSD.
On 8/7/2025 10:17 PM, Colin Percival 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.
8 aug. 2025 kl. 04:17 skrev Colin Percival <cperciva@freebsd.org>:
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.
--
Colin Percival
FreeBSD Release Engineering Lead & EC2 platform maintainer
Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid
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.
On 8/7/25 18:20, vermaden wrote:
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.
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.
Not really. So far "the FreeBSD standard" kept things "similar" for
over 30 years. If we traveled back/forward in time we would still use
the same approach to configure and run stuff. Maybe except pkg-add was replaced with pkg, but still all locations are the same, configuration
files format, ports build, etc. "Base" is the cornerstone of FreeBSD
and its most widely known unique feature. It is like coming back to
familiar stable work place, where all things does not change on a
daily basis, or going to a different place and having the same
familiar setup with nothing missing. There was always clear separation
of "base system" and "userland". This meant all FreeBSD base release
X.Y would have exactly the same predictable behavior for everyone.
- It's important to have a clean separation between the base systemYou can easily create an alias for this:
(whether that is installed using the package system or not) and the
rest. An easy way to list "these are the base system packages" is
absolutely needed.
- Maybe there should be an extra step if you try to delete packagesThere already is:
from the base system?
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.
----
Colin Percival
FreeBSD Release Engineering Lead & EC2 platform maintainer
Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid
Not really. So far "the FreeBSD standard" kept things "similar" forI'm sorry but that's pure fantasy. In the last 30 years, we've switched
over 30 years. If we traveled back/forward in time we would still use
the same approach to configure and run stuff. Maybe except pkg-add was replaced with pkg, but still all locations are the same, configuration
files format, ports build, etc.
It's bad form to quote a large paragraph without summarizing, but this[...] packages installed from ports might depend on packages fromThis statement is extremely dangerous. It touches clue of this
the base system [...]
discussion. It seems to reveal planning to totally break current
FreeBSD design / architecture? So far "base" could work without
"userland", provided consistent, coherent, and predictable working environment. Everyone had the same set of "base" tools where
"userland" could be built on top, so every system could be different
but had exactly the same base. I can see that "base" will not be
coherent for everyone anymore. If ports start depending on base
packages then circular dependencies will arise and this will be a Linux-like-mess, because there could be different versions of base
packages for different port versions that will depend on different
versions of base packages. Then all will be just a package and there
will be no "coherent FreeBSD base" anymore right? Then 14-RELEASE will
hit end-of-lie and people will be _forced_ to switch to 15-RELEASE or
move away to different BSD. This sounds like FreeBSD is going full
Linux :-(
On 8 Aug 2025, at 04:20, vermaden <vermaden@interia.pl> wrote:concept - besides 'kinda working' - does not holds to the POLA principle =
=20
OK, Colin Percival just announced 15.0-PRERELEASE - yet the PKGBASE =
=20
My 'vote' here does not changed.
=20
Lets keep pkg(8) for third party packages with:
- /etc/pkg
- /usr/local/etc/pkg
- /var/db/pkg
=20
Lets have pkgbase(8) for FreeBSD Base System PKGBASE with:
- /etc/pkgbase
- /usr/local/etc/pkgbase
- /var/db/pkgbase
=20
Its literally the same 'separation' as the Base System for binaries:
- /bin
- /usr/bin
- /sbin
- /usr/sbin
=20
And /usr/local PREFIX for third party packages as:
- /usr/local/bin
- /usr/local/sbin
=20
Regards,
vermaden
Tomek CEDRO <tomek@cedro.info> writes:Yes, but from user perspective these changes were easy to adapt to :-)
Not really. So far "the FreeBSD standard" kept things "similar" for
over 30 years. If we traveled back/forward in time we would still use
the same approach to configure and run stuff. Maybe except pkg-add was replaced with pkg, but still all locations are the same, configuration files format, ports build, etc.
I'm sorry but that's pure fantasy. In the last 30 years, we've switched
our init system twice, the main system configuration moved from /etc/sysconfig to /etc/rc.conf, and we later added /etc/rc.conf.d and per-service subdirectories. The ports tree is also completely different
from what it was 15 years ago, let alone 30: we've switched to staged, unprivileged builds, we've added USES and FLAVOR, we switched the
primary identifier from the origin to PKGNAME, we switched to pkg (which
is a much bigger change than you seem to realize)... If anything, the separation between base and ports is stronger now than ever, because we
used to allow ports to install files outside of ${LOCALBASE} and even
replace parts of the base system.
Packaged base has been in the works for a decade and it's going in.Looks like 15 will be a "great adventure", that just started with a
There are rough edges, but we'll sort them out and the end result will
be much, much easier to manage for everybody than what we have now. By
the time FreeBSD 16.0 comes around, it will be second nature, and you
will have a hard time remembering what the fuss was all about.
Its just fear, outlined by a speculation, sure, we don't know how this[...] packages installed from ports might depend on packages fromThis statement is extremely dangerous. It touches clue of this
the base system [...]
discussion. It seems to reveal planning to totally break current
FreeBSD design / architecture? So far "base" could work without
"userland", provided consistent, coherent, and predictable working environment. Everyone had the same set of "base" tools where
"userland" could be built on top, so every system could be different
but had exactly the same base. I can see that "base" will not be
coherent for everyone anymore. If ports start depending on base
packages then circular dependencies will arise and this will be a Linux-like-mess, because there could be different versions of base
packages for different port versions that will depend on different
versions of base packages. Then all will be just a package and there
will be no "coherent FreeBSD base" anymore right? Then 14-RELEASE will
hit end-of-lie and people will be _forced_ to switch to 15-RELEASE or
move away to different BSD. This sounds like FreeBSD is going full
Linux :-(
It's bad form to quote a large paragraph without summarizing, but this
is so unhinged I couldn't figure out what to cut. It's completely off
the wall, starting with the use of rCLuserlandrCY, a well-established term meaning rCLcode that isn't part of the kernelrCY, to mean... something else that I can't quite figure out. But also, there is nothing circular at
all about ports depending on base. That's the way it's always been,
even if we didn't explicitly record it in package metadata (apart from
the shlib login in recent versions of pkg).
Tomek CEDRO <tomek@cedro.info> writes:LetrCOs remember the thing that started this entire thread: `pkg delete -af` This is an *incredibly* stupid thing to do. Long before pkg came along, I did the equivalent of this and managed to lock myself out of a headless box by doing this because I forgot that I was using the ports version of openssh instead of the base one.
[...] from user perspective these changes were easy to adapt to :-)
So will this one.
Hi David, I see your point.Why?
For me, no pkg command (upgrade / install : delete / lock) should act on base without the user explicitly targeting base.
This is the same we have today. No extra complexity or confusion, actually it is quite simple , if you want to touch your base system just explicitly targeting it ( what we do today with FreeBSD-update)What is the reason that you would want to install updates for packages built by ports and *not* want to install updates to the base system?
Regarding the non-base package dependencies with base, it will be also the same as today. If this is something we are looking to get rid of then is a different situation.Fixing this is one of the benefits of pkgbase: there is a single upgrade command, unless you explicitly restrict what it is updating (via -r) then it will upgrade everything that is out of date.
Nothing stops the user from upgrading base (target base) then upgrading the rest. Or to have a target that is rCLallrCY.This is still possible with pkgbase. If you want to stage things, simply use the `-r` flag. But when do you *actively want* that?
I think most of the FreeBSD user like the separation of base and non base and the current status seems to get rid of it. Hence some of us are putting attention to it ( maybe too much)This is a gross mischaracterisation driven by VermadenrCOs love of hyperbole. No one is removing the distinction between the base system and ports. The base system remains:
removed:sthaug@nethelp.no writes:
- It's important to have a clean separation between the base system
(whether that is installed using the package system or not) and the
rest. An easy way to list "these are the base system packages" is
absolutely needed.
You can easily create an alias for this:
pkg query -e '%o = base' %n
If you want something closer to `pkg info`, try:
pkg query -e '%o = base' '%n-%v %c' | column -tl 2
- Maybe there should be an extra step if you try to delete packages
from the base system?
There already is:
% sudo pkg delete FreeBSD-clibs
Checking integrity... done (0 conflicting)
The following package(s) are locked or vital and may not be
FreeBSD-clibs
1 packages requested for removal: 1 locked, 0 missing
The only matter that remains to be settled is which packages should be
marked vital:
% pkg query -e '%V = 1' %n
FreeBSD-clibs
FreeBSD-runtime
DES
--
Dag-Erling Sm|+rgrav - des@FreeBSD.org
On 8/8/2025 10:48 AM, Daniel Morante wrote:
I'm from the group of people that believes if you ask a computer to do something, no matter what that thing is (even if it's destructive and dangerous) the computer should do it. There is nothing that I hate more
than someone else deciding what I can and can not do with my computer. FreeBSD is one of the few remaining operating systems that retains this freedom.
The problem isn't the action of deleting all your base packages. The
problem is the fact that this was designed in such a way where we are
having this conversation.
(trying to see the upside)
On Aug 8, 2025, at 11:00rC>AM, Dimitry Andric <dim@freebsd.org> wrote:Yeah, this thread is frustrating because on one hand we have users saying "here's why this is bad" and developers just saying "nobody does that" to someone who is doing that. There's no way to know how many people do that, and there's nothing productive in just saying those people are "using FreeBSD wrong". It's not like the handbook is going to teach you actual systems admin skills to the point where you know the "why's" of what you're doing.
On 8 Aug 2025, at 15:56, David Chisnall <theraven@FreeBSD.org> wrote:
On 8 Aug 2025, at 14:42, Dag-Erling Sm|+rgrav <des@FreeBSD.org> wrote:
Tomek CEDRO <tomek@cedro.info> writes:
[...] from user perspective these changes were easy to adapt to :-)
So will this one.
LetrCOs remember the thing that started this entire thread: `pkg delete -af` >>
This is an *incredibly* stupid thing to do. Long before pkg came along, I did the equivalent of this and managed to lock myself out of a headless box by doing this because I forgot that I was using the ports version of openssh instead of the base one.
I'm one of the people that regularly runs `pkg delete -af`, even with `-y` added. :) That said, I only use this when I have completely rebuilt a ports collection with poudriere against a newer base jail, and then I'd like to start completely from scratch with freshly installed packages. This also clears out any unnecessary non-leaf packages there were pulled in by a previous package build.
Obviously that is an outlier scenario! But does pkg have a way to express "show me packages only from this particular repo", or "delete only packages from this particular repo"? That would make it easy to do "delete only the packages from ports, not from base".Even better, the "-af" flag simply doesn't touch base. PKGBASE is new. Adding a single flag to pkg that indicates operations are being performed on the base system, or even minimally some warnings (who's going to spot a handful of base pkgs in a list of hundreds when running even an interactive purge of all pkgs?) when the command is run, why are people against simple measures like that? I really fail to see why the people creating this new feature, which I'm sure is useful for some vendor or other funding this stuff, cannot accept that there are actual, real, normal users out there who a) don't care about PKGBASE b) believe POLA adoption in the past is what has made this OS pretty great to use and c) don't see any value in doing a base upgrade and pkg upgrade at the same time (DES mentioned this as a feature, but I have no interest in upgrading two wildly different codebases at the same time and have never wanted to do that).
-Dimitry
On Aug 8, 2025, at 11:44=E2=80=AFAM, Brandon Allbery =<allbery.b@gmail.com> wrote:
=20Administrator <DutchDaemon@freebsd.org <mailto:DutchDaemon@freebsd.org>> = wrote:
On Fri, Aug 8, 2025 at 11:30=E2=80=AFAM DutchDaemon - FreeBSD Forums =
minimal a base system as they can get away with. The flip side of the = all-encompassing base system is that it's big. And grown considerably =(trying to see the upside)=20
=20
As stated earlier in the thread: embedded hardware which wants as =
=20
--
brandon s allbery kf8nh
allbery.b@gmail.com <mailto:allbery.b@gmail.com>
As stated earlier in the thread: embedded hardware which wants as minimal a base system as they can get away with. The flip side of the
all-encompassing base system is that it's *big*. And grown considerably
since the early days, making the early-days management of base a problem
now.
Current 'vital' thing does NOTHING to protect FreeBSD Base System.How much longer will it take you to learn that people stop taking you
--vermaden writes:
Current 'vital' thing does NOTHING to protect FreeBSD Base System.
How much longer will it take you to learn that people stop taking you seriously when you scream at them?
DES
--
Dag-Erling Sm|+rgrav - des@FreeBSD.org
vermaden <vermaden@interia.pl> writes:
Current 'vital' thing does NOTHING to protect FreeBSD Base System.
How much longer will it take you to learn that people stop taking you seriously when you scream at them?
DES
--
Dag-Erling Sm=C3=B8rgrav - des@FreeBSD.org
Dag,
mind your attitude towards our users/contributors
vermaden was clearly not yelling so stop trying to discredit them withte:
such accusations.
On Friday, August 8, 2025, Dag-Erling Sm=C3=B8rgrav <des@freebsd.org> wro=
vermaden <vermaden@interia.pl> writes:
Current 'vital' thing does NOTHING to protect FreeBSD Base System.
How much longer will it take you to learn that people stop taking you
seriously when you scream at them?
DES
--
Dag-Erling Sm=C3=B8rgrav - des@FreeBSD.org
System.Current 'vital' thing does NOTHING to protect FreeBSD Base
I literally just wiped one of my Jails because of this 'vital'protection.
That 'vital' thing is useless in current state after issuing thiscommand:
# pkg delete -afremoved packages without PKGBASE and with PKGBASE you are left with dust.
Log below.
Unbootable and unusable FreeBSD left after the command that only
Even /rescue is gone.Pages)
root@bsdinstalljail:/ # pkg info
FreeBSD-acct-14.1p1 System Accounting Utilities FreeBSD-acct-man-14.1 System Accounting Utilities (Manual
FreeBSD-acpi-14.1 ACPI Utilities(Development Files)
(...)
FreeBSD-zfs-dev-14.1p1 ZFS Libraries and Utilities
FreeBSD-zfs-man-14.1 ZFS Libraries and Utilities (ManualPages)
FreeBSD-zoneinfo-14.1p7 zoneinfo packageEnvironments on ZFS
beadm-1.3.5_1 Solaris-like utility to manage Boot
pkg-2.2.1 Package managerpackages in the universe):
root@bsdinstalljail:/ # pkg delete -af
Checking integrity... done (0 conflicting)
Deinstallation has been requested for the following 271 packages (of 0
Installed packages to be REMOVED:FreeBSD-zfs-man-14.1: 100%
FreeBSD-acct: 14.1p1
FreeBSD-acct-man: 14.1
FreeBSD-acpi: 14.1
(...)
[bsdinstalljail.lab.org] [268/271] Deleting files for
[bsdinstalljail.lab.org] [269/271] DeinstallingFreeBSD-zoneinfo-14.1p7...
[bsdinstalljail.lab.org] [269/271] Deleting files forFreeBSD-zoneinfo-14.1p7: 100%
[bsdinstalljail.lab.org] [270/271] Deinstalling beadm-1.3.5_1... [bsdinstalljail.lab.org] [270/271] Deleting files for beadm-1.3.5_1:100%
[bsdinstalljail.lab.org] [271/271] Deinstalling pkg-2.2.1... [bsdinstalljail.lab.org] [271/271] Deleting files for pkg-2.2.1: 100%longer needed.
pkg: Cannot runscript POST-DEINSTALL:No such file or directory
You may need to manually remove /usr/local/etc/pkg.conf if it is no
root@bsdinstalljail:/ # lshostname kenv
/bin/sh: ls: not found
root@bsdinstalljail:/ # vi
/bin/sh: vi: not found
root@bsdinstalljail:/ # pkg
/bin/sh: pkg: not found
root@bsdinstalljail:/ # pkg-static
/bin/sh: pkg-static: not found
root@bsdinstalljail:/ # reboot
/bin/sh: reboot: not found
root@bsdinstalljail:/ # goodbye
/bin/sh: goodbye: not found
root@bsdinstalljail:/ # /rescue/ls /rescue
/bin/sh: /rescue/ls: not found
root@bsdinstalljail:/ # /rescue/ls.pkgsave /rescue
rescue: ls.pkgsave not compiled in
usage: rescue ..., where is one of:
cat chflags chio chmod cp date dd df echo ed red expr getfacl
kill ln link ls mkdir mv pkill pgrep ps pwd realpath rm unlink rmdirsetfacl
sh -sh sleep stty sync test [ csh -csh tcsh -tcsh camcontrol clridevfs dmesg
dump rdump dumpfs dumpon fsck fsck_ffs fsck_4.2bsd fsck_ufsfsck_msdosfs fsdb
fsirand gbde geom glabel gpart ifconfig init kldconfig kldloadkldstat
kldunload ldconfig md5 mdconfig mdmfs mknod mount mount_cd9660mount_msdosfs
mount_nfs mount_nullfs mount_udf mount_unionfs newfs newfs_msdosnos-tun
reboot fastboot halt fasthalt restore rrestore rcorder route savecoreshutdown
poweroff swapon sysctl tunefs umount ccdconfig ping ping6 rtsol ipfrouted
rtquery bectl zfs zpool bsdlabel disklabel fdisk dhclient head mt sedtail tee
gzip gunzip gzcat zcat bzip2 bunzip2 bzcat less more xz unxz lzmaunlzma xzcat
lzcat zstd unzstd zstdcat zstdmt fetch tar nc vi ex id groups whoamiiscsictl
zdb chroot chown chgrp iscsid rescue
Temat: Re: PKGBASE Removes FreeBSD Base System Featurebe
Data: 2025-08-08 10:31
Nadawca: "Dag-Erling Sm|+rgrav" <des@FreeBSD.org>
Adresat: sthaug@nethelp.no;
DW: freebsd-current@freebsd.org; freebsd-stable@freebsd.org;
removed:
sthaug@nethelp.no writes:
- It's important to have a clean separation between the base system
(whether that is installed using the package system or not) and the
rest. An easy way to list "these are the base system packages" is
absolutely needed.
You can easily create an alias for this:
pkg query -e '%o = base' %n
If you want something closer to `pkg info`, try:
pkg query -e '%o = base' '%n-%v %c' | column -tl 2
- Maybe there should be an extra step if you try to delete packages
from the base system?
There already is:
% sudo pkg delete FreeBSD-clibs
Checking integrity... done (0 conflicting)
The following package(s) are locked or vital and may not be
FreeBSD-clibs
1 packages requested for removal: 1 locked, 0 missing
The only matter that remains to be settled is which packages should
marked vital:
% pkg query -e '%V = 1' %n
FreeBSD-clibs
FreeBSD-runtime
DES
--
Dag-Erling Sm|+rgrav - des@FreeBSD.org
[...] In Debian, there is an "Essential" package status. "Essential" packages can't be removed, only upgraded or replaced. [...] ItThis is already the case, as has been pointed out repeatedly in this
strikes me that having a similar bit of package metadata for pkg(8)
would go a long way to making the behaviour safe by default.
On 8 Aug 2025, at 15:02, Santiago Martinez <sm@codenetworks.net> wrote:I don't have to reboot my system after upgrading third-party software. I may have to after updating the base system.
This is the same we have today. No extra complexity or confusion, actually it is quite simple , if you want to touch your base system just explicitly targeting it ( what we do today with FreeBSD-update)
What is the reason that you would want to install updates for packages
built by ports and *not* want to install updates to the base system?
Currently, you need to do these separately because they are managed byI think this conflates the mechanism and policy a bit.
two separate tools, but thatrCOs an accident. It was never a deliberate usability choice to have different ways of updating different parts of
the system. Fixing this is one of the goals of pkgbase.
Same as before: I want to be able to answer, do two versions of third-party software run on a single known version of FreeBSD? Likewise, does one version of third-party software run on multiple known versions of FreeBSD?Nothing stops the user from upgrading base (target base) then upgrading the rest. Or to have a target that is rCLallrCY.
This is still possible with pkgbase. If you want to stage things,
simply use the `-r` flag. But when do you *actively want* that?
Every upgrade flow I have on every FreeBSD machine I use is simplifiedThat's perfectly reasonable to me.
by pkgbase. Having fewer tools is a usability win. Having a single
command upgrade everything is a usability win. If you *want to*
upgrade only some things, thatrCOs one extra command-line flag.
On Fri, Aug 8, 2025, at 7:20 AM, David Chisnall wrote:This should be: "why change the established policy of updating base and third-party separately, and require users to use a flag to retain it? Why not retain the policy, and require users to use a flag to update both **together**?"
Every upgrade flow I have on every FreeBSD machine I use is simplified
by pkgbase. Having fewer tools is a usability win. Having a single
command upgrade everything is a usability win. If you *want to*
upgrade only some things, thatrCOs one extra command-line flag.
That's perfectly reasonable to me.
I guess the core question is: why change the established policy of
updating base and third-party separately, and require users to use a
flag to retain it? Why not retain the policy, and require users to use
a flag to update both separately?
- Because it's so inherently superior to the old way that it should be--
the default, and people who want the old way just need to read UPDATING
to know the tweaks to make?
- Because doing so would make the semantics of `pkg` too confusing? So
we accept the tradeoff of changing established upgrade policy, and
again people need to be familiar with UPDATING?
- Other reasons?
pkgbase seems like a fine mechanism for upgrading base. The issue at
hand seems to be that the current approach changes the default freebsd upgrade policy in a significant way.
Karl Denninger <karl@denninger.net> wrote:
How many of us have done an "rm -rf" in the wrong place?a Uh..... same
thing when you get down to it, right?
The problem with this analogy is that "rm -rf" hasn't changed - the "-f" wasn't suddenly changed from something innocuous to "force".
Pople using "pkg delete -af" are used to using it to delete all ports.
I'll often do that when upgrading a server to a new major release -
update the base OS, with the appropriate COMPAT and compat-libs, if
required, then once that's working, chose a free moment to pkg-delete -af
all the ports, and then BATCH rebuild them from a list of previously installed ports.
On Aug 10, 2025, at 4:47rC>AM, Don Lewis <truckman@FreeBSD.org> wrote:I don't think he stated that he doesn't have a list of ports/pkgs that are wanted.
On 8 Aug, Jamie Landeg-Jones wrote:
Karl Denninger <karl@denninger.net> wrote:
How many of us have done an "rm -rf" in the wrong place? Uh..... same
thing when you get down to it, right?
The problem with this analogy is that "rm -rf" hasn't changed - the "-f"
wasn't suddenly changed from something innocuous to "force".
Pople using "pkg delete -af" are used to using it to delete all ports.
I'll often do that when upgrading a server to a new major release -
update the base OS, with the appropriate COMPAT and compat-libs, if
required, then once that's working, chose a free moment to pkg-delete -af
all the ports, and then BATCH rebuild them from a list of previously
installed ports.
It looks like you are making extra work for youself. When you
"pkg delete -af", you are erasing all the data about which ports you carefully chosen to install and whether they were manually our
automatically installed. You need to record this info somewhere before
you "pkg delete".
If you "pkg upgrade -af" after the version upgrade, all of this info is preserved and selects the right ports to reinstall. You can optionally follow this with "pkg autoremove" to clean up unused leaf ports.
On Aug 10, 2025, at 4:47rC>AM, Don Lewis <truckman@FreeBSD.org> wrote:
On 8 Aug, Jamie Landeg-Jones wrote:
Karl Denninger <karl@denninger.net> wrote:
How many of us have done an "rm -rf" in the wrong place? Uh.....
same thing when you get down to it, right?
The problem with this analogy is that "rm -rf" hasn't changed - the
"-f" wasn't suddenly changed from something innocuous to "force".
Pople using "pkg delete -af" are used to using it to delete all
ports. I'll often do that when upgrading a server to a new major
release - update the base OS, with the appropriate COMPAT and
compat-libs, if required, then once that's working, chose a free
moment to pkg-delete -af all the ports, and then BATCH rebuild them
from a list of previously installed ports.
It looks like you are making extra work for youself. When you
"pkg delete -af", you are erasing all the data about which ports you
carefully chosen to install and whether they were manually our
automatically installed. You need to record this info somewhere
before you "pkg delete".
If you "pkg upgrade -af" after the version upgrade, all of this info
is preserved and selects the right ports to reinstall. You can
optionally follow this with "pkg autoremove" to clean up unused leaf
ports.
I don't think he stated that he doesn't have a list of ports/pkgs that
are wanted.
Deleting everything, and then just adding the 4 or 5 things you want
(which would end up with many more than 4-5 pkgs installed) is a
pretty foolproof way to clean up a bunch of cruft. Unless of course
your base OS also goes away.
4 or 5 is easy. My desktop:
%pkg info -a | wc -l
1411
%pkg prime-origins | wc -l
177
With 177 things, I want to make my life as simple as possible.
On 8/11/25 06:05, vermaden wrote:
[...]
% pkg prime-list | wc -l
439
[...]
Wow! What other secret undocumented commands are there in pkg?
Charles Sprickman <spork@bway.net> wrote:I use poudriere to pre-build my desired package set on a headless box
On Aug 10, 2025, at 4:47rC>AM, Don Lewis <truckman@FreeBSD.org> wrote:
On 8 Aug, Jamie Landeg-Jones wrote:
all the ports, and then BATCH rebuild them from a list of previously
installed ports.
It looks like you are making extra work for youself. When you
"pkg delete -af", you are erasing all the data about which ports you
carefully chosen to install and whether they were manually our
automatically installed. You need to record this info somewhere before
you "pkg delete".
I don't think he stated that he doesn't have a list of ports/pkgs that are wanted.
Yep! As I even wrote! :-) , I batch rebuild them from a list - rather, I have a script that parses a pkg list, and creates a script to install the ports fresh. (I build from ports not packages) The script does hard code a priority install order of ports if necessary - i.e. on machines I use the ports version
of openssl, that's the port the script installs first. I think if openssh from
ports was installed, that is next, and a few other similar examples.
I don't do this process for all upgrades, just the times I want to do a complete rebuild, usually after a major release upgrade.
After doing a pkg delete -af I then check /usr/local for orphaned files
etc. and make it clean before running the script.
The script first runs through all the ports to check for config option changes
(I still have the previous settings in /var/db/ports) and then when they are done, it runs through the install in BATCH=YES mode.
Deleting everything, and then just adding the 4 or 5 things you want (which would end up with many more than 4-5 pkgs installed) is a pretty foolproof way to clean up a bunch of cruft. Unless of course your base OS also goes away.
Exactly! After cleaning the system, before running the script, I prune the list of ports I know I don't want, or are just dependencies. Any that are only there as dependencies will get built again anyway. It's a nice, and
as you say, pretty foolproof way of cleaning things up. It's also quite
a fast operation - well, the actual ports install takes a while, but that happens without me needing to be around.
Finally, any errors/failed installs are highlighted at the end of the script for manual selection.
I like to use pkg delete -af because I want to catch orphaned files, but bluntly,Any thoughts on how to do the same housecleaning on the base system?
I could just save /usr/local/etc and nuke the rest of /usr/local and /var/db/pkg
Thanks for the reply, cheers, Jamie--
4 or 5 is easy. My desktop:
%pkg info -a | wc -l
1411
%pkg prime-origins | wc -l
177
With 177 things, I want to make my life as simple as possible.
Same here.
% pkg prime-list | wc -l
439
% pkg stats
Local package database:
Installed packages: 1671
Disk space occupied: 22 GiB
I use poudriere to pre-build my desired package set on a headless box
running -CURRENT before starting the upgrade. It's now close to 24
hours for a full build of my package set. That way, I don't bog down my desktop while the build is in progress, and I can defer the upgrade if anything vital fails to build. I don't have to worry about getting
stuck in a half-upgraded state. My only downtime is during pkg upgrade.
If you use "pkg prime-origins" to get the list of ports, that is lot
smaller set to sort through.
I like to use pkg delete -af because I want to catch orphaned files, but bluntly,
I could just save /usr/local/etc and nuke the rest of /usr/local and /var/db/pkg
Any thoughts on how to do the same housecleaning on the base system?
vermaden <vermaden@interia.pl> wrote:
4 or 5 is easy. My desktop:
%pkg info -a | wc -l
1411
%pkg prime-origins | wc -l
177
With 177 things, I want to make my life as simple as possible.
Same here.
% pkg prime-list | wc -l
439
% pkg stats
Local package database:
Installed packages: 1671
Disk space occupied: 22 GiB
Well, I don't exactly have 4 or 5 things installed.... :-)
% pkg prime-origins | wc -l
1296
% pkg stats
Local package database:
Installed packages: 2243
Disk space occupied: 25 GiB