Conversation
|
Let me add some insights on that as I feel responsible for the sorting architecture here: Current Architecture
if (a_old != NULL && b_old != NULL &&
pkg_jobs_schedule_direct_depends(a_old, b_old)) {
return (PKG_SCHEDULE_EDGE_OLD_DEP_OLD);
}
The problem is in pkg_jobs_process_delete_request() (line 519-581): bool force = j->flags & PKG_FLAG_FORCE; // autoremove sets PKG_FLAG_FORCE
...
if (force)
return (EPKG_OK); // Skips reverse dependency processing!So autoremove is treated as "force" internally, which causes it to skip adding reverse dependencies to the delete request. Without the full dependency graph in the job list, the topological sort cannot correctly order the deletions. Another approach is to rethink |
|
Yeah, we can actually set something like |
If package A depends on package B (on a binary or script for example), when autoremove is called currently the order is (likely) by alphabetic. This cause problems as if package A is removed first and package B needs a script from package A it will fails to clean up correctly the system. Since autoremove is considered as force internally simply remove the check so we will process the removals in the correct order. Sponsored by: Beckhoff Automation GmbH & Co. KG
|
With this change added to the |
|
And packages marked vital. |
|
this changed broken many things, I will revert and redo it |
If package A depends on package B (on a binary or script for example), when autoremove is called currently the order is (likely) by alphabetic. This cause problems as if package A is removed first and package B needs a script from package A it will fails to clean up correctly the system. Since autoremove is considered as force internally simply extend the check so we will process the removals in the correct order.
Sponsored by: Beckhoff Automation GmbH & Co. KG