Re: PKGBASE Removes FreeBSD Base System Feature

August 4, 2025 3:34 PM, "Miroslav Lachman" <000.fbsd@quip.cz> wrote:

> On 01/08/2025 16: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 (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:
>> 
>> - I’ve upgraded my base system, but not my ports-kmods things, so now
>> my GUI doesn’t start.
>> - I’ve upgraded ports, but the ports tree is built on a newer point
>> release and I need to upgrade to make some symbols exist.
>> - I’ve upgraded the base system and now some kmods from ports don’t 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 don’t 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, I’d pick the former.
>> 
>> David
>> 
>> [1] I’ve 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.
> 
> I see your point, but our workflow is much different. One command to
> upgrade base and packages at the same time is like "one to break it all"
> to me.
> I have seen broken "pkg upgrade" so many times... but it never breaks
> base and running ssh so I am still able to fix it somehow..
> Running FreeBSD for more than 25 years on tens of machines (headless
> servers) and I never need to do upgrade of base and packages at the same
> time. I am not saying nobody need it. Yes it can be useful on upgrading
> desktops or other installations with kmods, but I think it still can be
> done in 2 separate steps to keep the base untouched if user wants it.
> Mainly when there is another step needed - etcupdate. Having base and
> packages upgraded and only then fixing conflicts with etcupdate seems
> very bad idea to me.
The biggest problem I see in all this, is that all the drivers were moved to
ports/. That's a HUGE failure. When they existed in $base you had the option
to build only the drivers you needed and you built them with $BASE. So there
were never any symbol collisions/mismatches. Moving them to ports has only
made the whole procedure more cumbersome and error prone for everyone. Which
makes this whole "how do we categorize/manage this whole pkg-base thing?" a
complete mess w/o a clear or ideal solution.

That's my take/experience FWIW.
> 
> Kind regards
> Miroslav Lachman