Re: PKGBASE Removes FreeBSD Base System Feature

On 8/8/2025 14:30, Tomoaki AOKI wrote:
> 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

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
karl@denninger.net
/The Market Ticker/
/[S/MIME encrypted email preferred]/