Pkg upgrade tries to remove KDE!

siealex · 2026-02-02T22:14:12+0000

My setup: FreeBSD 15.0 on a VMware virtual machine, KDE 6.5.5, "latest" repos.
Running pkg upgrade displays "Installed packages to be REMOVED" and 55 packages related to KDE, including plasma6-plasma, plasma6-plasma-desktop and qt6-webview.
What can cause this behavior? Usually pkg upgrade does not remove existing packages even if they are not currently available in the repo.

T-Aoki · 2026-02-02T22:37:59+0000

Just wait a day or more.
Something depended upon them would fallen out on most recent build (including cases invoked within too heavy builds, causing timeout) and wait for it to be appear again.

siealex · 2026-02-02T23:02:01+0000

Typically, if a package is not available in the repo, it is kept unchanged in the system, not removed during upgrade.

nxjoseph · 2026-02-02T23:04:36+0000

siealex said:
Typically, if a package is not available in the repo, it is kept unchanged in the system, not removed during upgrade.

I don't think that's how it worked.

unitrunker · 2026-02-02T23:19:32+0000

Just a guess. Some underlying library was updated. The updated KDE package hasn't happened yet. The old library is removed - along with anything that depends upon it.

hadoq · 2026-02-03T07:10:54+0000

Background; I started using FreeBSD again last month after a long hiatus.

On my laptop running 15.0-RELEASE/latest, my KDE install was deinstalled yesterday. I was playing with Fluxbox and Xfce and decided to keep using KDE. As I like 'clean' system, I removed the packages fluxbox and xfce (with a pkg autoremove), after which I my KDE installation was also gone. I thought KDE being removed was related to my actions, but this:

unitrunker said:
Just a guess. Some underlying library was updated. The updated KDE package hasn't happened yet. The old library is removed - along with anything that depends upon it.

might as well be it? I couldn't for the life of me get KDE working again, the package was missing in the `latest` repos. That was confirmed by looking at the Freshports info for the KDE package:

I solved this by switching back to 'quarterly' and reinstall KDE with all the dependencies. As expected, all my settings/personalizations were still there.

I have a few questions about this to get an understanding about this ('fallout' is new to me w/ regard to packages

):

How can the KDE package be deleted from the repo, is it 'just' what unitrunker said?
What is 'fallout' exactly w/ regard to packages in repos?
What is the best/fastest way for users to inform themselves about this?
Did I solve this in the best way or were there other options for me to explore?

Looking forward to learning from your answers, thanks in advance for your time!

weberjn · 2026-02-03T08:49:08+0000

unitrunker said:
Just a guess. Some underlying library was updated. The updated KDE package hasn't happened yet. The old library is removed - along with anything that depends upon it.

If this is true, then the pkg system is badly broken.

Emrion · 2026-02-03T09:11:06+0000

Why not simply answer 'N' when pkg is asking to continue the process?
You can retry until it upgrades your system without removing a part.

I agree it's not well designed, but it's what we have for free.

T-Aoki · 2026-02-03T09:19:47+0000

Not limited with FreeBSD, dry-run is strongly recommended whenever possible before actual upgrades. For pkg-upgrade(8) on FreeBSD, add option -n.

AlfredoLlaquet · 2026-02-03T09:31:17+0000

Emrion said:
Why not simply answer 'N' when pkg is asking to continue the process?

T-Aoki said:
Not limited with FreeBSD, dry-run is strongly recommended whenever possible before actual upgrades. For pkg-upgrade(8) on FreeBSD, add option -n.

The default answer is "N." You have to type "Y" to update!

T-Aoki · 2026-02-03T10:13:21+0000

AlfredoLlaquet said:
The default answer is "N." You have to type "Y" to update!

Exactly. But human beings make unintended mistakes.

AlfredoLlaquet · 2026-02-03T10:18:28+0000

T-Aoki said:
Exactly. But human beings make unintended mistakes.

I don't see how a dry-run helps in that, unless it is to make the user more aware that they are doing something important and cannot act without reading and thinking. But if you are truly aware of that, you don't need a dry-run.

AlfredoLlaquet · 2026-02-03T10:20:00+0000

What you do need is a snapshot or a backup. That is mandatory from my point of view before any change in your system.

monwarez · 2026-02-03T10:37:45+0000

www/qt6-webengine failed to build. It version was bumped to take into account of graphics/lcms2 update.
So you could lock qt6-webengine and probably lcms2 too.
In case lcms2 was updated, you could take from /var/cache/pkg the older version, and extract in $HOME/.local/lib where this directory is in LD_LIBRARY_PATH and then run the command in the extracted lcms2:

Code:

cp -a liblcms2_threaded.s* ~/.local/lib
cp -a liblcms2_fast_float.s* ~/.local/lib

jardows · 2026-02-03T15:42:50+0000

Think of "latest" as "bleeding edge." These are essentially nightly builds of the packages, and they aren't always processed and available at the time you want to run the upgrade. If you don't want this situation, you need to run "quarterly" or go through the effort to build your programs from ports and keep them updated that way.

hadoq · 2026-02-03T17:24:40+0000

Emrion said:
Why not simply answer 'N' when pkg is asking to continue the process?
You can retry until it upgrades your system without removing a part.

I agree it's not well designed, but it's what we have for free.

The list of stuff that was going to be deinstalled was quite long and I was on the cli without scrollback AFAIK (need to look into that). But yeah, in hindsight I should have looked better. I just glanced at it and it looked ok-ish, ha.

AlfredoLlaquet said:
What you do need is a snapshot or a backup. That is mandatory from my point of view before any change in your system.

Good point, as I'm new to ZFS I will play around with this more. Making snapshots before b0rking everything is a good practise of course. This is an unimportant laptop to play around with. It got interesting though

jardows said:
Think of "latest" as "bleeding edge." These are essentially nightly builds of the packages, and they aren't always processed and available at the time you want to run the upgrade. If you don't want this situation, you need to run "quarterly" or go through the effort to build your programs from ports and keep them updated that way.

Thanks for clarifying, I wasn't aware that 'latest' in this context boils down to 'nightly'. Again, for this laptop it doesn't matter much but your explanation makes me reconsider using 'latest' even for this laptop.

T-Aoki · 2026-02-03T17:39:22+0000

hadoq said:
The list of stuff that was going to be deinstalled was quite long and I was on the cli without scrollback AFAIK (need to look into that).

If you're on "real" CLI (means, vty* without X11 nor Wayland), you can turn into scrollback mode by pressing Scroll Lock key. Pressing again to cancel.
If your keyboard doesn't have Scroll Lock key, look into its manual to find which key combination (some usesCtrl+B, some others use Ctrl+K, or maybe any other combinations) is mapped to Scroll Lock.

nxjoseph · 2026-02-03T17:41:56+0000

T-Aoki said:
If you're on "real" CLI (means, vty* without X11 nor Wayland), you can turn into scrollback mode by pressing Scroll Lock key. Pressing again to cancel.
If your keyboard doesn't have Scroll Lock key, look into its manual to find which key combination (some usesCtrl+B, some others use Ctrl+K, or maybe any other combinations) is mapped to Scroll Lock.

Or, pipe it into a text pager.

pkg upgrade -n | less

hadoq · 2026-02-03T18:17:04+0000

T-Aoki said:
If you're on "real" CLI (means, vty* without X11 nor Wayland), you can turn into scrollback mode by pressing Scroll Lock key. Pressing again to cancel.

That was indeed the case - figured it'd be better to switch to a vty instead of yanking all packages from under a running DE