pkg upgrade breaks kde/plasma again

[bgroper]

Using 14.3
Latest pkg upgrade removes plasma6-plasma-workspace, but doesn't install updated package.
Was a long build from ports.
Also session plasma renamed as plasmax11
Is this normal ?

Edit. It seems the missing plasma6-plasma-workspace-6.6.3 has arrived in the pkg repo overnight.

 

[matt_k]

It's not there for me, today I ran pkg update && pkg upgrade and it deleted KDE.

 

[sko]

KDE is a fast-moving dumpsterfire. It often drops out of the pkg repositories due to build errors; even more often for the 'latest' ports tree.
If you need something reliable, don't use KDE.
And as always: always check what pkg intends to upgrade or remove and if in doubt, check for fallout/build errors for the affected packages on freshports.

 

[T-Aoki]

DON'T BLINDLY HIT "Y" KEY ON UPGRADES!
Always confirm carefully to see there are no unintentional deletions before hitting "y" on upgrades.

If you're specifying "-y" option for pkg upgrade, never attempt to use the terrible option! Even think of using it!

The option is only for managed environments that admins are managing local repository and putting safe-to-upgrading things into the local repo.
Otherwise, the option could be catastrophic!

 

[Zare]

If you need something reliable, don't use KDE.

I find this conclusion dead wrong.

always check what pkg intends to upgrade or remove and if in doubt, check for fallout/build errors for the affected packages on freshports.

And this one is very right.
Any kind of software with multiple packages is susceptible to fallout. KDE being big and with quite a few packages, the chance increases.

 

[jardows]

This is a risk you run when using Latest package repository. I swear, almost every "X package got deleted!!!!" post would not be needed if people were using Quarterly. If you can't handle things occasionally breaking, or don't want to put in the time to verify what you are doing, don't run latest.

I do run Latest repo, but I learned early on to:

DON'T BLINDLY HIT "Y" KEY ON UPGRADES!
Always confirm carefully to see there are no unintentional deletions before hitting "y" on upgrades.

If you're specifying "-y" option for pkg upgrade, never attempt to use the terrible option! Even think of using it!

The option is only for managed environments that admins are managing local repository and putting safe-to-upgrading things into the local repo.
Otherwise, the option could be catastrophic!

I don't have system breaking problems running Latest, because I pay attention to what it is doing. If something is getting removed that I don't want to be removed, I can investigate why. That usually comes down to a couple of things - 1. build problems with the ports or 2. certain dependencies have been updated but the port hasn't yet been updated to use those dependencies. In these cases, simply waiting a couple of days resolves the problem.

 

[T-Aoki]

I swear, almost every "X package got deleted!!!!" post would not be needed if people were using Quarterly.

Unfortunately, it's not specific for latest.
Even on quarterly, if any huge one got upgraded with security fixes (something like www/chromium, for example), there can be broken window that previous versions are deleted but the upgraded ones are not yet finished building.

 

[sko]

previous versions are deleted but the upgraded ones are not yet finished building.

creation/updating of ports repositories is an atomic operation with poudriere. otherwise it would be a constant hell of dependency issues.

After the whole ports tree was built by poudriere, it recreates the pkg repository. every port that couldn't be built for whatever reason is missing from packages - short and simple.

I find this conclusion dead wrong.

It's a completely linux-centric (to put it *very* mildly) project with WAY too many moving parts and dependencies that are often heavily linux-specific. While for most developers in the UNIX (i.e. BSD, solaris/illumos) world "production safe first" is still a thing, the first rule of development in linux-land for many years has been "break stuff, maybe fix later (but it runs on my laptop, so I don't care), but push as many new versions per week as possible". And if you don't run systemd/linux your bug reports are usually invalid to them anyways.

 

[T-Aoki]

every port that couldn't be built for whatever reason is missing from packages - short and simple.

And this is the issue I've mentioned.

 

[bgroper]

Thanks for all the replies and suggestions.
I'm committed to both FreeBSD and KDE/plasma for various reasons, personal prejudice included.
Over some years and many updates I've learnt that KDE is potentially fragile on FreeBSD.
Suggested solution/s include some or all of the following :
- accept greater personal responsibility for the whole upgrade process
- never use pkg upgrade -y ; always use pkg upgrade -n
- be vigilant regarding KDE packages being removed and replaced, especially removed and NOT replaced
- don't rely solely on the pkg repos
- be prepared to build from ports if necessary
- delay helps. avoid being an early adopter, let other users find problems in repo pkgs before upgrading.
'nuf sed and YMMV

 

[matt_k]

Thanks for all the replies and suggestions.
I'm committed to both FreeBSD and KDE/plasma for various reasons, personal prejudice included.
Over some years and many updates I've learnt that KDE is potentially fragile on FreeBSD.
Suggested solution/s include some or all of the following :
- accept greater personal responsibility for the whole upgrade process
- never use pkg upgrade -y ; always use pkg upgrade -n
- be vigilant regarding KDE packages being removed and replaced, especially removed and NOT replaced
- don't rely solely on the pkg repos
- be prepared to build from ports if necessary
- delay helps. avoid being an early adopter, let other users find problems in repo pkgs before upgrading.
'nuf sed and YMMV

I just tend to pay attention if "Packages to be REMOVED" entry appears when doing
pkg update && pkg upgrade
If this text appears, then I need to pay a little bit more attention and read what is it trying to do.
Some day in April (or godknowswhen) it decided to remove KDE and I thought, "who's using KDE anyway" and let it disappear. A few days later I check if KDE appeared and it is still missing. I don't know how to check the status of the package build, and I don't care that much about having KDE, and I've seen this unresolved forum post, so I just reported that it's missing on my side as well.

I like lazy approach when it comes to system administration, it's what you can afford when the computer is not exactly mission critical. And FreeBSD is good for this use case, because it barely changes, so everything just tends to run for years without tinkering. One of these days I need to look into all this hot pkgbase thing, I don't know much about it and it's been a while since it's been introduced. But I think that FreeBSD will let me know when the end for the
freebsd-update
command approaches.

 

[matt_k]

KDE is a fast-moving dumpsterfire. It often drops out of the pkg repositories due to build errors; even more often for the 'latest' ports tree.
If you need something reliable, don't use KDE.
And as always: always check what pkg intends to upgrade or remove and if in doubt, check for fallout/build errors for the affected packages on freshports.

I agree with that. It seems to me, that the best course of action is to shy away from such software. Gnome is an unusable dumpster fire and KDE is far from reliable as well. The same goes for Hyprland and really any Wayland type of window manager/compositor. Just not reliable. Even less pompous projects like Niri or Sway tend to have their own share of weird behaviour.

 

[fahrenheit]

The issue here is not kde or any other piece of software other than pkg and how FreeBSD handles builds and dependencies. For reference this also happened to me on base packages (when tracking 15-stable).
As pkg will be the default in 16, it would be really nice that these issues stop happening every fortnight and happen once in a blue moon or some low occurrence event.

 

[matt_k]

The issue here is not kde or any other piece of software other than pkg and how FreeBSD handles builds and dependencies. For reference this also happened to me on base packages (when tracking 15-stable).
As pkg will be the default in 16, it would be really nice that these issues stop happening every fortnight and happen once in a blue moon or some low occurrence event.

And why does it happen? In my years of using FreeBSD it only affected me twice. And both times it was related to desktop environments. Or maybe it affected me more than twice, but I did not notice, because I was not actively using the affected program.

 

[sko]

The issue here is not kde or any other piece of software other than pkg and how FreeBSD handles builds and dependencies. For reference this also happened to me on base packages (when tracking 15-stable).
As pkg will be the default in 16, it would be really nice that these issues stop happening every fortnight and happen once in a blue moon or some low occurrence event.

this has nothing to do with pkg per se - and pkgbase is completeley unrelated here (I'm also definitely *not* a fan of pkgbase - IMHO the strict distinction between the OS and third party software is absolutely essential to FreeBSD just like other BSDs, which are proper, coherent operating systems)

Regarding KDE or gnome: Those bloatfests are regularly failing to build, so they (or parts of them) fall out of the official pkg repositories - there's nothing wrong with that and it's the only correct way to handle broken upstream software. If it's broken, it just won't be available via pkg until it is fixed and builds again - plain and simple. pkg will tell you if it has to remove some broken (and hence unavailable) ports to upgrade everything else and you are free to accept this or not.
This puts the pressure on the software that's broken and not anyone else - if you'd hold back everything else just because KDE is broken for the umpteenth time, we'd still be smearing feces at cave walls.

 

[drhowarddrfine]

I'm also definitely *not* a fan of pkgbase - IMHO the strict distinction between the OS and third party software is absolutely essential to FreeBSD

I'm not sure that understanding is correct but I haven't had a chance to read much about pkgbase, either. I believe pkgbase will be an installation tool only and is indifferent to what it installs. That is, it installs parts of the OS in the same way (in a sense) that it installs third party software but that's as far as that goes. Those portions of the OS will now be treated as packages in the same way as other software is but that's all it does and that's as far as it goes.

Someone correct me if I'm way off base.

 

[fahrenheit]

this has nothing to do with pkg per se - and pkgbase is completeley unrelated here (I'm also definitely *not* a fan of pkgbase - IMHO the strict distinction between the OS and third party software is absolutely essential to FreeBSD just like other BSDs, which are proper, coherent operating systems)

Regarding KDE or gnome: Those bloatfests are regularly failing to build, so they (or parts of them) fall out of the official pkg repositories - there's nothing wrong with that and it's the only correct way to handle broken upstream software. If it's broken, it just won't be available via pkg until it is fixed and builds again - plain and simple. pkg will tell you if it has to remove some broken (and hence unavailable) ports to upgrade everything else and you are free to accept this or not.
This puts the pressure on the software that's broken and not anyone else - if you'd hold back everything else just because KDE is broken for the umpteenth time, we'd still be smearing feces at cave walls.

This is more visible because DEs, specially large ones, have an high amount of dependencies (but this is also true of anything on base).
If a lower dependency fails to build anything that requires it disapears (hence the removed).
There are two ways to handle that: the current way, in which the onus of figuring out if the end state is desired falls to the user (so, care with using pkg upgrade -y) or hold on pushing updates that would break dependencies (harder to do and shifts the onus to ci and mantainers not the software as you put it, upstream on general doesn't care about *bsd).
In my opinion the current solution is not good (hence the frequent forum posts), the other option is obviously possible otherwise large linux distros (debian, rhel, suse) that also have the same DEs (and substantially more users) would be filled with rage on their forums.
There are open tickets from the foundation's laptop project that aim to do improvements to pkg, I just don't know if that will be enough to mitigate the current issues.

 

[Zare]

I just tend to pay attention if "Packages to be REMOVED" entry appears when doing

I'm just doing this and I haven't had any issues.

(I'm also definitely *not* a fan of pkgbase - IMHO the strict distinction between the OS and third party software is absolutely essential to FreeBSD just like other BSDs, which are proper, coherent operating systems)

Someone correct me if I'm way off base.

The strict distinction did not come from pkg/freebsd-update separation but hier(7). And that will never change.
pkg is a system component, not a third party tool. Now, apart from managing 3rd party packages it can also manage the FreeBSD base.

 

[Zare]

hence the frequent forum posts

Wait a second, and excuse me if I'm wrong about something here.

This requires manually moving the pkg source to latest, and then using pkg without confirmation. Right?

I do not care if Debian, RHEL, Suse don't have as much fallout on their build systems. They have a shitton more funding than FreeBSD, those are infrastructure and manpower limits.

 

[fahrenheit]

Wait a second, and excuse me if I'm wrong about something here.

This requires manually moving the pkg source to latest, and then using pkg without confirmation. Right?

I do not care if Debian, RHEL, Suse don't have as much fallout on their build systems. They have a shitton more funding than FreeBSD, those are infrastructure and manpower limits.

The point was not whether debian et all had more man power, it was that it is possible to handle the issue in a different manner. Smaller distros without funding and/or running from mantainer pocket money can also achieve the same result.

As for latest, and as T-Aoki mentioned, the issue can, and does, happen on quarterly.