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..)
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation: https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
