On 8/8/2025 14:30, Tomoaki AOKI wrote:
On Fri, 8 Aug 2025 10:53:57 -0400 Karl Denninger<[email protected]> wrote:On 8/8/2025 10:48 AM, Daniel Morante wrote: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.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. This needs to be re-designed with user experience and FreeBSD philosophy in mind. In a previous reply I had suggested a isolated tool called 'freebsd-setup' which would be a merged/renamed/refactored version of 'bsdinsall' and 'freebsd-update'. The two package systems should never cross paths. 'pkg' is the software management tool for the userland and that's what the user interacts with regularly. 'freebsd-setup' is the tool you bring out when you need to manage FreeBSD.How much of this angst originally was driven by the mess that is drm-kmod (and related blobs for other devices than display adapters) -- and thus perhaps thus the "better answer" is to put that stuff back where it belongs (which isn't in pkg/ports since the cross-dependencies are in the *kernel*, not user space.)For drm-*-kmod, isn't it the license issue (at least partially GPLv2) which avoids it from getting it back to base? https://cgit.freebsd.org/ports/tree/graphics/drm-61-kmod/Makefile#n12 Another aspect would be the "frequent updates", though. https://cgit.freebsd.org/ports/log/graphics/drm-61-kmod
Yeah, it is, and perhaps that's insoluble in that regard with to base given where it originates.
But that didn't make "generic packages" a reasonable answer to the problem although that's what was done originally since it frequently blew up in your face; backward ABI compatibility for userland stuff generally works with very few exceptions until and unless you remove the old shared libraries, which is a conscious choice and a positive action you have to take. You can still shoot yourself in the foot in some cases but generally that sort of foot-shooting occurs when you compile something from source and it mismatches a package and base component that are both there (OpenSSL comes to mind not long ago although 14.3 has aligned them reasonably-well in that regard.)
The "second repo" for kmod stuff (FreeBSD-kmods) is IMHO a very-decent and welcome approach to this issue, appears to resolve 90% of it, and that is pretty recent -- now you can do "pkg upgrade -r FreeBSD-kmods" and only upgrade those (which can now easily be part of "freebsd-update" when the kernel changes, and "strongly suggested" for "make installkernel") or "pkg upgrade -r FreeBSD" and only do the userland package stuff. I presume the same will apply to the repo defined for "base".
The /usr/local/etc/pkg/repos/FreeBSD.conf file does serve the "default" (no "-r" flag) purpose -- if you have something shut off in there then its not enabled by default. But if I explicitly list one or more repos after the -r flag (e.g. "-r FreeBSD" or "-r FreeBSD,FreeBSD-kmods") pkg should, if it can resolve those repos, use them even if the /usr/local/etc/pkg/repos/FreeBSD.conf file says they're not enabled.
That change would basically get you all the way there in that you can default it however you want but the upgrade function remains available from the command line by explicit request.
I presume an EXPLICIT command to operate on a given thing as root should be reasonably taken at face value (e.g. the difference between "rm -rf *" and "rm -rf /*"; the latter, well, that's rather intentionally specified. Perhaps its stupid but I did specify it. :-))
Further and beyond the foot-shooting examples there ARE situations (e.g. embedded systems running out of RAM and booting off read-only media) where I can see PKGBASE posing a problem with the package database in that at present the build environment for those (whether nanobsd or crochet) doesn't handle the idea of having the package database on backed storage and that storage requirement including the cache directory can get a bit large over time. I can handle that now with the /usr/local/etc/pkg/repos file -- but there's no current override other than editing that control file any time I want to do otherwise.
-- Karl Denninger [email protected] /The Market Ticker/ /[S/MIME encrypted email preferred]/
smime.p7s
Description: S/MIME Cryptographic Signature
