From 76632ec8816369f5b7cf503a37e75fe814bb12bf Mon Sep 17 00:00:00 2001 From: Karen Arutyunov Date: Thu, 9 Nov 2023 19:23:14 +0300 Subject: Fix unexpected 'unable to satisfy dependency' error in pkg_configure() by turning collect_order_dependent() into collect_dependent() --- bpkg/pkg-build-collect.hxx | 76 +++++++++++++++++++++------------------------- 1 file changed, 35 insertions(+), 41 deletions(-) (limited to 'bpkg/pkg-build-collect.hxx') diff --git a/bpkg/pkg-build-collect.hxx b/bpkg/pkg-build-collect.hxx index 74a48a0..86878f0 100644 --- a/bpkg/pkg-build-collect.hxx +++ b/bpkg/pkg-build-collect.hxx @@ -1571,6 +1571,27 @@ namespace bpkg const function&, postponed_configuration* = nullptr); + // If a configured package is being up/down-graded or reconfigured then + // that means all its configured dependents could be affected and we have + // to reconfigure them. This function examines every such a package that + // is already in the map and collects all its configured dependents. We + // also need to make sure the dependents are ok with the up/downgrade. If + // some dependency constraints are not satisfied, then cache them and + // proceed further as if no problematic constraints are imposed (see + // unsatisfied_dependents for details). Return the set of the collected + // dependents. + // + // Should we reconfigure just the direct depends or also include indirect, + // recursively? Consider this plausible scenario as an example: We are + // upgrading a package to a version that provides an additional API. When + // its direct dependent gets reconfigured, it notices this new API and + // exposes its own extra functionality that is based on it. Now it would + // make sense to let its own dependents (which would be our original + // package's indirect ones) to also notice this. + // + std::set + collect_dependents (const repointed_dependents&, unsatisfied_dependents&); + // Order the previously-collected package with the specified name and // configuration returning its position. // @@ -1584,27 +1605,6 @@ namespace bpkg const function&, bool reorder = true); - // If a configured package is being up/down-graded then that means all its - // dependents could be affected and we have to reconfigure them. This - // function examines every package that is already on the list and - // collects and orders all its dependents. We also need to make sure the - // dependents are ok with the up/downgrade. If some dependency constraints - // are not satisfied, then cache them and proceed further as if no - // problematic constraints are imposed (see unsatisfied_dependents for - // details). - // - // Should we reconfigure just the direct depends or also include indirect, - // recursively? Consider this plauisible scenario as an example: We are - // upgrading a package to a version that provides an additional API. When - // its direct dependent gets reconfigured, it notices this new API and - // exposes its own extra functionality that is based on it. Now it would - // make sense to let its own dependents (which would be our original - // package's indirect ones) to also notice this. - // - void - collect_order_dependents (const repointed_dependents&, - unsatisfied_dependents&); - void clear (); @@ -1744,6 +1744,20 @@ namespace bpkg unsatisfied_dependents&, bool add_required_by); + // Skip the dependents collection for the specified dependency if that has + // already been done. + // + // Note that if this function has already been called for this dependency, + // then all its dependents are already in the map and their dependency + // constraints have been checked. + // + void + collect_dependents (build_package&, + const repointed_dependents&, + unsatisfied_dependents&, + std::set& visited_deps, + std::set& result); + struct package_ref { database& db; @@ -1761,26 +1775,6 @@ namespace bpkg const function&, bool reorder); - // Skip the dependents collection/ordering for the specified dependency if - // that has already been done. - // - // Note that if this function has already been called for this dependency, - // then all its dependents are already in the map and the dependency - // constraints have been checked for them. Also they are in the list and - // are ordered to the left of this dependency, unless this dependency has - // been moved to the left itself since the previous visit. Such a move can - // only happen if this dependency is a dependent of some other dependency - // whose dependents have been collected/ordered since that previous visit. - // This function tracks such moves and just removes the moved dependencies - // from the visited set, so their dependents can be properly reordered - // after the move. - // - void - collect_order_dependents (iterator, - const repointed_dependents&, - unsatisfied_dependents&, - std::set& visited_deps); - private: struct data_type { -- cgit v1.1