Re: Installed packages to be REMOVED

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
>