Solved PKG wants to remove non-automatic packages during upgrade

D

deadbeef2000

I just recently wanted to upgrade my nextcloud/web jail when I ran into the following issue:
Running pkg upgrade leads to pkg wanting to uninstall nextcloud.
I set nextcloud to be a non-automatic package.

Output of pkg upgrade
Code: 
Updating latest-vserver-arm-01 repository catalogue...
pkg: No HTTP mirrors founds for the repo 'latest-vserver-arm-01'
latest-vserver-arm-01 repository is up to date.
All repositories are up to date.
Checking for upgrades (1 candidates): 100%
Processing candidates (1 candidates): 100%
The following 9 package(s) will be affected (of 0 checked):

Installed packages to be REMOVED:
    ImageMagick7-nox11: 7.1.1.26_5
    ffmpeg: 6.1.2_1,1
    libgd: 2.3.3_13,1
    libheif: 1.18.2
    libwmf-nox11: 0.2.13_2
    nextcloud-php82: 29.0.6
    php82-gd: 8.2.23
    php82-pecl-imagick: 3.7.0_4

Installed packages to be UPGRADED:
    x265: 3.5_1 -> 3.5_3

Number of packages to be removed: 8
Number of packages to be upgraded: 1

The operation will free 682 MiB.
1 MiB to be downloaded.

I'm building my own packages in a poudriere jail, but I guess this shouldn't make any difference.
Has anyone any suggestions on how to fix this? I'd like nextcloud to stay installed on my system during upgrades :D
 
deadbeef2000 said:
I set nextcloud to be a non-automatic package.
Click to expand...
Non-automatic is only relevant for pkg-autoremove(8).

deadbeef2000 said:
I'm building my own packages in a poudriere jail, but I guess this shouldn't make any difference.
Click to expand...
It does. Check your build logs, it probably has some build failures or skipped packages. Your system wants to upgrade x265 and as a result of that it will also trigger an upgrade of everything that depends on it. It looks like some packages are missing, so they cannot be upgraded but still need to be deleted because they depend on the previous version of x265.

Also, if you're building your own repository, did you disable the FreeBSD repositories? You can get some strange interactions if you enabled both the standard FreeBSD repository and your custom repo. Especially if you've enabled/disabled different options compared to the defaults.


What does pkg version -vRL= show?
 
Hello SirDice,
first of all, thank you for your really quick response. I've read a lot of posts on this forum over the past 4-5 years and your name came up rather often with a lot of really helpful posts. I want to thank you for that (but this isn't the proper place, so I'll leave it at that).

SirDice said:
What does pkg version -vRL= show?
Click to expand...
Code: 
argp-standalone-1.5.0              ?   orphaned: devel/argp-standalone
lame-3.100_5                       ?   orphaned: audio/lame
libXrandr-1.5.2_1                  ?   orphaned: x11/libXrandr
libXrender-0.9.10_2                ?   orphaned: x11/libXrender
libepoll-shim-0.0.20230411         ?   orphaned: devel/libepoll-shim
libtermkey-0.22_1                  ?   orphaned: devel/libtermkey
py39-packaging-24.0                ?   orphaned: devel/py-packaging
python39-3.9.18_2                  ?   orphaned: lang/python39
wayland-1.22.0                     ?   orphaned: graphics/wayland
x265-3.5_1                         <   needs updating (remote has 3.5_3)

Regarding the build, there's neither any failed nor skipped ports.
I'm only using my own package repo and none of the official ones provided by the FreeBSD project.
 
It's clear from the ? you have some missing packages in your repository. The Python 3.9 related packages are likely caused by the change to 3.11 as the default. You should clean those out with pkg-autoremove(8). Then check why those other packages are 'missing', maybe wayland didn't get built because you turned off that option? Same for the other 'missing' packages, certain options turned off? Which would cause dependencies to be dropped?
 
It might also have to do with the fact, that x265 is broken on a regular basis, because upstream changes stuff without changing the version number, resulting in checksum errors during build. Check your last few build logs if there were any occurences of x265 failing to build and hence (many) other ports being skipped (e.g. ffmpeg, which IIRC is also a dependency for nextcloud).
To fix building x265 temporarily you can run a make makesum in the ports' directory to update the checksums.

But the main problem here is very likely the python version as SirDice already pointed out. Default is 3.11 now, which should have triggered a rebuild of all python-related packages, but on the client side you might have to manually move to the 'py311'-versions of some packages.
 
Thanks guys, I actually found the culprit by digging a bit deeper...

I did build all my packages in a 14.0aarch64 jail until FreeBSD 14.1 was publicly released. I then created another poudriere jail, based on 14.1 and started building packages there. But the x265 dependency just vanished suddenly and there's no trace in my 14.1 repo. Apparently I changed an option somewhere which triggered this. So yes, thank you guys for pointing out the obvious :D

One more question, just so I get I right. For as long as the 14.x-RELEASE version is supported, I could theoretically build packages on a 14.0 based jail, correct? This is what I understood from reading the documentation, regarding ABI changes.
 
With the dependency hell on FreeBSD, www/firefoxcan get slated for removal if you're not careful. Yeah, there are ways to lock the pkg database, but it does take some digging around to figure out how to do it right. ?
 
deadbeef2000 said:
I don't have those dots. Maybe because I'm a new user?
Click to expand...
I don't know, but if you can post I would think you could mark your posts solved; below is a sample of the dots in case you do have them but didn't see them.

So I go into one of my older posts, and over on the right - the ellipsis:

1727302385782.png
 
Nope, I only have the unwatch button (and a jump to new on the left of it). But every time a post something a moderator checks it first and I see a message about my messages being checked before made publicly available. It's not a big deal or anything, just something I came across and wondered about. But thank you nevertheless!
 
You must log in or register to reply here.
Back
Top