Enable packages metadata to be float when int is expected

[m-czernek]

What does this PR change?

When we process package metadata, packages can mistakenly have float where we expect integer, for example Installed Size, Size, etc.

Though this is technically an invalid package, Uyuni can round such values to integer instead of throwing an exception.

In this PR, if a package contains a float value in metadata where we expect integer, we first round the value to the nearest integer.

In case where such value is neither float nor int, I improve the error that is displayed to the user.

Documentation

• No documentation needed: only internal and user invisible changes

Links

Issue(s): #9613
Port(s): TODO

• DONE

Changelogs

Make sure the changelogs entries you are adding are compliant with https://github.com/uyuni-project/uyuni/wiki/Contributing#changelogs and https://github.com/uyuni-project/uyuni/wiki/Contributing#uyuni-projectuyuni-repository

If you don't need a changelog check, please mark this checkbox:

• No changelog needed

If you uncheck the checkbox after the PR is created, you will need to re-run changelog_test (see below)

Re-run a test

If you need to re-run a test, please mark the related checkbox, it will be unchecked automatically once it has re-run:

• Re-run test "changelog_test"
• Re-run test "backend_unittests_pgsql"
• Re-run test "java_pgsql_tests"
• Re-run test "schema_migration_test_pgsql"
• Re-run test "susemanager_unittests"
• Re-run test "javascript_lint"
• Re-run test "spacecmd_unittests"

Before you merge

Check How to branch and merge properly!

[m-czernek]

I refactored this into a separate function so that sonarcloud won't fail with method complexity being too high.

[agraul]

I wonder why we use classes, but then don't do this with the classes. Would be too big to change that here, but it's something we could think about changing.

[agraul]

Do we have any examples we can use for testing this change?

[agraul]

Are we using "GH" without any project/repo in changelogs? If we don't like gh#uyuni-project/uyuni#9613, maybe we could request to add uyuni#9613 to known trackers in OBS?

[agraul]

I wonder why we use classes, but then don't do this with the classes. Would be too big to change that here, but it's something we could think about changing.

[m-czernek]

@agraul for testing, see [0]. I personally tested it with the wolframscript pkg from [1], which uses Installed-Size: 6635.2451171875.

To not sync the whole repo, I created a local deb repo (using the file:// protocol). If it'd help, let me know, I can send you the repo.

[0] http://archive.raspberrypi.org/debian/dists/bookworm/main/binary-arm64/Packages
[1] https://archive.raspberrypi.org/debian/pool/main/w/wolframscript/wolframscript_14.1.0+20240822262_arm64.deb

[agraul]

Thanks for the pointer, I'll try to sync this to see if we can solve the issue higher up in the stack. Just to have a second approach we can compare to this one.

[agraul]

The alternative that immediately came to my mind was to fix this at the outside layer instead of deep down close to the DB insertion. The downside is that this approach only works for known keys, instead of anything. But casting anything to float then int is maybe not needed either.

python/spacewalk/server/importlib/debPackage.py | 5 +++++

modified   python/spacewalk/server/importlib/debPackage.py
@@ -59,6 +59,11 @@ class debBinaryPackage(headerSource.rpmBinaryPackage):
             value = header[field]
             if key == "build_time" and isinstance(value, int):
                 value = gmtime(value)  # unix timestamp
+            elif key == "payload_size" and value:
+                # Payload size / Installed-Size is an int, but some packages have
+                # bad metadata (float). Since Installed-Size is an estimation, truncating to int is ok
+                # https://www.debian.org/doc/debian-policy/ch-controlfields.html#installed-size
+                value = int(float(value))
             elif value == []:
                 value = None
             elif value:

I'm not sure why we currently keep every value as a string until it hits the DB and only casts it to the expected DB type. Maybe your approach fits better with the current approach.