setup: --prune-install appears to be broken

[Jon Turney]

On 20/06/2024 14:36, David McFarland via Cygwin wrote:

Sorry for the delay in replying to this.

> 
> If I do a base install to a new root:
> 
>      setup-x86_64.exe --root "$(cygpath -wa .cygtest)" --no-admin \
>          --no-shortcuts --no-replaceonreboot --no-version-check \
>          --prune-install --verbose
> 
> And then run the same install again, I get:
> 
[...]

>      Can't happen.  No packagemeta for base
> 
> The "Can't happen" error results in all following transactions being skipped:
> 
>          // Can't happen - throw an exception?
>          {
>            Log (LOG_PLAIN) << "Can't happen.  No packagemeta for "
>                            << pv.Name() << endLog;
>            return;
>          }

Yeah, that's clearly a bug of some sort.

At the very least, if we're not going to terminate there, it probably 
should be a 'continue' rather than a 'return', so we actually process 
the rest of the transactions.

> This results in setup always showing no pending changes, even if you
> have installed additional packages that should be pruned by
> --prune-install, or if setup.ini has different contents.
> 
> The problem seems to be that we use SOLVER_ERASE jobs to remove all
> non-base installed packages, and they take precedence over keeping the
> pseudo-package 'base' installed.

There's something else going on here I don't understand as there are 
other base or basedep packages in that list of things it wants to erase.

> Making the erase jobs weak seems to solve the problem:
> 
> diff --git a/libsolv.cc b/libsolv.cc
> index 3f083a4..95f21a2 100644
> --- a/libsolv.cc
> +++ b/libsolv.cc
> @@ -850,7 +850,7 @@ SolverSolution::tasksToJobs(SolverTasks &tasks, updateMode update, Queue &job)
>             queue_push2(&job, SOLVER_INSTALL | SOLVER_SOLVABLE_PROVIDES, sv.name_id());
>             break;
>           case SolverTasks::taskUninstall:
> -          queue_push2(&job, SOLVER_ERASE | SOLVER_SOLVABLE, sv.id);
> +          queue_push2(&job, SOLVER_ERASE | SOLVER_WEAK | SOLVER_SOLVABLE, sv.id);
>             break;
>           case SolverTasks::taskReinstall:
>             // we don't know how to ask solver for this, so we just add the erase
> 
> However, I'm not sure if this is a good idea. Perhaps it should only be

Thanks very much for attempting to fix this and providing a patch.

But, yeah, that seems like probably the wrong approach.

(for e.g. seems like that's going make us silently ignore removing X at 
the same time as installing something else which depends on X, when we 
really should to indicate a conflict..)