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

|

objects/common/build/libsolv/solvversion.h:30:2: error: invalid preprocessing directive #cmakedefine

30 | #cmakedefine LIBSOLV_FEATURE_MULTI_SEMANTICS

|

objects/common/build/libsolv/solvversion.h:31:2: error: invalid preprocessing directive #cmakedefine

31 | #cmakedefine LIBSOLV_FEATURE_CONDA

|

objects/common/build/libsolv/solvversion.h:33:2: error: invalid preprocessing directive #cmakedefine

33 | #cmakedefine LIBSOLVEXT_FEATURE_RPMPKG

|

objects/common/build/libsolv/solvversion.h:34:2: error: invalid preprocessing directive #cmakedefine

34 | #cmakedefine LIBSOLVEXT_FEATURE_RPMDB

|

objects/common/build/libsolv/solvversion.h:35:2: error: invalid preprocessing directive #cmakedefine

35 | #cmakedefine LIBSOLVEXT_FEATURE_RPMDB_BYRPMHEADER

|

objects/common/build/libsolv/solvversion.h:36:2: error: invalid preprocessing directive #cmakedefine

36 | #cmakedefine LIBSOLVEXT_FEATURE_PUBKEY

|

objects/common/build/libsolv/solvversion.h:37:2: error: invalid preprocessing directive #cmakedefine

37 | #cmakedefine LIBSOLVEXT_FEATURE_RPMMD

|

objects/common/build/libsolv/solvversion.h:38:2: error: invalid preprocessing directive #cmakedefine

38 | #cmakedefine LIBSOLVEXT_FEATURE_SUSEREPO

|

objects/common/build/libsolv/solvversion.h:39:2: error: invalid preprocessing directive #cmakedefine

39 | #cmakedefine LIBSOLVEXT_FEATURE_COMPS

|

objects/common/build/libsolv/solvversion.h:40:2: error: invalid preprocessing directive #cmakedefine

40 | #cmakedefine LIBSOLVEXT_FEATURE_HELIXREPO

|

objects/common/build/libsolv/solvversion.h:41:2: error: invalid preprocessing directive #cmakedefine

41 | #cmakedefine LIBSOLVEXT_FEATURE_DEBIAN

|

objects/common/build/libsolv/solvversion.h:42:2: error: invalid preprocessing directive #cmakedefine

42 | #cmakedefine LIBSOLVEXT_FEATURE_ARCHREPO

|

objects/common/build/libsolv/solvversion.h:43:2: error: invalid preprocessing directive #cmakedefine

43 | #cmakedefine LIBSOLVEXT_FEATURE_HAIKU

|

objects/common/build/libsolv/solvversion.h:44:2: error: invalid preprocessing directive #cmakedefine

44 | #cmakedefine LIBSOLVEXT_FEATURE_APPDATA

|

objects/common/build/libsolv/solvversion.h:45:2: error: invalid preprocessing directive #cmakedefine

45 | #cmakedefine LIBSOLVEXT_FEATURE_ZLIB_COMPRESSION

|

objects/common/build/libsolv/solvversion.h:46:2: error: invalid preprocessing directive #cmakedefine

46 | #cmakedefine LIBSOLVEXT_FEATURE_LZMA_COMPRESSION

|

objects/common/build/libsolv/solvversion.h:47:2: error: invalid preprocessing directive #cmakedefine

47 | #cmakedefine LIBSOLVEXT_FEATURE_BZIP2_COMPRESSION

|

objects/common/build/libsolv/solvversion.h:48:2: error: invalid preprocessing directive #cmakedefine

48 | #cmakedefine LIBSOLVEXT_FEATURE_ZSTD_COMPRESSION

|

objects/common/build/libsolv/solvversion.h:49:2: error: invalid preprocessing directive #cmakedefine

49 | #cmakedefine LIBSOLVEXT_FEATURE_ZCHUNK_COMPRESSION

|

`

[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
  • We can't build via buildmaster as a new libsolv of a new ABI would break every haiku install (nightly or release) that doesn't have the matching updated haiku.hpkg.
• 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.