I was hit this week by opkg giving me a cryptic hint to resolve a problem:
- * Problem 1/2:
* - package packagegroup-core-boot-1.0-r17.6.shadow_ghost requires
sysvinit, but none of the providers can be installed
*
* Solution 1:
* - do not ask to install a package providing packagegroup-core-boot
Digging a bit into how it does things, I saw it's making use of
solver_problem2str(), which in
turn calls solver_findproblemrule(), which is documented as:
* search for a rule that describes the problem to the
* user. Actually a pretty hopeless task that may leave the user
* puzzled. To get all of the needed information use
* solver_findallproblemrules() instead.
So I ended up patching opkg to call the latter (patch below), yielding the
following output:
- * Problem 1/2:
* - package packagegroup-core-boot-1.0-r17.6.shadow_ghost requires
sysvinit, but none of the providers can be installed
* - complete list of reasons:
* - package sysvinit-2.88dsf-r14.6.aarch64 requires sysvinit-inittab,
but none of the providers can be installed
* - package packagegroup-core-boot-1.0-r17.6.shadow_ghost requires
sysvinit, but none of the providers can be installed
* - package sysvinit-inittab-2.88dsf-r10.16.shadow_ghost requires
o-usb, but none of the providers can be installed
* - conflicting requests
* - nothing provides openssl11 >= 1.1.0i needed by
o-usb-0.0.0+git6+2c2d1e6fe3-r1.7.aarch64
*
* Solution 1:
* - do not ask to install a package providing packagegroup-core-boot
Here I do find the expected information (openssl11 was a hack I hadded in
sumo, which poluted my first warrior builds, thus polluted my shard-state,
as there were 2 providers of this libssl soversion). So now I can solve my
problem.
Where do we go from now ? I'd argue libsolv selects the wrong message, but
its doc does say this API asks for the impossible, so we may not want to
spend time fixing it.
Is it reasonable to include the full list of reasons, maybe flagging those
that solver_findproblemrule() think are the most relevant ?
Or should this be seen as "extended diag" and conditioned by a new opkg
flag, maybe for backward-compatibility of some sort ?
It may make sense to push a function like this to libsolv itself ?
@@ -0,0 +1,38 @@
+Index: opkg-0.4.0/libopkg/solvers/libsolv/opkg_solver_libsolv.c
+===================================================================
+--- opkg-0.4.0.orig/libopkg/solvers/libsolv/opkg_solver_libsolv.c
++++ opkg-0.4.0/libopkg/solvers/libsolv/opkg_solver_libsolv.c
+@@ -795,6 +795,25 @@ static void libsolv_solver_add_job(libso
+ }
+ }
+
++static libsolv_print_all_problem_rules(libsolv_solver_t *libsolv_solver,
Id problem)
++{
++ Queue rules;
++ int i;
++
++ opkg_message(ERROR, " - complete list of reasons:\n");
++ queue_init(&rules);
++ solver_findallproblemrules(libsolv_solver->solver, problem, &rules);
++ for (i = 0; i < rules.count; i++) {
++ Id type, source, target, dep;
++ Id r = rules.elements[i];
++ type = solver_ruleinfo(libsolv_solver->solver, r, &source,
&target, &dep);
++ opkg_message(ERROR, " - %s\n",
++ solver_problemruleinfo2str(libsolv_solver->solver,
++ type, source, target,
dep));
++ }
++ queue_free(&rules);
++}
++
+ static int libsolv_solver_solve(libsolv_solver_t *libsolv_solver)
+ {
+ int problem_count = solver_solve(libsolv_solver->solver,
+@@ -810,6 +829,7 @@ static int libsolv_solver_solve(libsolv_
+ opkg_message(ERROR, "Problem %d/%d:\n", problem,
problem_count);
+ opkg_message(ERROR, " - %s\n",
+ solver_problem2str(libsolv_solver->solver,
problem));
++ libsolv_print_all_problem_rules(libsolv_solver, problem);
+ opkg_message(ERROR, "\n");
+
+ int solution_count =
solver_solution_count(libsolv_solver->solver,
--
Yann Dirson <y...@blade-group.com>
Blade / Shadow -- http://shadow.tech
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
