Re: PKGBASE Removes FreeBSD Base System Feature
- Reply: Karl Denninger : "Re: PKGBASE Removes FreeBSD Base System Feature"
- In reply to: Karl Denninger : "Re: PKGBASE Removes FreeBSD Base System Feature"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Fri, 08 Aug 2025 18:30:35 UTC
On Fri, 8 Aug 2025 10:53:57 -0400 Karl Denninger <karl@denninger.net> 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 > -- > Karl Denninger > karl@denninger.net > /The Market Ticker/ > /[S/MIME encrypted email preferred]/ -- Tomoaki AOKI <junchoon@dec.sakura.ne.jp>