pkgman update doesn't work anymore

[axeld]

When I try to update Haiku via pkgman update, I get the following output:

The following changes will be made:
  in system:
    install package haiku_welcome-r1~alpha4_pm_hrev47819-1-any.hpkg from repository Haiku
    install package makefile_engine-r1~alpha4_pm_hrev47819-1-any.hpkg from repository Haiku
    install package haiku_userguide-r1~alpha4_pm_hrev47819-1-any.hpkg from repository Haiku
    install package haiku_loader-r1~alpha4_pm_hrev47819-1-x86_gcc2.hpkg from repository Haiku
    uninstall package haiku_welcome-r1~alpha4_pm_hrev47816-1
    uninstall package makefile_engine-r1~alpha4_pm_hrev47816-1
    uninstall package haiku_userguide-r1~alpha4_pm_hrev47816-1
    uninstall package haiku_loader-r1~alpha4_pm_hrev47816-1

Note the absence of a few core packages. Does anybody have any idea about that?

[RJ_Master]

Works for me hrev47839.

[diver]

(In #11330) Yeah, likely a dupe then, closing as such. Thanks for the heads up!

[jua]

I have the same problem now on hrev47828. If anyone wants to analyze it by trying out anything, I could do that.

[axeld]

According to Ingo, the best way to debug issues such as these is to manually add debug output to libsolver by adding a:

  pool_setdebuglevel(fPool, level);

to src/kits/package/solver/LibsolvSolver.cpp LibsolvSolver::_InitPool().

He wasn't sure about the level (probably start with 1, and see how that goes), and the output is supposed to be cryptic; I haven't yet found the time to look into the issue myself unfortunately. Hopefully this helps!

[diver]

Moving libqt4_x86-4.8.6.2-1-x86_gcc2.hpkg out of /system/packages solved the problem for me.

[waddlesplash]

Ah, that makes sense, as the current Qt version requires the old ICU. I'm recompiling it now, it should be uploaded in the next few days...

But now we're stuck with: what should the package manager do when there are packages that cannot be upgraded? Should it deactivate these packages, or show an error and not continue?

[bonefish]

Replying to waddlesplash:

But now we're stuck with: what should the package manager do when there are packages that cannot be upgraded? Should it deactivate these packages, or show an error and not continue?

Unless I'm mistaken it already works such that if you ask to update a specific package and it cannot be updated because that would break another package, these two problem solutions (don't update or uninstall problematic package) are offered. However, if you ask to update all packages that can be updated -- as in this case -- not getting all the possible options is exactly what should happen, since eventually there might be an awful lot of them (due to mutually exclusive alternatives, additional (e.g. "patented") repositories that replace certain packages, etc.).

Anyway, this is not a problem on the package manager side. The problem is that the package repository is in an inconsistent state.

On a related note, we should develop a strategy what to do in case of updating a package to a binary incompatible version -- both regarding the packaging aspect (the package should probably get another name) and regarding the question what we want to happen with third-party software that uses such a package.

[bonefish]

I added an option --debug <level> in hrev48098, so it is at least possible to get some debug output from the solver, now.

[waddlesplash]

full-sync handles this case properly now (i.e. it will ask what to do about the packages that will break); and HaikuPorts has developed a strategy for handling ABI breakage.

[nielx]

Assign tickets with status=closed and resolution=fixed within the R1/beta2 development window to the R1/beta2 Milestone