Opened 6 years ago

Closed 20 months ago

Last modified 4 months ago

#11206 closed bug (fixed)

pkgman update doesn't work anymore

Reported by: axeld Owned by: nobody
Priority: normal Milestone: R1/beta2
Component: - General Version: R1/Development
Keywords: Cc:
Blocked By: Blocking: #11330
Platform: All


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?

Attachments (1)

libpackage-add-on-libsolv-debug-2.log (23.2 KB ) - added by diver 6 years ago.

Download all attachments as: .zip

Change History (11)

comment:1 by RJ_Master, 6 years ago

Works for me hrev47839.

comment:2 by diver, 6 years ago

Blocking: 11330 added

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

comment:3 by jua, 6 years ago

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

comment:4 by axeld, 6 years ago

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!

comment:5 by diver, 6 years ago

Moving libqt4_x86- out of /system/packages solved the problem for me.

comment:6 by waddlesplash, 6 years ago

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?

in reply to:  6 comment:7 by bonefish, 6 years ago

Component: Kits/Package Kit- General
Owner: changed from bonefish to nobody

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.

comment:8 by bonefish, 6 years ago

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

comment:9 by waddlesplash, 20 months ago

Resolution: fixed
Status: newclosed

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.

comment:10 by nielx, 4 months ago

Milestone: R1R1/beta2

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

Note: See TracTickets for help on using tickets.