On 7/9/25 10:20, Roger Marquis wrote:
The most recent protobuf-c package update wants to remove and downgrade
incompatible dependencies:
Cannot solve problem using SAT solver, trying another plan
The following 5 package(s) will be affected (of 0 checked):
Installed packages to be UPGRADED:
protobuf-c: 1.5.1_2 -> 1.5.1_3
Installed packages to be DOWNGRADED:
bind-tools: 9.20.10 -> 9.20.9
libxml2: 2.14.4 -> 2.11.9
libxml2 was upgraded to 2.14.4 then reverted to 2.11.9 on 06/21
within an hour, then reupgraded on 6/28 if I read logs correctly.
Freshports lists quarterly package repository is still on 2.11 while
latest is on 2.14; have you switched or activated multiple repos?
Installed packages to be REMOVED:
apache24: 2.4.63_1
py311-html5-parser: 0.4.12_2
The operation will free 4 MiB
This should never happen. It never happens on Linux package upgrades,
making autoupdate cron tasks feasible and saving nontrivial admin time.
Upgrades lead to errors, including on Linux; I broke multiple distros
through updates to varying degrees but they were definitely broken by
the action. If it wasn't causing issues, then containerizing all
dependencies into each install wouldn't be so popular, nor would
snapshots and backups being integrated into upgrade workflows.
Automating upgrades without testing or backups will cause problems even
if it isn't just package conflicts.
Would be great if there were a poudriere or pkg-install flag or
environment variable to prevent such behavior but I did not find one in
the docs. Did I miss it or is there an RFE form under freebsd.org for
such requests?
I haven't seen a 'fail with error if manually installed packages will
be removed/replaced' option but if it doesn't exist then it would be a
good one to have. Sometimes people also use automatically installed
packages that they would want similar handling of; best to mark used
packages as manually installed when they are important. Otherwise
dependencies come and go which makes them less important to watch.
As a workaround, you could first run an upgrade with -n and check if
the output contains REMOVED or even DOWNGRADED (rarely happens, but can
legitimately happen) and error out + contact admin.
If automating, remember that without an option to run autoremove
during the upgrade that you still need a second command to try to handle
dependency cleanup. Without it, any unused dependencies will remain
until they conflict. With the effort to report upgrade used space, you
would think such cleanup would be a default (but preferrably optional)
part of upgrading.
Roger Marquis
