Handle additional libsolv 0.7.x cases

[kallisti5]

libsolv 0.7.x has additional solver rules that need handled within our package kit...

C++ objects/linux/x86_64/release/build/libpackage/solver/LibsolvSolver.o 
../src/kits/package/solver/libsolv/LibsolvSolver.cpp: In member function ‘status_t LibsolvSolver::_AddProblem(Id)’:
../src/kits/package/solver/libsolv/LibsolvSolver.cpp:914:16: warning: enumeration value ‘SOLVER_RULE_PKG_RECOMMENDS’ not handled in switch [-Wswitch]
  914 |         switch (solver_ruleinfo(fSolver, ruleId, &sourceId, &targetId,
      |                ^
../src/kits/package/solver/libsolv/LibsolvSolver.cpp:914:16: warning: enumeration value ‘SOLVER_RULE_PKG_CONSTRAINS’ not handled in switch [-Wswitch]
../src/kits/package/solver/libsolv/LibsolvSolver.cpp:914:16: warning: enumeration value ‘SOLVER_RULE_PKG_SUPPLEMENTS’ not handled in switch [-Wswitch]
../src/kits/package/solver/libsolv/LibsolvSolver.cpp:914:16: warning: enumeration value ‘SOLVER_RULE_JOB_UNKNOWN_PACKAGE’ not handled in switch [-Wswitch]
../src/kits/package/solver/libsolv/LibsolvSolver.cpp:914:16: warning: enumeration value ‘SOLVER_RULE_JOB_UNSUPPORTED’ not handled in switch [-Wswitch]
../src/kits/package/solver/libsolv/LibsolvSolver.cpp:914:16: warning: enumeration value ‘SOLVER_RULE_YUMOBS’ not handled in switch [-Wswitch]
../src/kits/package/solver/libsolv/LibsolvSolver.cpp:914:16: warning: enumeration value ‘SOLVER_RULE_RECOMMENDS’ not handled in switch [-Wswitch]
../src/kits/package/solver/libsolv/LibsolvSolver.cpp:914:16: warning: enumeration value ‘SOLVER_RULE_BLACK’ not handled in switch [-Wswitch]
../src/kits/package/solver/libsolv/LibsolvSolver.cpp:914:16: warning: enumeration value ‘SOLVER_RULE_STRICT_REPO_PRIORITY’ not handled in switch [-Wswitch]
MkDir1 objects/linux/x86_64/release/build/libsolv 

We should likely detect the new libsolv package and optionally check for them.

~0.7.23

• SOLVER_RULE_PKG_CONSTRAINS ​https://github.com/openSUSE/libsolv/commit/cdf3f67b03cdc4755c2f03b8393b2d09d37b9159
• SOLVER_RULE_PKG_SUPPLEMENTS ​https://github.com/openSUSE/libsolv/commit/cdf3f67b03cdc4755c2f03b8393b2d09d37b9159

~0.6.4

• SOLVER_RULE_JOB_UNKNOWN_PACKAGE ​https://github.com/openSUSE/libsolv/commit/c63a0c9ce78bf828e91508981608f7973ac7b1a5
• SOLVER_RULE_JOB_UNSUPPORTED ​https://github.com/openSUSE/libsolv/commit/c63a0c9ce78bf828e91508981608f7973ac7b1a5

~Unknown

• SOLVER_RULE_YUMOBS
• SOLVER_RULE_RECOMMENDS
• SOLVER_RULE_BLACK
• SOLVER_RULE_STRICT_REPO_PRIORITY

You too can try this via:

diff --git a/build/jam/repositories/HaikuPorts/x86_64 b/build/jam/repositories/HaikuPorts/x86_64
index bf09923c1a..b95965ae6f 100644
--- a/build/jam/repositories/HaikuPorts/x86_64
+++ b/build/jam/repositories/HaikuPorts/x86_64
@@ -155,8 +155,8 @@ RemotePackageRepository HaikuPorts
        libpsl_devel-0.21.1-2
        libraw-0.20.2-1
        libraw_devel-0.20.2-1
-       libsolv-0.3.0_haiku_2014_12_22-3
-       libsolv_devel-0.3.0_haiku_2014_12_22-3
+       libsolv-0.7.23-3
+       libsolv_devel-0.7.23-3
        libssh2-1.9.0-2
        libssh2_devel-1.9.0-2
        libtasn1-4.18.0-1

[kallisti5]

more errors

<command-line>: note: this is the location of the previous definition
Cc objects/linux/x86_64/release/build/libsolv/testcase.o 
In file included from build_packages/libsolv_source-0.7.23-3-source/develop/sources/libsolv-0.7.23-3/sources/src/pool.h:18,
                 from build_packages/libsolv_source-0.7.23-3-source/develop/sources/libsolv-0.7.23-3/sources/ext/testcase.c:15:
objects/common/build/libsolv/solvversion.h:28:2: error: invalid preprocessing directive #cmakedefine
   28 | #cmakedefine LIBSOLV_FEATURE_LINKED_PKGS
      |  ^~~~~~~~~~~
objects/common/build/libsolv/solvversion.h:29:2: error: invalid preprocessing directive #cmakedefine
   29 | #cmakedefine LIBSOLV_FEATURE_COMPLEX_DEPS
      |  ^~~~~~~~~~~
.
.

These can be solved via:

diff --git a/src/build/libsolv/Jamfile b/src/build/libsolv/Jamfile
index 3cedcf7d79..27fe16af22 100644
--- a/src/build/libsolv/Jamfile
+++ b/src/build/libsolv/Jamfile
@@ -97,6 +97,8 @@ actions GenerateLibsolvVersionHeader
                -e s,@LIBSOLV_MAJOR@,$(LIBSOLV_MAJOR),g \
                -e s,@LIBSOLV_MINOR@,$(LIBSOLV_MINOR),g \
                -e s,@LIBSOLV_PATCH@,$(LIBSOLV_PATCH),g \
+               -e 's/#cmakedefine.*LIBSOLVEXT_FEATURE_HAIKU$/#define LIBSOLVEXT_FEATURE_HAIKU/' \
+               -e '/#cmakedefine/d' \
                $(2) > $(1)
 }

However, "GenerateLibsolvVersionHeader" feels like an abomination in general. It seems to be fixing up libsolv_source packages for the build host.

[kallisti5]

​https://review.haiku-os.org/c/haiku/+/6270 for x86_64

[pulkomandy]

This jamfile looks like a leftover from libsolv being copied into Haiku sources, not properly cleaned when libsolv was moved into a package. If that's the case, it should indeed be removed.

[kallisti5]

We have to build libsolv for the host tools... then build libsolv for haiku and the package kit. I can't think of anything else "out of tree" that we have to build as a built_package? I think that explains some of the oddness.

To be completely honest, given how often we update libsolv... it may be something we actually want + need to keep in-tree. The license is BSD. ​https://github.com/openSUSE/libsolv/blob/master/LICENSE.BSD

libsolv is a complex thing to update, especially given all the weird patching we do via Jam. There's an ABI change between 0.3.0 and 0.7.23.. so updating libsolv immediately breaks the package kit. (we have to make it a build-package, then rebuild on the later version)

[kallisti5]

Pulkomandy made the case that zlib, zstd, etc also fit into this model which is true.

I guess the fact that libsolv getting updated by anyone missing an ?all arch flag could theoretically break every Haiku installation is what makes me worry a bit.

Heck... even stable releases like r1beta4, r1beta3, etc.

[kallisti5]

ugh. If we wanted to update libsolv as it stands, we would need to upgrade haiku.hpkg at the same time as libsolv across every stable branch and every architecture too.

Ok.. My opinion is we really do need to move libsolv in-tree. Fight me about it :-)

[tqh]

Perhaps a companion tree for essential things instead of haiku? Kind of like buildtools.

[pulkomandy]

First of all there's a thing to fix on haikuports side: if versions of libsolv have a different ABI, the pacbage name should be suffixed with the ABI version so that the packages don't conflict with each other. Just like for the other libraries used by Haiku. There is nothing special about this one and the process is equally annoying for the other libraries. But the alternative of maintaining a jam based build for libraries and copying all their code inside Haiku git is equally annoying.

So let's fix that versioning on Haikuports side first, and then we can see what's best.

[kallisti5]

My only point is lets not be complected just to be complected. As it stands:

• libsolv needs a recipe for a new version
• libsolv needs built locally for a new version on every architecture and branch
• libsolv needs made into a build_package and uploaded to the server along with the source package
• libsolv needs the build_packages updated for every architecture + branch
• libsolv needs plugged into build_packages repo in the source tree
• libsolv needs to be compiled against and bugs fixed in haiku's consumers.
• Haiku needs jam files updated for the various sets of new source files in libsolv (without breaking the older versions mind you)
• All of this has to come together and be updated across every architecture, every branch, with an updated haiku.hpkg at the same time + transaction

Versioning as a new major (libsolv03, libsolv07) fixes some of those things, but doesn't address all of them all of this, so we can theoretically bump the libsolv version (if there are no ABI changes) without rebuilding haiku.hpkg

moving to a static library would mean we can "just pull the libsolv_source", use it.

If the user wants to install the real libsolv package, they can without any risk to impacting the package kit's functionality.

[pulkomandy]

The build from source for the host is what requires mesing with sourcecode on Haiku side. For the parts that run on Haiku we should use a libraryeindeed (static or shared with package named after ABI. it doesn't really make a difference)

But you stillneed to build for the host and that has to be done at Haiku buildtime. Unless we stop supporting building from any other OS than Haiku, but that sounds like a bad idea?

[pulkomandy]

Part of the "upgrade system packages" task, moving to beta5 milestone for consideration

[waddlesplash]

I agree with vendoring libsolv. zlib and zstd are different in that we don't build them for the host, we just use the host-provided versions of them.

[waddlesplash]

I've switched us to using a vendored libsolv in hrev57880.

[waddlesplash]

Kicking the can down the road on this one again. We now use a vendored libsolv so upgrades should be possible between releases much more easily now.